There are many design principles that have become best practices over the years. Using these principles we can develop scalable and maintainable enterprise application with time tested approaches.
Encapsulation
Various parts of the application should use encapsulation to protect them from other parts of the application. Proper use of encapsulation helps to achieve loose coupling and modularity in application designs, because objects can be replaced with alternative implementation if they are sharing the same interface.
In classes, it is achieved by limiting outside access to the class’s internal state using methods or public property setters. So direct access to the private state of the object is restricted.
Similarly, applications or application components should expose well defined interfaces for their users and restricting them from modifying the internal state directly.
This design principle frees internal design to evolve over the time without affecting it’s users.
Keep It Simple Stupid (KISS)
KISS, an acronym for keep it simple, stupid, is a design principle noted by the U.S. Navy in 1960. The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided.
The main goal here is keep things simple. Avoiding unnecessary complexity will help to keep it clear and easy to understand. Also this principle will help in maintenance; if it is simple then also easy to modify. Usually the simplest solution is the best solution.
Don’t Repeat Yourself (DRY)
This principle states to not repeat things. We can abstract out repeated things and keep it at some common place where everybody can access it. We can also make common (repeating) things as general, so that it is available to all. It’s main aim is to reduce repetition of software patterns, replacing it with abstractions or using data normalization to avoid redundancy.
Separation of Concerns (SoC)
Separating things into discrete responsibilities increases re-usability, maintenance and also testability. Here concerns refer to specific features or behavior of the system. For example, Object Oriented programming languages such as C++, C# and Java (to name a few) can separate concerns into objects.
A Design Pattern like MVC (Model-View-Controller) can separate content from presentation and data processing (model) from content. Service Oriented design can separate concerns into services. Procedural programming languages such as ‘C’ can separate concerns into procedures. Aspect Oriented programming languages can separate concerns into aspects and objects.
The Pareto Principle
The famous Pareto principle states that 80% of effects comes from 20% of causes, i.e. 80% of sales comes from 20% of customers. The principle is named after Italian economist Vilfredo Pareto, who observed in 1906 that 80% of land in Italy is owned by 20% of the population. It can help to resist efforts to correct and optimize designs beyond critical 20%. So 80% focus is on 20% part of the stuff.
In software engineering Pareto principle can be applied to optimization efforts. For example, Microsoft noted that by fixing the top 20% of the most reported bugs, 80% of the errors and crashes would be eliminated.
The Robustness Principle
The Robustness Principle states that, “Be liberal in what you accept, and be conservative in what you send”. In other words, code that sends commands or data to other parts of the system should conform completely to the specifications, but code that receives input should accept non-conformant input as long as the meaning is clear.
For example, TCP protocol implementation follows the robustness principle.
You Ain’t Gonna Need It (YAGNI)
It is the principle in extreme programming, states that programmers should not add functionality until it is necessary. It tells programmers that always implement things when you actually need them, never when you just foresee that you need them. Even if you are sure that you will need it later on, do not implement it now. The principle is actually emerged from “Extreme Programming”
methodologies.
Loose Coupling and High Cohesion
Coupling means links between separate units of a program. In Object Oriented Programming (OOPs), if two classes depend closely on many details of each other, we say they are tightly coupled.
Coupling is a measure of the interdependence between types/entities. If every object has a reference to every other object, then there is tight coupling, which is undesirable. Because there’s potentially too much information flow between objects. Loose coupling is desirable. It means that objects work more independently of each other. Loose coupling minimizes the “ripple effect” where changes in one class cause necessity for changes in other classes.
Cohesion refers to the number and diversity of tasks that a class is designed for. If a class is responsible for a few related logical tasks, we say it has high cohesion.
Cohesion is a measurement of strengths of the association of variables and methods within a class. High cohesion is desirable because it means the class does one job well. Low cohesion is undesirable because it indicates that there are elements in the class which have little to do with each other. Modules whose elements are strongly and genuinely related to each other are desired. Each method should also be highly cohesive. Most methods have only one function to perform. Don’t add extra instructions into methods that cause it to perform more than one function.
Loose Coupling has following advantages:-
- We can understand concerned class without reading other classes
- We can change one class without affecting other classes
- Loose Coupling improves maintainability
High Cohesion has following advantages:-
- We can easily understand what is the purpose of class or method
- High Cohesion makes it easier to use descriptive names
- We can easily reuse classes or methods
SOLID Principles
Single Responsibility Principle (SRP)
The Principle states that every object should have single responsibility, and the responsibility (reason to change) should be entirely encapsulated by the class. So a class or module should have one and only one reason to change.
For example, we have a print report module. There are utmost two reasons to change the module. First is content of report is changed. Second is format of report is changed.
Open Closed Principle (OCP)
Software entities (i.e. classes, functions or modules) should be open for extension but closed for modification. Normally we close entities modification for providing backward compatibility (regression testing) and open entities extension for extending existing entities with new functionalities.
For example, we can implement this principle by using Abstract classes, and thus enforcing concrete classes extend abstract classes rather than changing it. Some of the design patterns that supports this principle is template pattern and strategy pattern.
In .NET Framework Microsoft has further supported this principle by providing partial classes/methods and extension methods. You can extend existing code by using these two new features in .NET.
Liskov’s Substitution Principle (LSP)
The principle states that derived types must be completely substitute-able for their base types. It is just an extension of Open Closed Principle in terms of behavior. Meaning that the derived types must extend without changing behavior of base types, so that derived types is replaceable with base types (No need to change code).
Interface Segregation Principle (ISP)
In nutshell, the principle states that “Clients should not be forced to depend upon interfaces that they don’t use”. When we simplify it states that when interface is too heavy, just break it down to the smaller and more specific interfaces which is client oriented so that clients should only worry about their concerned part.
For example if we have one interface which has “fly()” method and is implemented by Duck class. Now if we have wooden duck ?
Dependency Inversion Principle (DIP)
Also known as Inversion of Control or Hollywood Principle: Don’t call us, we’ll call you or Dependency Injection.
The Dependency Inversion principle refers to specific form of decoupling where conventional dependency relationship established from high level. The principle states two things.
- High-level modules should not depend on low-level modules. Both should depend on abstractions.
- Abstractions should not depend upon details. Details should depend upon abstractions.
The main goal of dependency inversion principle is to decouple high-level components from low-level components in such a manner that reuse of low-level component implementations become possible.
For example Adapter Pattern does the same thing. The high-level class defines its own adapter interface which is the abstraction that the high-level class depends on. The adaptee implementation also depends on the adapter interface abstraction. The high-level has no
dependency to the low-level module since it only uses low-level indirectly through the adapter interface by working polymorphic methods to the interface which are implemented by the adaptee and its low-level module.
Bounded Context
It is a central pattern in Domain-Driven Design. Bounded Context is a logical boundary. It provides a way to handle complexity in large applications or organizations by breaking it up into separate conceptual modules. Each conceptual module then represents a context that is separated from other contexts (bounded), and can evolve independently.
Individual web applications should strive to be their own bounded context, with their own persistence store for their business model, rather than sharing a database with other applications. Communication between bounded contexts occur through programmatic interfaces, rather than through shared database, which allows for business logic and events to take place in response to changes that take place.
Bounded contexts map closely to microservices, which also are ideally implemented as their own individual bounded contexts.
Persistent Ignorance (PI)
The Persistent Ignorance principle states that the classes that modeling the business domain in a software application should not be impacted by how they might be persisted.
So, the software design will remain as close as possible to the ideal design needed to solve the problem and it won’t be tainted by concerns like how object’s state is saved and later retrieved.
Such types in .NET are sometimes referred to as Plain Old CLR Objects (POCOs), because they don’t need to be inherited from a particular base class or to be implemented a particular interface. It allows the same business model to be persisted in multiple ways, offering additional flexibility to the application.