Interview Skills - SOLID principals in 21(ish) seconds
I'm showing my age here, but if like me you remember the 2001 classic "21 seconds" by So Solid Crew, then you know the importance of being able to say a lot in a short amount of time.
Interviewing for Development roles is somewhere that skill can be highly useful, especially when answering questions about SOLID Principals of Object Oriented design, so lets take a few (not 21) seconds to refresh our memories and ensure we can explain these five principals succinctly.
Why are SOLID principals important in interview?
"To create understandable, readable, and testable code that many developers can collaboratively work on."
Essentially, Interviewers are assessing if you join a new team will you be able to understand the existing code base and will you add to it in a way that other Developers will be able to follow your logic.
Let's look at each principle in the SOLID acronym, they are:
The Single Responsibility Principle
The Single Responsibility Principle states that?a class should do one thing and therefore it should have only a single reason to change.
In other words, only one potential change in the specification should be able to affect the specification of the class.
Why is this important?
Multiple teams can work on the same project and edit the same Class for different reasons, this could lead to incompatible modules.
As a bonus, it makes version control much easier and reduces the risk of merge conflicts.
Open-Closed Principle
The Open-Closed Principle requires that?classes should be open for extension and closed to modification.
In other words, you should be able to add new functionality without touching the existing code for the class
Why is this important?
Whenever we modify the existing code, we risk introducing bugs so we should avoid touching production code where possible. Adding functionality through interfaces and abstract ?classes is a much safer option.
领英推荐
Liskov Substitution Principle?
The Liskov Substitution Principle states that subclasses should be substitutable for their base classes.
This means that, given that class B is a subclass of class A, we should be able to pass an object of class B to any method that expects an object of class A and the method should not give any weird output in that case.
Why is this important?
Because when we use inheritance we assume that the child class inherits everything that the superclass has. The child class extends the behavior but never narrows it down.
Therefore, when a class does not obey this principle, it leads to some nasty bugs that are hard to detect.
Interface Segregation Principle
The principle states that many client-specific interfaces are better than one general-purpose interface.
Why is this important?
Clients should not be forced to implement a function they do not need and in doing so they can create complexity that can create problems down the line.
By separating the interfaces the solution is more flexible, extendable while retaining the logic and functionality required.
Dependency Inversion Principle
The Dependency Inversion principle states that our classes should depend upon interfaces or abstract classes instead of concrete classes and functions.
"If the OCP states the goal of OO architecture, the DIP states the primary mechanism".
Why is this important?
This is related to the open-Closed Principal, We want our classes to be open to extension, so we should reorganize our dependencies to depend on interfaces instead of concrete classes.
Conclusion
So hopefully you’ve found that a useful refresher in SOLID Principals that will likely come up in any Software interviews.
By applying them to your own work when developing and refactoring code you’ll create code that’s cleaner, more extendable and testable too, making your life (and your co-workers by extension) that little bit easier.
To paraphrase Romeo Dunn “2 multiplied by 10 plus 1…. Refresher DONE”