Software Design Principles

A software design principle is a compilation of rules and best practices that help developers organize, maintain, and build effective software systems. With such principles, the code that is produced is easy to comprehend, modify, or expand, which improves the quality of the software over time.

These rules are also very important for best practices in object-oriented design, clean code, and software architecture.

The key objectives of software design principles include:

• Encouraging code reusability and modularity.
• Promoting loose coupling between components or modules.
• Ensuring code readability and understandability.
• Enhancing testability, maintainability, and scalability.
• Facilitating effective collaboration among team members.

Several well-known software design principles are:

1. SOLID: A set of five object-oriented design principles that focus on creating maintainable and scalable code.
2. DRY (Don't Repeat Yourself): A principle that emphasizes avoiding code duplication to reduce maintenance complexity and potential inconsistencies.
3. KISS (Keep It Simple, Stupid): A principle that encourages simplicity in code and design, avoiding unnecessary complexity.
4. YAGNI (You Aren't Gonna Need It): A principle that advises developers to focus on delivering the features that are currently needed, rather than over-engineering or anticipating future requirements.
5. Composition Over Inheritance: A design principle that encourages the use of composition (combining simple objects to create more complex ones) instead of inheritance (creating new classes by inheriting properties and methods from a parent class) for code reuse and extensibility.
6. Law of Demeter (Principle of Least Knowledge): A principle that promotes reducing coupling between components by limiting the knowledge an object has about other objects in the system.

SOLID Principles

It is correct to state that SOLID – is a collection of principles that assist developers in building object-oriented software systems that are easy to maintain, scale, and are efficient. With these principles, a programmer is guided in achieving the most basic requirements of writing software – writing code that can be read easily, understood, modified, and extended. Following these principles allows developers to build and maintain a robust, stable, low-defect, and easy-to-refactor codebase. Implementing SOLID principles enables software to be better in many ways and make the software adaptable to changing needs, improve quality, and enhance collaboration within the team.

SOLID?is an acronym that represents five fundamental principles:

1. Single Responsibility Principle (SRP)
2. Open-Closed Principle (OCP)
3. Liskov Substitution Principle (LSP)
4. Interface Segregation Principle (ISP)
5. Dependency Inversion Principle (DIP)

?

Single Responsibility Principle (SRP)

Definition: The Single Responsibility Principle states that a class should have only one reason to change, meaning it should have just one responsibility. In other words, each class should focus on a single task or concern to make the code more maintainable and understandable.

HRM Example:

• Separate classes for: EmployeeOnboarding: Handles new hire documentation. PayrollProcessor: Manages salary calculations. PerformanceReview: Tracks employee evaluations.

Benefits:

• Changes to payroll logic won’t affect onboarding.
• Clearer debugging for performance reviews.

?

By following the Single Responsibility Principle, you can design classes that are easier to understand, maintain, and modify.

?

Open-Closed Principle (OCP)

Definition: The Open-Closed Principle states that software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. In other words, you should be able to add new functionality to a class without modifying its existing code, by extending it or using other mechanisms like composition.

HRM Example:

• Base class?LeaveRequest?with methods?approve()?and?calculateDays().
• Extend for specific leave types without altering the base:

?

Benefits:

• Add new leave types (e.g., parental leave) without breaking existing code.

?

By following the Open-Closed Principle, you can design classes that are flexible and easy to maintain.

Liskov Substitution Principle (LSP)

Definition: The Liskov Substitution Principle states that objects of a derived class should be able to replace objects of the base class without affecting the program's correctness. In other words, derived classes should adhere to the behavior and contracts defined by the base class.

HRM Example:

• Base class?Employee?with method?calculateSalary().
• Subclasses?FullTimeEmployee?and?ContractEmployee?must implement?calculateSalary()?consistently.

Violation: A?ContractEmployee?subclass that removes?calculateSalary()?would break LSP.

Benefits:

• Ensures payroll systems work for all employee types.

By following the Liskov Substitution Principle, you can design class hierarchies that are consistent, maintainable, and reusable. Remember that LSP is a guideline to help you create better abstractions and more reliable code, but it's essential to consider the specific context of your project to apply it effectively.

?

Interface Segregation Principle (ISP)

Definition:?The Interface Segregation Principle states that clients should not be forced to depend on interfaces they do not use. In other words, large interfaces should be split into smaller, more specific ones so that a class implementing the interface only needs to focus on methods that are relevant to its functionality.

HRM Example:

• Split a bulky?Employee?interface into: Payable: For salary processing. Trainable: For skill development. Promotable: For role upgrades.
• An?Intern?class implements?Trainable?but not?Payable.

Benefits:

• Prevents interns from accidentally accessing payroll methods.

When you apply the Interface Segregation Principle, you make it possible to create more precise, manageable, and adaptable classes and interfaces. Always keep your project in mind and try to balance the need for precise focused interfaces against the risk of having too many fragmented ones.

?

Dependency Inversion Principle (DIP)

Definition:?The Dependency Inversion Principle states that high-level modules should not depend on low-level modules; both should depend on abstractions. Furthermore, abstractions should not depend on details; details should depend on abstractions. In simple terms, this principle encourages you to depend on abstract interfaces rather than concrete implementations, promoting loose coupling and better separation of concerns.

HRM Example:

• High-level?HRReportGenerator?depends on an?EmployeeRepository?interface.
• Low-level classes?DatabaseEmployeeRepository?or?CloudEmployeeRepository?implement the interface.

Benefits:

• Switch from a local database to cloud storage without rewriting report logic.

By following the Dependency Inversion Principle, you can create code that is more flexible, maintainable, and testable.

?

DRY (Don’t Repeat Yourself)

Example:

• Reuse a?NotificationService?class to send emails/SMS for: Payroll alerts. Leave approvals. Training reminders. Benefits:
• Centralized changes to notification templates.

KISS (Keep It Simple, Stupid)

Example:

• An?EmployeeProfile?class stores only essential fields:

·??????? Avoid adding unnecessary fields like?favoriteColor.

Benefits:

·??????? Simplifies data retrieval for HR dashboards.

YAGNI (You Aren’t Gonna Need It)

Example:

• Skip building a?SabbaticalLeave?class unless explicitly required. Benefits:
• Avoids overcomplicating the leave management system.?

Composition Over Inheritance

Example:

• Use composable roles instead of inheritance:

Benefits:

• Employees can switch roles dynamically without class hierarchy changes.

Law of Demeter (Principle of Least Knowledge)

Example:

Benefits:

• Reduces coupling between?HRService?and?Department?classes.