Imagine that we have a program, some part of which somehow manipulates doors. Here are some parts of a few modules of this program.
Is there anything you want to improve?
# List of potential issues
* Class Door has own method to convert itself to string representation. It breaks SRP.
* Is it easy to extend the class Door? What if I want to represent door elements with a different colors? Partially breaks O of SOLID, but it highly depends on an architecture.
* Should the state of this class keep both open/close sign and a color as a part of its state? Why, in which cases? How to improve it?
* Method open in the class ClosedDoor breaks contract of class Door. It extends exception specification. Breaks L of SOLID.
* Modules 3 and 4 (that processes doors) work with classes, not with interfaces. For example, method “open” might work with IOpenable interface. Ask candidate, what if I also want to open a window, not just a door? This part breaks both I and D of SOLID.
* Method repaintOpenDoors shouldn’t exist at all: it should be a function that applies an operation based on a predicate. Or, even, better a ranges-like pipeline! To properly implement it, class Door should be extended.
* There are also raw pointers and missing null checks, but who cares… Design example! Though, there are might be bonus points anyway!
