SOLID Principles

Single Responsibility Principle: A class should be limited to a single responsibility. There should be one and only one reason to change a class.

  • Supported by

Open/Closed Principle: Class should be open for extension but closed for modification.

  • This is supported by Decorator pattern which allows:
    • to dynamically add behaviours to an existing class
    • incremental extension of target class and it’s decorators too
    • uses composition and avoids class explosion
    • Related patterns for decorator: Adapter, Composite, Facade, Bridge, Flyweight, Proxy

Liskov’s Substitution Principle: Subclasses can be substituted instead of their base class (OR interfaces). This ensures inheritance is used properly, we don’t build dependencies on subclasses but on abstract-tions (interfaces) and the system can fail gracefully.

Interface Segregation Principle:

Dependency Inversion Principle: Systems/classes should depend on abstractions instead of concretions.

  • This is supported by IOC containers and Service Locator pattern.

 

Design patterns and their use cases:

Decorator Pattern: To dynamically add properties/behaviour onto classes without modifying them. These decorators are then substitutable for the classes they decorate.

Facade Pattern: To simplify a complex/poorly designed API (or SET OF APIs) by orchestrating/wrapping/aggregating interactions. e.g. Data Access facade (hides the multiple complex steps required to access data stores) – ADO.NET was a facade for RawSql ODBC. Or a FileSystem provider could be a Facade for an OS independent file system access (providing a simpler/abstracted API for an entire subsystem). However, we normally don’t have a strict facade interface to provide/expose. Is that strictness was mandated in for a facade, then that facade would also be an ADAPTER since it is adapting one interface to another(one or more). Related patterns: Adapter, Flyweight, Mediator.

WIDELY used patterns:

  • MVVM, Decorator, Facade, Proxy, Service Locator, Adapter, Lazy Load, Abstract Factory, Iterator, Composite, Builder, Observer (events/delegates and or pub/sub), Repository, Singleton (IOC container is mostly instantiated as a singleton to manage registrations and object lifetimes), Strategy, Unit of Work (or Use Case pattern),
Leave a Reply

Your email address will not be published. Required fields are marked *