+ -

Pages

Sunday, August 24, 2014

Software design patterns 01


Hi guys, welcome back. After several weeks today I'm going to write something about software design patterns. This is an introduction to software design patterns and also this is the first article of software design patterns article series. Let's move, 
{?} What are the design patterns?

Design patterns are well tested solutions to common problems in software development. 

Is it a package, module or a library? No, you can't download and install a design pattern. And also it's not a finished design that can be directly converted to the code. It's a guide line for how to solve a problem. Think of design patterns is an ultimate reuse in software development. Design patterns are,

  • Built from years of software development experience
  • Save time, minimize trial and error

If you learnt design patterns you are reusing experience not code. Change is a constant in software design. Say your manager is asking for add a new feature to the running system, or your client asking for a new feature or sometimes you may found a bug in the system. If your code is not flexible to change you may have to restructure it. In so many ways you can change your code. After that your system may powered with new features, or it may optimized or you may invented few bugs.

Lots of problems in software development are related to how flexible those systems are, Can we add a new feature easily? can we change the part of the system without breaking the entire system? can we adapt a new data exchange format in the system? Design patterns are invented to solve these kinds of problems in a effective way. Design patterns are not specific solutions for specific kinds of software.

If you are building a HR management system you may use some design pattern, when you are building a banking system you may use some other design pattern. Design patterns are providing general solutions for common problems in software development. The primary goal of any design pattern is help to structure your code in a flexible way.

Design patterns are originated by Christopher Alexander as an architectural concept in 1977-79. Then in 1987 Kent Beck and Wad Cunningham began experimenting by applying this idea to programming and presented their results to OOPSLA conference in that year. Design patterns gained popularity in Computer Science after the book Design Patterns: Elements of Reusable Object-Oriented Software was published in 1994 by the so-called "Gang of Four". 

There are 23 design patterns. We can divide them into three categories on their specifications as follows,
  • Creational patterns
  • Structural patterns
  • Behavioral patterns 

Followings are the design patterns which are belong to above categories,

# Creational design patterns
- All about class instantiation.
  • Abstract Factory
    - Creates an instance of several families of classes
  • Builder
    - Separates object construction from its representation
  • Factory Method
    - Creates an instance of several derived classes
  • Object Pool
    - Avoid expensive acquisition and release of resources by recycling objects that are no longer in use
  • Prototype
    - A fully initialized instance to be copied or cloned
  • Singleton
    - A class of which only a single instance can exist

# Structural design patterns
- All about Class and Object composition.
  • Adapter
    - Match interfaces of different classes
  • Bridge
    - Separates an object’s interface from its implementation
  • Composite
    - A tree structure of simple and composite objects
  • Decorator
    - Add responsibilities to objects dynamically
  • Facade
    - A single class that represents an entire subsystem
  • Flyweight
    - A fine-grained instance used for efficient sharing
  • Private Class Data
    - Restricts accessor/mutator access
  • Proxy
    - An object representing another object

# Behavioral design patterns
- All about Class's objects communication.
  • Chain of responsibility
    - A way of passing a request between a chain of objects
  • Command
    - Encapsulate a command request as an object
  • Interpreter
    - A way to include language elements in a program
  • Iterator
    - Sequentially access the elements of a collection
  • Mediator
    - Defines simplified communication between classes
  • Memento
    - Capture and restore an object's internal state
  • Null Object
    - Designed to act as a default value of an object
  • Observer
    - A way of notifying change to a number of classes
  • State
    - Alter an object's behavior when its state changes
  • Strategy
    - Encapsulates an algorithm inside a class
  • Template method
    - Defer the exact steps of an algorithm to a subclass
  • Visitor
    - Defines a new operation to a class without change

Thanks for reading, if you have any ideas, doubts please comment below. In my next design pattern article I'll discuss about above three design pattern categories and more about abstract factory. Thanks, see you again, bye.
5 {foss}-4ever: Software design patterns 01 Hi guys, welcome back. After several weeks today I'm going to write something about software design patterns. This is an in...

No comments:

Post a Comment

< >