Design Pattern - Revision history

User at 17:42, 2 January 2023

2023-01-02T17:42:23Z

Show changes

User at 18:06, 9 June 2022

2022-06-09T18:06:46Z

User at 17:57, 9 June 2022

2022-06-09T17:57:11Z

User at 16:23, 9 June 2022

2022-06-09T16:23:48Z

User at 16:02, 9 June 2022

2022-06-09T16:02:40Z

User: Created page with "'''Content Coming Soon'''"

2018-12-03T19:54:23Z

Created page with "'''Content Coming Soon'''"

New page

'''Content Coming Soon'''

@@ Line 93: / Line 93: @@
 [[File:Design Pattern Structure.png|400px|Design Pattern Structure]]
@@ Line 106: / Line 115: @@
 == Criticism<ref>Criticism of Design Pattern [https://en.wikipedia.org/wiki/Software_design_pattern Wikipedia]</ref> ==
 It has been observed that design patterns may just be a sign that some features are missing in a given programming language (Java or C++ for instance). Peter Norvig demonstrates that 16 out of the 23 patterns in the Design Patterns book (which is primarily focused on C++) are simplified or eliminated (via direct language support) in Lisp or Dylan. Related observations were made by Hannemann and Kiczales who implemented several of the 23 design patterns using an aspect-oriented programming language (AspectJ) and showed that code-level dependencies were removed from the implementations of 17 of the 23 design patterns and that aspect-oriented programming could simplify the implementations of design patterns. See also Paul Graham's essay "Revenge of the Nerds". Inappropriate use of patterns may unnecessarily increase complexity.

@@ Line 6: / Line 6: @@
 [[File:Design Pattern.png|400px|Design Pattern]]
@@ Line 35: / Line 50: @@
 In 1998 Mark Grand released Patterns in Java. This book included design patterns not found in the GoF book, including concurrency patterns. Grand also used the Unified Modeling Language (UML) to describe design patterns and their solutions. The book's examples were expressed and described in the Java language.
@@ Line 76: / Line 102: @@
 ''Disadvantages''<br />
 Using design patterns requires extensive knowledge. Having design patterns available can also lead to people believing that apparently all problems can be solved using existing design patterns. In short, this can limit creativity and the desire to find new (better) solutions.

@@ Line 17: / Line 17: @@
-== The History of Design Pattern<ref>The History of Design Pattern [https://www.infoworld.com/article/2078665/design-patterns-the-big-picture-part-1-design-pattern-history-and-classification.html Infoworld]</ref> --
+== The History of Design Pattern<ref>The History of Design Pattern [https://www.infoworld.com/article/2078665/design-patterns-the-big-picture-part-1-design-pattern-history-and-classification.html Infoworld]</ref> ==
 Design patterns date back to the late 1970s with the publication of A Pattern Language: Towns, Buildings, Construction by architect Christopher Alexander and a few others. This book introduced design patterns in an architectural context, presenting 253 patterns that collectively formed what the authors called a pattern language.
@@ Line 40: / Line 40: @@
 There are mainly three types of design patterns:
 *Creational: These design patterns are all about class instantiation or object creation. These patterns can be further categorized into Class-creational patterns and object-creational patterns. While class-creation patterns use inheritance effectively in the instantiation process, object-creation patterns use delegation effectively to get the job done.
 **Use case of creational design pattern-
 ***Suppose a developer wants to create a simple DBConnection class to connect to a database and wants to access the database at multiple locations from code, generally what the developer will do is create an instance of DBConnection class and use it for doing database operations wherever required. This results in creating multiple connections from the database as each instance of DBConnection class will have a separate connection to the database. In order to deal with it, we create DBConnection class as a singleton class, so that only one instance of DBConnection is created and a single connection is established. Because we can manage DB Connection via one instance, we can control load balance, unnecessary connections, etc.
 ***Suppose you want to create multiple instances of a similar kind and want to achieve loose coupling then you can go for Factory pattern. A class implementing factory design pattern works as a bridge between multiple classes. Consider an example of using multiple database servers like SQL Server and Oracle. If you are developing an application using SQL Server database as back end, but in the future need to change the database to the oracle, you will need to modify all your code, so as factory design patterns maintain loose coupling and easy implementation, we should go for the factory design pattern in order to achieve loose coupling and the creation of a similar kind of object.
-*Structural: These design patterns are about organizing different classes and objects to form larger structures and provide new functionality.
+Creational design patterns are the Factory Method, Abstract Factory, Builder, Singleton, Object Pool, and Prototype.
-Structural design patterns are Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Private Class Data, and Proxy.
+*Structural: These design patterns are about organizing different classes and objects to form larger structures and provide new functionality.
 **Use Case Of Structural Design Pattern-
 ***When 2 interfaces are not compatible with each other and want to establish a relationship between them through an adapter it’s called an adapter design pattern. The adapter pattern converts the interface of a class into another interface or class that the client expects, i.e adapter lets classes work together that could not otherwise because of incompatibility. so in these types of incompatible scenarios, we can go for the adapter pattern.
 *Behavioral: Behavioral patterns are about identifying common communication patterns between objects and realizing these patterns.
 **Use Case of Behavioral Design Pattern-
 ***The template pattern defines the skeleton of an algorithm in an operation deferring some steps to sub-classes. The template method lets subclasses redefine certain steps of an algorithm without changing the algorithm structure. For example, in your project, you want the behavior of the module to be able to extend, such that we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications. However, no one is allowed to make source code changes to it, i.e you can add but can’t modify the structure in those scenarios a developer can approach template design pattern.

← Older revision		Revision as of 16:02, 9 June 2022
Line 1:		Line 1:
−	'''~~Content Coming Soon~~'''	+	== What is a Design Pattern?<ref>Definition - What does Design Pattern Mean? [https://www.techopedia.com/definition/18822/design-pattern Techopedia]</ref> ==
		+	A '''design pattern''' is a repeatable solution to a software engineering problem. Unlike most program-specific solutions, design patterns are used in many programs. Design patterns are not considered finished product; rather, they are templates that can be applied to multiple situations and can be improved over time, making a very robust software engineering tool. Because development speed is increased when using a proven prototype, developers using design pattern templates can improve coding efficiency and final product readability.
		+
		+	Design patterns are language neutral, so they can be applied to any language that supports object-orientation.
		+
		+
		+	[[File:Design Pattern.png\|400px\|Design Pattern]]
		+
		+
		+	=== What Design Pattern is Not<ref>What Design Pattern is Not [https://cs.lmu.edu/~ray/notes/designpatterns/ LMU]</ref> ===
		+	Design Patterns are not analysis patterns, are not descriptions of common structures like linked lists, nore are they detailed application or framework designs. Design Patterns are "descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context." -- Gamma et al.
		+
		+	Good design patterns help make your software more flexible and reusable.
		+
		+
		+	__TOC__
		+
		+
		+	== The History of Design Pattern<ref>The History of Design Pattern [https://www.infoworld.com/article/2078665/design-patterns-the-big-picture-part-1-design-pattern-history-and-classification.html Infoworld]</ref> --
		+	Design patterns date back to the late 1970s with the publication of A Pattern Language: Towns, Buildings, Construction by architect Christopher Alexander and a few others. This book introduced design patterns in an architectural context, presenting 253 patterns that collectively formed what the authors called a pattern language.
		+
		+	The concept of a pattern language subsequently emerged in Donald Norman's and Stephen Draper's User Centered System Design, which was published in 1986. This book suggested the application of pattern languages to interaction design, which is the practice of designing interactive digital products, environments, systems, and services for human use.
		+
		+	Meanwhile, Kent Beck and Ward Cunningham had begun to study patterns and their applicability to software design. In 1987, they used a series of design pattern to assist Tektronix's Semiconductor Test Systems Group, which was having trouble finishing a design project. Beck and Cunningham followed Alexander's advice for user-centered design (letting representatives of the project's users determine the design outcome) while also providing them with some design patterns to make the job easier.
		+
		+	Erich Gamma also realized the importance of recurring design patterns while working on his PhD thesis. He believed that design patterns could facilitate the task of writing reusable object-oriented software, and pondered how to document and communicate them effectively. Prior to the 1991 European Conference on Object-Oriented Programming, Gamma and Richard Helm started to catalog patterns.
		+
		+	At an OOPSLA workshop held in 1991, Gamma and Helm were joined by Ralph Johnson and John Vlissides. This Gang of Four (GoF), as they subsequently were known, went on to write the popular Design Patterns: Elements of Reusable Object-Oriented Software, which documents 23 design patterns in three categories.
		+
		+
		+	=== Modern Evolution of Design Patterns ===
		+	Design patterns have continued to evolve since the original GoF book, especially as software developers have confronted new challenges related to changing hardware and application requirements.
		+
		+	In 1994, a U.S.-based non-profit organization known as the Hillside Group inaugurated Pattern Languages of Programs, a group of annual conferences whose aim is to develop and refine the art of software design patterns. These ongoing conferences have yielded many examples of domain-specific design patterns. For example, design patterns in a concurrency context.
		+
		+	In 1998 Mark Grand released Patterns in Java. This book included design patterns not found in the GoF book, including concurrency patterns. Grand also used the Unified Modeling Language (UML) to describe design patterns and their solutions. The book's examples were expressed and described in the Java language.
		+
		+
		+	== Types of Design Patterns<ref>What are the Different Types of Design Patterns [https://www.geeksforgeeks.org/design-patterns-set-1-introduction/ Geeks for Geeks]</ref> ==
		+	There are mainly three types of design patterns:
		+	*Creational: These design patterns are all about class instantiation or object creation. These patterns can be further categorized into Class-creational patterns and object-creational patterns. While class-creation patterns use inheritance effectively in the instantiation process, object-creation patterns use delegation effectively to get the job done.
		+	Creational design patterns are the Factory Method, Abstract Factory, Builder, Singleton, Object Pool, and Prototype.
		+	**Use case of creational design pattern-
		+	***Suppose a developer wants to create a simple DBConnection class to connect to a database and wants to access the database at multiple locations from code, generally what the developer will do is create an instance of DBConnection class and use it for doing database operations wherever required. This results in creating multiple connections from the database as each instance of DBConnection class will have a separate connection to the database. In order to deal with it, we create DBConnection class as a singleton class, so that only one instance of DBConnection is created and a single connection is established. Because we can manage DB Connection via one instance, we can control load balance, unnecessary connections, etc.
		+	***Suppose you want to create multiple instances of a similar kind and want to achieve loose coupling then you can go for Factory pattern. A class implementing factory design pattern works as a bridge between multiple classes. Consider an example of using multiple database servers like SQL Server and Oracle. If you are developing an application using SQL Server database as back end, but in the future need to change the database to the oracle, you will need to modify all your code, so as factory design patterns maintain loose coupling and easy implementation, we should go for the factory design pattern in order to achieve loose coupling and the creation of a similar kind of object.
		+	*Structural: These design patterns are about organizing different classes and objects to form larger structures and provide new functionality.
		+	Structural design patterns are Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Private Class Data, and Proxy.
		+	**Use Case Of Structural Design Pattern-
		+	***When 2 interfaces are not compatible with each other and want to establish a relationship between them through an adapter it’s called an adapter design pattern. The adapter pattern converts the interface of a class into another interface or class that the client expects, i.e adapter lets classes work together that could not otherwise because of incompatibility. so in these types of incompatible scenarios, we can go for the adapter pattern.
		+	*Behavioral: Behavioral patterns are about identifying common communication patterns between objects and realizing these patterns.
		+	Behavioral patterns are Chain of responsibility, Command, Interpreter, Iterator, Mediator, Memento, Null Object, Observer, State, Strategy, Template method, Visitor
		+	**Use Case of Behavioral Design Pattern-
		+	***The template pattern defines the skeleton of an algorithm in an operation deferring some steps to sub-classes. The template method lets subclasses redefine certain steps of an algorithm without changing the algorithm structure. For example, in your project, you want the behavior of the module to be able to extend, such that we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications. However, no one is allowed to make source code changes to it, i.e you can add but can’t modify the structure in those scenarios a developer can approach template design pattern.