Skip to content

safa-abidi/Lab1-Software-Architecture

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

6 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

SOLID Principles

This work was done in the first Software Architecure lab.

SRP (Single Responsability Principle):

  • Problem:

    SRP_prob

    Each class should have one responsibility. The CarManager class includes data as well as 3 methods getCarNames() , getBestCar(), getCarById() which makes it vulnerable to too much modification when we want to change these methods. The SRP states that a class should have one and only one reason to change.

  • Solution:

    SRP_sol

    We have applied SRP so that the class CarDao contains the array of cars, CarRater implements the method getBestCar() and CarFormatter implements getCarsNames().

OCP (Open Closed Principle):

  • Problem:

    OCP_prob

    ResourceAllocator contains all the logic and functionalities of Time and Space. Modifying any existing method or adding a new one (for a new resource for example) implies a change of the whole class. The OCP states that a class should be open for extension but closed for modification.

  • Solution:

    OCP_sol

    So we created an interface IResource and classes that implement it. Each future modification only results in changes in the corresponding class.

LSP (Liskov Substitution Principle):

  • Problem:

    LSP_prob

    Calling quack() or swim() for electronicDuck causes exceptions. The LSP states that a subclass should be able to replace its superclass without any unexpected behavior.

  • Solution:

    LSP_sol

ISP (Interface Segregation Principle):

  • Problem:

    ISP_prob

    The Door interface has 2 methods timeOutCallback() and proximityCallback(). Timer only uses the timeOutCallback() method and Sensor only uses the proximityCallback() method. The ISP states that a client should not be forced to depend on methods it does not use.

  • Solution:

    ISP_sol

    We apply ISP to distinguish 2 types of Doors. Each implements the method it needs.

DIP (Dependency Inversion Principle):

  • Problem:

    DIP_prob

    EncodingModule depends on MyDatabase. If we want to change the database, we will have to modify EncodingModule. The DIP states that high level classes should not depend on low level classes but on abstractions.

  • Solution:

    DIP_sol

    To remedy this, we created an interface Database that MyDatabase implements and that EncodingModule uses.

About

First Software Architecture Lab, about SOLID principles

Topics

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages