Building Better Software

Software design principles are fundamental guidelines that help developers create robust, maintainable, and scalable applications.

Separation of Concerns is the idea that a software system should be divided into parts with minimal overlap in functionality. For example, the code that handles the user interface should be separate from the code that handles business logic, which in turn should be separate from the code that accesses the database. This makes the system easier to manage because changes in one part are less likely to break another.

S: Single Responsibility Principle (SRP)

A class should have one, and only one, job. This means it should have only a single reason to change. If a class is responsible for both calculating employee salaries and saving employee data to a database, it has two responsibilities. A change in the tax calculation logic would require modifying the class, and so would a change in the database system. It's better to have a SalaryCalculator class and a separate EmployeeRepository class. Each has a single responsibility.

O: Open/Closed Principle (OCP)

Software entities (like classes or modules) should be open for extension, but closed for modification. This sounds like a contradiction, but it's not. It means you should be able to add new functionality without changing existing, working code. You can achieve this using techniques like inheritance or interfaces. For example, if you have a system for generating reports, you shouldn't have to edit the main report generator class every time you want to add a new format (like PDF or XML). Instead, you should be able to create a new class for each format that extends the base functionality.

L: Liskov Substitution Principle (LSP)

This principle states that objects of a superclass should be replaceable with objects of its subclasses without breaking the application. In simpler terms, if class B is a subclass of class A, you should be able to pass an object of class B to any method that expects an object of class A and have it work correctly.

A classic example is the rectangle/square problem. A square is a rectangle, so it seems logical to make Square a subclass of Rectangle. But a Rectangle has separate setWidth and setHeight methods. If you set the width of a Square object to 5 and its height to 10, what should happen? The object would no longer be a square. This violates the principle because a Square object doesn't behave like a Rectangle object in all cases.

I: Interface Segregation Principle (ISP)

Clients should not be forced to depend on interfaces they do not use. This means that large, “fat” interfaces should be split into smaller, more specific ones. Imagine an interface for a Worker that has methods for work() and eat(). A HumanWorker can do both. But what about a RobotWorker? A robot works but doesn't eat. Forcing the RobotWorker class to implement the eat() method is awkward. The solution is to segregate the interface into a Workable interface and an Edible interface. Classes can then implement only the interfaces they need.

D: Dependency Inversion Principle (DIP)

High-level modules should not depend on low-level modules. Both should depend on abstractions. Also, abstractions should not depend on details; details should depend on abstractions.

This means that the parts of your code that orchestrate business logic (high-level) shouldn't be directly tied to the specific tools you use for things like databases or sending emails (low-level). Instead, both should depend on a common abstraction, like an interface. For example, a NotificationService shouldn't directly create an EmailSender object. Instead, it should depend on an IMessageSender interface. This allows you to easily swap out EmailSender for an SMSSender or a PushNotificationSender without changing the NotificationService at all.