Review+Project+3+SSE658

=Design Patterns Review=

Design Patterns
Design Patterns are design tools used to improve existing code. Design patterns allow the code we write to be easier to implement, build, and maintain. Design Patterns are a general reusable solution to a commonly occurring problem in software design. Design patterns will allow you as the developer to improve your overall design skills as well as the quality of your projects. If there are common problems in coding, design patterns will allow us to see new answers to those problems. We will have a common programming model, which other developers will also be familiar with it. They will help us be a better software designer by using standard patterns that we will follow. A design patterns cannot be made into code directly, it is not a finished design. It is more of a template used to solve common problems. They show relationships between classes and objects. When we reuse design patterns, we avoid causing major problems, and making the code easier to read. Design pattern models are based on the aspects of object-oriented languages. Encapsulation, polymorphism, abstraction, and inheritance all extend their properties into the design patterns concept. You might say that patterns methodology is an extension of object-oriented methodology. To better understand where patterns fit into the object-oriented design, we need to examine some of these properties. Those will be called the building block of the OOD.

Encapsulation
Encapsulation is one of the most important aspects of object-oriented languages. In encapsulation we want to keeping things private or masked inside the domain of an object, package, namespace, class, or interface and allowing only expected access to pieces of functionality. We use the rule of encapsulation in almost every aspect of OOP. Encapsulation is widely used on patterns such as facades, proxies, bridges, and adapters. It allows us to hide with an interface or class structure some functionality that we do not wish to be publicly or globally known. When you encapsulate functionality into an object, you decide what interface that object exposes to the world. We decide what getter and setter methods and/or public properties your objects present to the rest of the application so that the application can interact with it. The whole idea behind encapsulation — you hide the complexities inside objects and then create a simple interface to let that object interact with the rest of your code. You should encapsulate what changes the most.

Polymorphism
Polymorphism is the ability to extend things, in our case our objects. We can do polymorphism by either overloading a type or by overriding the type. We also override methods. When we override the class, it will have the same name as the parent class. The compiler will determine which one to run. For example, you might want to write code that handles all kinds of different shapes — rectangles, circles, triangles, and so on. Although they’re different shapes, they all have in common certain actions as far as your code goes — for example, they can all be drawn. There are important concepts that we should learn when dealing with polymorphism. When we create classes they can be either abstract or concrete. Abstract classes are the ones that are not instantiated. An abstract class has no value; it needs to be extended in order to be useful. Methods can also be abstract, if a method is abstract; the class in which the method is declared should be abstract as well.

Abstraction
Abstraction cannot be considered a programming technique. It means that you conceptualize a problem before applying OOP techniques. The whole idea of abstraction is to break down the approach to a problem into natural segments. Abstracting a problem simply means thinking of how to solve a problem in terms of object-oriented code. Much of what design patterns are all about has to do with making sure we are setting up the way to take care of the problem correctly. Working with design patterns often means spending more time on the abstraction part of the process than on the concrete classes’ part.

Inheritance
Inheritance is the process by which one class can inherit methods and properties from another class. Design patterns tend to favor composition over inheritance. (You use composition when your object contains other objects instead of inheriting from them.) Inheritance sets up “is-a” relationships — Circle “is-a” Shape, for example. When you use composition, your code contains other objects, rather than inheriting from them. And to be supple enough to deal with the various kinds of contained objects in the same way, with the same code, design-patterns often rely on polymorphism.

Design Patterns Classifications
Design patterns are grouped into three different categories: Creational patterns, Structural patterns, and Behavioral patterns. Creational Patterns are patterns whose job is to make the job easier of creating, initializing, and configuring objects and classes. Basically, creational patterns are grouped and called that way because they create things: other classes, interface implementations, attributes, or any other structural type. They act as factories, builders, configuration constructs, or class initializers. These types of patterns are useful when we need to render instances of objects, store these objects, perform complex initialization of objects, or create copies of objects. Structural Patterns are patterns whose job is to make easier to change the structural associations of classes, class associations, and hierarchies of class structures. Most structural patterns take on the form of facades or types of proxies and adapters. Behavioral Patterns are patterns whose job is to make easier to calculate algorithms and the communication between classes. They use inheritance heavily to control code flow. They define and produce process and run-time flow and identify hierarchies of classes and when and where they become instantiated in code. Some define class instance and state, some hand off work from one class to another, and some provide placeholders for other functionality.

The 23 Gang of Four Design Patterns
Next we have the original 23 Gang of Four design patterns (from Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley Professional Computing Series, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides). Those 4 guys came with the foundation of Design Patterns.



Proxy ** REVIEW ** Conclusion


 * Chapters **