Design Patterns And Design Principles Notes

Here are my design pattern notes in summary that I’ve already extracted. The order may be mixed, but I noted the important points and concepts.

Design pattern is a general repeatable solution to commonly occurring problem in software design.

• Creational patterns deal with the process of object creation
• Structural patterns, deal primarily with the static composition and structure of classes and objects
• Behavioral patterns, which deal primarily with dynamic interaction among classes and objects

A pattern has four essential elements (GoF)

• Pattern name: increases vocabulary of designers.
• Problem: intent, context, when to apply.
• Solution: UML-like structure, abstract code.
• Consequences: results and tradeoffs.

Name

• Describes the pattern
• Adds to common terminology for facilitating communication (i.e. not just sentence enhancers)

Problem

• Describes when to apply the pattern
• Answers — What is the pattern trying to solve?

Solution

• Describes elements, relationships, responsibilities, and collaborations which make up the design Consequences
• Results of applying the pattern
• Benefits and Costs
• Subjective depending on concrete scenarios

Pros Of Design Patterns

• Add consistency to designs by solving similar problems the same way, independent of language
• Add clarity to design and design communication by enabling a common vocabulary
• Improve time to solution by providing templates which serve as foundations for good design
• Improve reuse through composition

Cons Of Design Patterns

• Some patterns come with negative consequences (i.e. object proliferation, performance hits, additional layers)
• Consequences are subjective depending on concrete scenarios
• Patterns are subject to different interpretations, misinterpretations, and philosophies
• Patterns can be overused and abused (Anti Patterns)

Factory Pattern

• Factory pattern is one of the most used design patterns in Java.
• We create object without exposing the creation logic to the client
• We refer to newly created object using a common interface.

Abstract Factory Pattern

• It is Creational pattern
• Almost similar to Factory Pattern
• Considered as another layer of abstraction over factory pattern.
• Works around a super-factory which creates other factories.
• Implementation provides us with a framework that allows us to create objects that follow a general pattern.
• At runtime, the abstract factory is coupled with any desired concrete factory which can create objects of the desired type.

Singleton Pattern

• One of the simplest design patterns in Java
• It is Creational pattern
• involves a single class which is responsible to create an object while making sure that only single object gets created.
• This class provides a way to access its only object which can be accessed directly without need to instantiate the object of the class.
• Make constructor private.
• Write a static method that has return type object of this singleton class.

Adapter Pattern:

• Known as a wrapper.
• Connects incompatible components.
• Adapter is a structural design pattern, which allows incompatible objects to cooperate.
• Adapter acts as a wrapper between two objects, It catches calls for one object and transforms them to format and interface recognizable by the second object.
• Adapter is a structural design pattern, which allows incompatible objects to cooperate.

Decorator Pattern

• The Decorator Pattern attaches additional responsibilities to an object dynamically.
• Decorators provide a flexible alternative to subclassing for extending functionality.
• Decorators have the same super type as the object they decorate.
• You can use multiple decorators to wrap an object.
• Since decorators have same type as object, we can pass around decorated object instead of original.
• We can decorate objects at runtime.

Facade Pattern

• Hides the complexities of the system.
• Provides an interface to the client using which the client can access the system
• Involves a single class which provides simplified methods required by client
• Delegates calls to methods of existing system classes

SOLID Principles

• The Single Responsibility Principle: A class should have a single responsibility. This principle aims to separate behaviours so that if bugs arise as a result of your change, it won’t affect other unrelated behaviours.
• The Open-Closed Principle: Classes should be open for extension, but closed for modification. This principle aims to extend a Class’s behaviour without changing the existing behaviour of that Class. This is to avoid causing bugs wherever the Class is being used.
• The Liskov Substitution Principle If S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program. This principle aims to enforce consistency so that the parent Class or its child Class can be used in the same way without any errors.
• The Interface Segregation Principle Clients should not be forced to depend on methods that they do not use. This principle aims at splitting a set of actions into smaller sets so that a Class executes ONLY the set of actions it requires.
• The Dependency Inversion Principle High-level modules should not depend on low-level modules. Both should depend on the abstraction. Abstractions should not depend on details. Details should depend on abstractions. This principle aims at reducing the dependency of a high-level Class on the low-level Class by introducing an interface.

KISS (Keep it simple, stupid!): Very important principle that means you should keep up every piece simple.

DRY (Don’t repeat yourself): The small part of code should only occur one time in your system. Write reusable codes, and use it.

YAGNI (You ain’t gonna need it): Don’t implement any thing you don’t need. Just implement it when you need it.