OOPS: Why Design-Pattern and Why not Coding-Pattern

Question

Thanks in advance for your reply.

I am interested in C/C++ mentoring. My way of teaching would be to explain the necessity of a new concept/technology first or what is the drawback in the existing system. In that way, I tried to arrive for the necessity and the naming reason for design patterns.

Now come to my actual question. I know almost all design pattern at least theoretically and used some practically too. No problem in usage. But when I teach, I used to raise few questions towards myself which I may expect from students.

1. Can’t I survive without design patterns? - seems like just a logics/algorithms for a problem. since its solution for a common/repeated problem is it publicized just to avoid the reinvention of the same wheel?.

2. Called as design pattern but it seems like a coding-pattern? - If its just code logics, why its called as design pattern. As a programmer, I can also analyse which loop statement should I use? ie. for/while/ do-while? can I name it as "loop design pattern". If someone answers as "hey this is just a problem dealing with building blocks(conditional/loop/datatypes/storage classes) of coding language. If so, I can raise same question against a singleton -"Hey its just a problem dealing with static keyword".But static key word too part of building block. If so, I can raise same question against a Factory, Builder, bridge, visitor, strategy - "Hey they are just problems dealing with dynamic binding which is achieved using raw, unsafe "void" pointers in C and safe virtual mechanism in C++" that's it" do you agree?.

3. Are they introduced to achieve SOLID principles? I came to know about SOLID principles 5 years later I started to use design patterns. ie. theoretically I was not perfect. But after i read those principles I could understand every design pattern satisfies at least one of those five rules. Hence can I conclude as SOLID is design level constraints and design patterns are code level solutions. Hence it should be called as "coding patterns"

4. So what is the boundary line for design and coding?

5. Is it just a make-life-easy tool?(ie. Reusability: Productivity: maintainability: Extendibility: scalability, etc).

6. Or do you want to simply compromise me as "Hey someone named it so, leave it"?

I have my own answer in different view, which you please correct?

Answer 1: Before a developer, a designer(low level/high level) also will bother about entity/objects and communication between objects, all. For him the language is UML and he has class, sequence, state diagram, etc. So we can understand that these patterns were published as UML diagrams by designers only, but code solutions were given later by different developers hence named as "design" patterns?

Answer 2: In C, "type" and "logic" were kept separated(even for user defined datatypes using struct keyword). But in C++, some of the logics were merged as member functions-eg. boundary checking for array type. so while writing the standalone functions in C, you need to worry only about algorithms/logics which you can name as "coding pattern" for "repeated problems". But in OO paradigm(C++), while defining your "type" itself you have to think more than storage space. ie. data members, which you cant simply call as logics, because instead of defining a type you almost design a "type" by considering constraints, like 1. only-single instance for singleton, 2. enabling provision for new states in state pattern, etc.

If you feel, I confuse myself or have too much analysis on this, please allow me. I want to have more clarity while explaining to students because they should not get confused. Thanks

Answer 1

1. Sure, you can survive without patterns. When you first learn to code all you know is syntax, and you can still make things run. But at some point you'll want to communicate what you've written to other developers on your team. Wouldn't it be nice to have a terminology to explain your implementation at a high level, without having to describe every line or function?

2. The concept of design patterns is taken from architecture, which has its own design patterns. In software, design patterns are language agnostic. They are not tied to syntax. If you think Singleton is about static, your understanding of the pattern is incomplete. The equivalent of patterns at a language syntax level is called idioms. Idioms are implementation patterns. They are equally important, but not transferable across languages.

3. The GoF design patterns cannot have been intended to achieve SOLID principles specifically, because SOLID was published years later; however, the principles that SOLID is based on (coupling, cohesion, separation of concerns, etc) are older and certainly were known to the authors of the GoF. Good software tends to satisfy software principles. It should be no surprise that good patterns would do the same.

4. This question is too big and too vague. Entire books are written on software design.

5. Isn't all software just a make-life-easy tool?

6. Appealing to the authority of the GoF has certainly been a common refrain; but I would recommend appealing to the authority of your team instead. If your team practices design patterns, then your apps will have a consistent structure that is easily communicated. If your team is not interested in design patterns, then they will benefit very little from you implementing them alone. I believe design patterns are about the social aspect of programming more than anything else.

A1. The "designer" you're talking about here sounds like an architect. Architecture is more abstract than (GoF) design patterns. It is concerned with the integration of multiple apps across separate systems.

A2. You are describing the difference between Procedural Programming and Object-Oriented Programming. OOP gave rise to the patterns movement: it made them famous; but every paradigm has its own patterns. C is a procedural language while C++ supports OOP. Your approach to mentoring these two languages would be quite different if you intend to teach the different paradigms.