Beginning Design Patterns

In this series we will take a review around the design patterns that are the great elements of reusable object oriented software.
We will speak first about the meaning and importance of this great technique
Then we will move to the discussion of each of the 23 design patterns which are the basic design patterns in Erich Gamma's book (Gang of four)
This book will be my reference in this series and also the book of James W. Cooper (Introduction to Design patterns).
The samples code of this discussion will be in the C# language you can also create them in any language of your choice we will not speak about the syntax of the C# language we will just discuss the design pattern technique.
The reader of this series should have a good understanding of the OOP technique and also some about OOD.
I think that's enough of blab and let's move to our discussion.

Sitting at your desk in front of your workstation, you stare into space, trying to figure out how to write a new program feature. You know intuitively what must be done, what data and what objects come into play, but you have this underlying feeling that there is a more elegant and general way to write this program.
In fact, you probably don’t write any code until you can build a picture in your mind of what the code does and how the pieces of the code interact.
The more that you can picture this organic whole, the more likely you are to feel comfortable that you have developed the best solution to the problem. If you don’t grasp this whole right away, you may keep staring out the window for a time, even though the basic solution to the problem is quite obvious.
In one sense you feel that the more elegant solution will be more reusable and more maintainable, but even if you are the sole likely programmer, you feel reassured once you have designed a solution that is relatively elegant and that doesn’t expose too many internal inelegances.
One of the main reasons that computer science researchers began to recognize design patterns is to satisfy this need for elegant, but simple, reusable solutions.


-What are design patterns?
before we know design patterns we need to know what's a pattern?
Pattern describes a problem which occurs over and over again in our
environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.
The term “design patterns” sounds a bit formal to the uninitiated and can be somewhat off-putting when you first encounter it.
But, in fact, design patterns are just convenient ways of reusing object oriented code between projects and between programmers.
In other words, design patterns describe how objects communicate without become entangled in each other’s data models and methods. Keeping this separation has always been an objective of good OOP, and if you have been trying to keep objects minding their own business, you are probably using some of the common design patterns already. Design patterns recognized to satisfy the need to elegant, simple, and reusable solutions, also
The fundamental reason for using design patterns is to keep classes separated and prevent them from having to know too much about one another. Equally important, using these patterns helps you avoid reinventing the wheel and allows you to describe your programming approach succinctly in terms other programmers can easily understand.

The authors divided these patterns into three types: creational, structural, and behavioral.
•Creational patterns create objects for you rather than having you instantiate objects directly. This gives your program more flexibility in deciding which objects need to be created for a given case.
•Structural patterns help you compose groups of objects into larger structures, such as complex user interfaces or accounting data.
•Behavioral patterns help you define the communication between objects in your system and how the flow is controlled in a complex program.


Example:
One of the frequently cited patterns from early literature on programming frameworks is the MVC (Model-View-Controller) framework for Smalltalk
(Krasner and Pope 1988), which divided the user interface problem into three parts.
The parts were referred to as
a data model, which contains the computational parts of the program;
the view, which presented the user interface;
and the controller, which interacted between the user and the view.
Each of these aspects of the problem is a separate object, and each has its own rules for managing its data. Communication among the user, the GUI, and the data should be carefully controlled, and this separation of functions accomplished that very nicely. Three objects talking to each other using this restrained set of connections is an example of a powerful design pattern.

I think that's enough for now we will begin our discussion of the first design pattern in the next article.
Thanks for reading, and enjoy your time.