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 Object Composition (Composites), Strategy/Template Pattern etc.
  • Key guidelines
    • clearly defined boundaries as to where a piece of functionality is “implemented”;
    • information-hiding in components that protect the integrity of data;
    • separation of concerns that ensures changes in one location do not affect others;

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. Also subtypes should not strengthen pre-conditions or weaken post-conditions.

Interface Segregation Principle: Interfaces should be client/consumer specific rather than being general.

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 *