SOLID

Today, I would like to take this opportunity reiterate that SOLID principle provide great benefits to the SharePoint development.

Lets review what SOLID stands for. The acronym SOLID is derived from the following phrases/principles in English:

Single Responsibility Principle: Each class should have a unique responsibility or main feature. In other words, one class should have only one reason that justifies performing changes on its source code. One consequence of this principle is that, in general, classes should have few dependencies on other classes/types.

Open Closed Principle: A class must be open for extension but closed for modification. That is, the behavior of a class should be able to be extended without requiring modifications on its code.

Liskov Substitution Principle: Sub-types must be able to be replaced by their base types (base class or interface). This stems from the fact that the behavior of a program that works with abstractions (base classes or interfaces) should not change because a specific implementation is replaced with another one. Programs should refer to abstractions, and not to implementations. We will see later that this principle is closely related to the Dependency Injection and substitution of some classes for others providing they meet the same interface.

Interface Segregation Principle: The class interface implementers should not be obliged to implement methods that are not used. This means the class interfaces should be specific depending on who consumes them and should therefore be split into different interfaces, and no large interfaces should be created. Classes should expose separate interfaces for different clients/consumers with differing interface requirements.

Dependency Inversion Principle: Abstractions should not depend on details; the details should depend on

abstractions. Direct dependencies between classes should be replaced by abstractions (interfaces) to allow top-down designs without the need to design the lower levels first.

Other key design principles

• The component design must be highly cohesive: do not overload the components by adding mixed or non-related functionality. For example, avoid mixing data access logic with business logic belonging to the Domain model. When functionality is cohesive, we can then create assemblies with more than one component and place them in the appropriate layers of the application. This principle is therefore closely related to the "N-layer" pattern and to the „Single Responsibility Principle‟.
• Keep the cross-cutting code abstracted from the application-specific logic: the cross-cutting code refers to horizontal aspect code, such as security, operations management, logging, instrumentation, etc. The combination of this type of code with specific implementation of the application can lead to designs that, in the future, are difficult to extend and maintain. The AOP (Aspect Oriented Programming) principle is related to this.
• Separation of Concerns: dividing the application in different parts and minimizing the overlapping functionalities between such parts. The key factor is to minimize the interaction points to achieve high cohesion and low coupling. However, separating functionality in the wrong boundaries can lead
  to a high degree of coupling and complexity among the characteristics of the system.
• Don‟t Repeat Yourself (DRY): the "intention" must be specified in only one part of the system. For example, in terms of an application design, a specific functionality should be implemented in only one component; the same functionality should not be implemented in other components.
• Minimize the top-down design (Upfront Design): design only what is necessary, do not perform "over engineering" and take into account the agile YAGNI principle („You Ain‟t Gonna Need It‟).

Next time you design SharePoint project, ask yourself a question: 

Is my application design and architecture SOLID?