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

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