The Observer pattern is a behavioral design pattern that defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.
In a simple words, it is like a publisher and subscriber pattern. When publisher publishes something, all it’s subscriber gets notified.
One Example could be, when we subscribe someone’s mailing list we get notified whenever the publisher publishes something.
[Read More]
The Abstract Factory pattern is a creational design pattern that provides an interface for creating families of related or dependent objects without specifying their concrete classes. It allows a client to create objects from a variety of related classes without needing to know the specifics of their implementations.
Let’s say, we need to create GUI components for different themes in our application. Each theme includes a consistent set of components such as buttons and checkboxes. We want to ensure that the creation of these components is consistent and interchangeable.
[Read More]
The Factory Method Pattern is a creational design pattern that provides an interface for creating objects in a superclass but allows subclasses to alter the type of objects that will be created.
This pattern is useful when a class cannot anticipate the class of objects it needs to create or when subclasses want to specify the objects to be created.
Imagine we need to develop a notification system that can send different types of notifications such as Email, SMS, and Push Notifications. Each type of notification has a distinct implementation but shares a common interface. Instead of creating each notification type directly in our main logic, we can use the Factory Method Pattern to encapsulate the instantiation process, making our code more modular and extensible.
[Read More]
Aggregation is when an object is made up of one or more objects, but those objects can live outside the main object. It defines the has-a relationship.
Note: In the aggregation, if main object is destroyed, its aggregated objects may still live.
Example #1: A Library is an aggregation of Books. Books can live without the library.
Example #2: A Department is an aggregation of Employees. If department closes, the Employees can exist on their own.
Composition is when your class is composed of one or more objects from other classes. A simple example is a Car composed of Engine and Wheel objects. Inheritance defines an “is-a” relationship, while composition defines a “has-a” relationship.
For example, Dog is-a Animal, and Circle is-a Shape. It defines inheritance.
This makes sense because you want to reuse all the features of Animal (eat, sleep, walk, makeNoise) in the Dog class. Cow is-a Animal too, so Cow can also inherit the Animal class. Since cows and dogs make different noises and eat different things, we have to redefine or override the makeNoise() and eat() methods in the Dog and Cow classes. The point is when we want to reuse the functionality of a class and also want subtype polymorphism (Dog and Cow are subtypes of Animal), then we must use inheritance.
The Dependency Inversion Principle states that:
Source: Wikipedia
Other SOLID Principles
public class UserRepository
{
public string GetUserById(int id)
{
// Code to fetch user from the database
return "User";
}
}
public class UserService
{
private readonly UserRepository _userRepository;
public UserService()
{
_userRepository = new UserRepository();
}
public string GetUser(int id)
{
return _userRepository.GetUserById(id);
}
}
One problem with this code is , theUserService is tightly coupled with the UserRepository. Another problem is, if you want to use different implementation of UserReposoitory, you can not easily do it. For instance you want to swap your UserRepsoitory to UserRepositoryWithDifferentDatabase.
📢 Clients should not be forced to depend on interfaces they do not use.
In simpler terms, this principle suggests that an interface should not include methods that implementing classes don’t need. It Encourages us to create smaller interfaces over the big fat interface.
Other SOLID principles
Imagine you have an interface for workers in a company:
[Read More]
The Liskov Substitution Principle states that a derived type should be completely replaceable for its base type.
In simpler terms, a child class should do at least what the parent class can do. The child class can have additional behaviors, but it must have all the behaviors that the parent class has.
For instance, an Animal has behaviors (eat, sleep, makeSound). A Dog, which is a subtype of Animal, must have all the behaviors (eat, sleep, makeSound).
[Read More]
The Open-Closed Principle is one of the five SOLID principles. It states that a class should be open for extension but closed for modification. In other words, you should be able to add new functionality without changing existing code.
Once you have written your class, it should not be modified in the future. However, this doesn’t mean you cannot modify your class during early development stages. It means that once your application or software is in production and you want to introduce the new functionality, you should extend that class rather than modifying it.
[Read More]
The Single Responsibility Principle (SRP) is a cornerstone of object-oriented design, closely associated with the SOLID principles. It emphasizes that a class should have only one reason to change, meaning it should have a single responsibility or purpose.
The principle asserts that a class should do only one thing and do it very well. This doesn’t imply that a class should have only one method or behavior, but rather that it should contain a cohesive set of behaviors related to a single responsibility.
[Read More]