Software Design Patterns 101: A Beginner’s Guide, a Medium essay, introduces readers to software design patterns and discusses how they help create systems that are effective, scalable, and manageable. According to the article, design patterns are reusable templates that help programmers produce cleaner, more structured code by resolving common programming problems. The three primary types of design patterns, structural, behavioral, and creational are explained. Object generation is the main emphasis of creational patterns like Factory Method and Singleton. Adapter and Composite are two examples of structural patterns that explain how classes and objects can be merged to create more expansive, adaptable systems. Observer and Strategy are two behavioral patterns that emphasize direct communication and responsibility delegation. Teams can create a common language by employing these patterns, which enhances cooperation and lowers misunderstandings.
I chose this article because it clearly relates to the concepts of object-oriented design and code organization that we have been studying in class. In a recent exercise, for instance, we examined a Duck class hierarchy dilemma in which some subclasses, such as RubberDuck and DecoyDuck, were compelled to inherit unnecessary methods, such quack() and fly(). Because of this design, we had to override methods with “do nothing” implementations because these ducks either didn’t fly or quack. My understanding of why this is a typical example of a design issue that can be fixed using patterns like the Strategy Pattern, Which is under the behavioral category covered in the reading.
I came to understand how inheritance, although helpful, may become problematic when it compels subclasses to adopt behavior that isn’t appropriate for them through the article and our class discussion. Depending on the type of duck, the quack() and fly() methods in the Duck superclass in our example have different actions. We may dynamically assign these behaviors to various ducks at runtime by classifying them into distinct classes, such as FlyBehavior and QuackBehavior. This method reduced superfluous overrides and increased the design’s adaptability. Here, the Strategy Pattern was essential since it let us alter a duck’s behavior without explicitly changing its class.The way that design patterns like Strategy prioritize composition over inheritance struck resonated with me. By mixing smaller, reusable components instead of depending only on strict class hierarchies, this idea promotes the development of systems. In the Duck example, we can simply construct new behavior classes and mix them in as needed, rather than adding extra subclasses each time a new type of duck is created. I intend to incorporate these ideas into my upcoming work. For instance, I could use behavior classes for activities like jumping, running, and attacking if I were creating a game with many character kinds. This would eliminate the need to rewrite significant portions of code in order to add new characters or change current ones.
From the blog CS@Worcester – A Bostonians Blogs by Abdulhafeedh Sotunbo and used with permission of the author. All other rights reserved by the author.
