Skip to content

Design Principles Exercise

Tip

These exercises are examples of the kind of questions you can expect in the quiz.

Exercise 1

Consider the following partial design of an application.

Can you identify cases where SOLID design principles is applied/violated?
  • Single Responsibility Principle
    • There seems to be a good separation and isolation of responsibilities between the CoffeeApp and different types of CoffeeMachine.
  • Open/Closed Principle
    • Adding new types of coffee machines will not require any modification to existing ones. (I.e. app is open for extension but closed for modification.)
  • Liskov Substitution Principle
    • There is not enough information to consider the application of this principle. Based on the diagram, it seems every subtype is substitutable for their parent type.
  • Interface Segregation Principle
    • The responsibilities of CoffeeMachine is broken down into FilterCoffeeMachine and EspressoCoffeeMachine (more granular interfaces to prevent a bloated CoffeeMachine interface).
  • Dependency Inversion Principle
    • High-level classes (e.g. CoffeeApp) does not depend on low-level classes (e.g. BasicCoffeeMachine); instead they both depend on abstractions (i.e. CoffeeMachine interface).

Exercise 2

Download this codebase which implements the game of Blackjack. Consider the high-level design of the application.

Can you identify cases where SOLID design principles is applied/violated?
  • Single Responsibility Principle
    • A Card class holds information about a playing card as well as how it is displayed in the application's GUI (i.e. ImageIcon field); it might make for a better design if the GUI related stuff were not tightly coupled together with model entities.
    • On the previous note, the application's design can certainly improve (in terms of separation of responsibilities) if the MVC pattern were to be applied to it.
  • Open/Closed Principle
    • The Deck and Hand classes are tightly coupled to the logic of the game (i.e. the constructor of Deck creates 52 standard playing cards where the value assigned to each card is based on the rules of Blackjack); in addition to violating the Single Responsibility Principle, any modification to the game rules, or extension to the application (e.g. to support different versions of Blackjack or different card game) will (likely) require modifying the Deck and Hand classes. The latter is a violation of the Open/Closed Principle.
  • Liskov Substitution Principle
    • There is no violation nor application of this principle (sub-typing is not employed here).
  • Interface Segregation Principle
    • There is no violation nor application of this principle (abstraction--in the form of creating interfaces--is not employed here).

  • Dependency Inversion Principle

    • High-level classes such as Blackjack directly depend on the low-level classes like Deck and Hand. It might make for a better design if an abstraction were to be introduced between them to change the direction of dependency: