Getting better at writing object-oriented code means practicing a lot, identifying common problems, and working to avoid them. The SOLID principles have been around for a long time and have served as a good set of guiding principles that lead you toward better object-oriented designs. In this series we will examine the SOLID principles and see how they apply to Swift.
Length: about 1 hour
This episodes kicks off a new series on SOLID principles for improving at object-oriented design. Writing better code means writing code that costs less to change, which can be a crucial factor in delivering project successfully. In this series we will see how these principles apply to Swift.
In this episode we'll examine a type that has too many responsibilities and refactor it into multiple types, each with their own responsibility.
The Open Closed Principle (or OCP) states that a class should be open for extension, but closed for modification. The goal is to write classes that are more stable, and don't require constant changes themselves to support every scenario the software encounters. Instead, having a stable class to inherit from can provide a nice extension point for our software to customize it for other needs.
In this episode we examine the Liskov Subtitution Principle, which stresses the importance of the strong relationship a type has with its super type. Understanding LSP can help you identify when you are missing an important abstraction, or perhaps when inheritance is being abused as a tool.
In this episode we examine ISP (the Interface Segregation Principle). This one states that a type should not depend on methods from an interface that it will never use. Often times this means that the type probably carries too many responsibilities, but breaking it apart is difficult for other reasons (perhaps too many things depend on it and changing it would be expensive). You can extract smaller interfaces that support the individual responsibilities, but still have the same class adopt it. Doing so opens up opportunities for further refactoring and testing.
In this episode we cover the dependency inversion principle, which states that high level components should not depend on low level components, but instead they both should depend on abstractions. We will look at two examples of this and leverage dependency injection to decouple classes from concrete dependencies.