SOLID Simplified - Software Design Fundamentals

Explain that a class should have one responsibility, not one method. Show why calculateBonus belongs to HR, not the employee class, highlighting one reason to change.

Explore how violating the single responsibility principle creates a rigid and fragile design, demonstrated by the Employee class's trimID usage affecting HRPersonnel and FinanceCalculations when bonus logic changes.

Move unrelated responsibilities to dedicated classes to enforce single responsibility; HRPersonnel uses Employee, while FinanceCalculations uses EmployeeBenefits to compute bonuses.

Single responsibility means a module has one and only one responsibility. Methods do one task; components handle a single concern like configuration data, guided by cohesion.

Single responsibility principle means a class has one responsibility; changes for multiple reasons reveal SRP violations. Identify users to spot breaches, and apply refactoring to avoid rigid or fragile designs.

Apply the open-closed principle by extending functionality with new code, not by modifying existing modules, as shown by bonus and ESOP calculations based on grade versus merit.

Enforce the open-closed principle to keep existing functionality intact while adding new criteria, avoiding multiple software versions, costly maintenance, and fragile, hard-to-test changes.

Replace EmployeeBenefits class with an interface named IBenefitsCalculator, declare methods CalculateBonus and CalculateESOPs, implement GradeBasedCalculator and MeritBasedCalculator, and follow the open-closed principle.

this lecture demonstrates separating bonus and ESOP calculations into dedicated interfaces to achieve open closed principle compliance for varying criteria.

Review how the open-closed principle keeps modules open for extension and closed for modification by using interfaces over concrete implementations, enabling new functionality without changing existing code.

Explore the Liskov substitution principle by relating an employee and IBenefitsCalculator hierarchy through a grade-based calculator, and examine how introducing contractors can violate LSP when overridden methods throw exceptions.

Explore how type checks to avoid method exceptions reveal fragile inheritance, violate the open-closed principle, and risk breaking client code on base class references in solid design.

Examine how derived classes violate the Liskov substitution principle by tightening or relaxing preconditions and breaking input and return value contracts under design by contract.

Refactor the employee hierarchy by moving getGrade and isServingNotice to a Regular class. Enforce base class contracts and use derived references for predictable client behavior.

Master the Liskov Substitution Principle, ensuring derived classes remain substitutable for base classes and respect design by contract. Address violations by adjusting contracts or inheritance, and uphold open-closed principle.

Understand the interface segregation principle by analyzing a fat employee interface that forces dummy implementations for unused training methods, highlighting how distinct interfaces improve design and maintainability.

Examine the consequences of fat interfaces, including forced dummy implementations and violations of the Liskov substitution principle, causing rigidity and unnecessary dependencies when registerForTraining changes affect derivatives.

Move newly introduced methods to a separate ITrainee interface implemented by Regular and PartTime employees. HR personnel uses Employee references while the training system uses ITrainee, limiting changes to registerForTraining.

Explore interface segregation by modeling an employee as an interface with name, id, and address; avoid fat interfaces that cause Liskov substitution principle violations.

Apply the interface segregation principle to expose only interfaces clients use. Avoid unnecessary dependencies and relate to the Liskov Substitution Principle and the Single Responsibility Principle.

Examine the dependency inversion principle by showing how high level modules depend on abstractions rather than details, and how salary calculator relies on interface-based tax and bonus calculators.

The salary calculator's reuse hinges on the bonus interface, forcing organizations to take both libraries and showing how interface ownership can break reusability when lower-level modules change.

Revisit the solid principle definition by showing how high and low level modules depend on abstractions. Contrast interfaces with concrete implementations to highlight that abstraction should not depend on details.

Invert dependencies to maximize reuse by moving the abstraction, namely the bonus calculator interface, into the same library as the salary calculator, enabling independent implementations and stable interfaces.

Review how the dependency inversion principle uses abstractions to decouple high level and low level modules, showing how ownership of interfaces and open/closed principles affect reusability and true modularity.