Types of design patterns in details
- Structural design patterns
- 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
- Creational design pattern
- 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
- Behavioral design patterns
- 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
Popular design pattern
- Factory Design Pattern
- Abstract factory
- Interface factory
- Concrete factory
- Lazy Load Design pattern
- Singleton
- Repository pattern
- Prototype
SOLID Principles in
C#
Is also a design pattern technique defined in 1990 by Robert C martin.
●
S: Single
Responsibility Principle (SRP)
○
SRP says "Every software module should have only
one reason to change".
○
This means that every class, or similar structure, in
your code should have only one job to do.
●
O: Open
closed Principle (OSP)
○
says "A software module/class is open for
extension and closed for modification".
●
L: Liskov
substitution Principle (LSP)
○
It states that "you should be able to use any
derived class instead of a parent class and have it behave in the same manner
without modification" in short derived classes should be perfectly substitute of their base classes.
●
I: Interface
Segregation Principle (ISP)
○
Developer should
not forced to implement one big interface.
○
Instead of one fat interface many small interfaces are
preferred based on groups of methods, each one serving one sub module.
●
D:
Dependency Inversion Principle (DIP)
○
It states that high-level modules/classes should not
depend upon low-level modules/classes. Both should depend upon abstractions.
Software development approaches:
- Waterfall Model
- Incremental model (Agile)
- Iterative Model
- Spiral approach
- Vmodel
- Agile based on Incremental
- Waterfall Model
- Incremental model (Agile)
- Iterative Model
- Spiral approach
- Vmodel
- Agile based on Incremental
