A single class must have a single responsibility, something like abstracting a single business entity or a single communication protocol. It does not matter how easy creating such an entity is or how much coding such an entity needs. This is because if a single class tries to abstract multiple entities, it would be unable to actually abstract any of those entities proposed. This does not mean that multiple classes abstract entities that are more specific. For example, applying an inheritance principle does not inherit a single and a more abstract class (the mother class).

This principle states that a class must be open for extension and closed for modification. This is an important principle regarding teamwork and code lifetime management. If a class never changes its contract (public shape) but still grows up in functionality, it then maintains compatibility with the older versions. Later in this chapter, in the Common designs and architectures section, we will see how this principle is also applicable in specific high-distributed architectures such as the n-tier or Service Oriented Architectures.

This principle states that wherever an object is used, a subtype must be used in the same place, without ever changing any code and without having any different behavior in the application. This tenet extends the OOP inheritance principle by giving us a direct test case to validate how inheritance is applied to our class hierarchy.

This principle states that a role interface must be created, based on what a client (the caller of the methods of any object) needs with no more logic (methods) or properties than effectively required. These interfaces help software decoupling between modules, module management, and development because it splits the contract (the shared need of a client in the form of a C# interface) from the concrete implementation. Like creating a facade, this principle helps to simplify the shape of the object to its clients and helps move concrete logic from different classes, if needed, without (actually decoupling) any change in the client usage.

This principle extends the preceding interface segregation principle by stating that better decoupling and management of software modules happens by inverting references between objects. Without this principle, multiple modules calling each other at the same or from different levels will make up the software. Although abstraction is practically nothing at some level, such as when developing a module with, for instance, classes for low-level network communication, for most other modules, abstraction is significantly useful for reducing coupling. For instance, with a strait dependency, a desktop application using this module will contain a UX module that calls business logic in one module and that in turn calls another system by using another module (A -> B -> C).

By inverting the dependency, we will find that module A asks for another module (without knowing the concrete name/implementation) that extends any interface that A needs. The same occurs between module B and the unknown module C, when B asks for a module to implement its needs (module C). A practical implementation of this scenario is the plugin pattern or the Inversion of Control (IoC) with the Dependency Injection (DI) pattern.

By respecting this principle, the improved decoupling is visible. Less visible is the little drawback this solution has. If used extensively, this solution could create some performance issues, such as added latency and higher resource usage that came from data-mapping usage. Later in this chapter, we will see a case study on Dependency Injection.