SOLID principles are super essential software design principles, introduced by Robert C. Martin, also popularly known as ‘Uncle BOB’ in this paper. They are rather, 5 principles selected from a large number of principles. Now that this gorgeous Ferrari 458 has your attention, let’s start with SOLID Principles. The Principles go as follows:
- Single Responsibility Principle (SRP)
- Open Closed Principle (OCP)
- Liskov Substitution Principle (LSP)
- Interface Segregation Principle (ISP)
- Dependency Inversion Principle (DIP)
These Principles solve main problems of bad architecture such as:
- Fragility: Changes in one module, results in code break in totally different unrelated module.
- Rigidity: Rigid Code is difficult to modify, rigidity makes it difficult to make changes in in existing functionalities, or adding new features.
- Immobility: It becomes difficult to reuse a component in different parts of project, let alone different projects, common culprit being too many dependencies.
At production scale, these issues cause massive damage in regards to code smell and pace of implementation. SOLID Principles assist in writing better code, mere usage of SOLID Principles are no defining guidelines of a good or bad developer, but these are for sure, useful tools in your belt!
Single Responsibility Principle (SRP)
Def._ Every module or class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class, module or function._
The SRP is a simple idea, each class has just one reason to change, is has it’s specific area of responsibility and it should not be responsible for anything apart for it, lets see it in practice.
Suppose, you own the car displayed above (of course, you’re a veteran in process!), and you plan to take it on a long drive, but before, you need to set things up, so you perform 3 activities. _You start the engine, temperature is warm today so you turn on the AC, and now that you’re feeling good, you turn up the music as well, and boom, you’re all set up. _Let’s code this:
On Left: Class not complying to SRP, On Right: Classes complying to SRP
Both the scripts produce identical outputs, but there is a major difference in implementation. When you purchase a sports car, you can’t imagine all the hundreds of features jammed right beneath the bonnet, instead, such a sophisticated car would contain multiple subsystems, which are designated specific areas of responsibility. Each subsystem is a group of similar functions, this is what exactly SRP states. On the left is a class Ferrari458, which is not so organised and definitely not as organised as a Ferrari, no systematic arrangement is present, all the features are just put in there. On the right in class Ferrari458 which complies with SRP, specific responsibility is assigned to a specific class, each class has single reason to change, and seperation of concerns is done to have a nicer and more maintainable architecture.
Open Closed Principle
_Def. _Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.”
Uncle Bob considers this as the most important principle of an object oriented design. The definition is difficult to grasp in one go, but it is what it is, software entities should be open for extensions and closed for modification both at the same time! And one more catch, you must use inheritance, composition or polymorphism to achieve this!
Let us see Open Closed Principle(OCP) in practice. Continuing with the story, _after the drive, you reach your neighbourhood and instead of rushing straight to your bed, you decide to meet Paul, your mechanic friend. Paul has some really cool accessories for your sports car: spoiler, seats(Id: 5), style wheels, bridge and dashboard. You purchased them, and Paul is now installing them. _Let’s code this:
On Left: Entities not complying to OCP, On Right: Entities complying to OCP
The two scripts were expected to produce identical outputs, but few installations failed in first, while all succeeded in second case. On Left, Paul sells you fake products, relies on in-house installation manuals folder as parts were not authenticate, they didn’t have any documentation on them, and On Right, Paul sells you authentic products, and uses installation manuals sent with brand accessories.
On left, the class Ferrari458 has a function installAccessories() which uses a switch statement for installation. Switch statement requires a case to be mantained for each accessory respectively or else it fails the installation. Just like it’s not optimal to maintain installation docs in one shelf for all the accessories in the world, switch statement is not idle solution for this problem either. This introduces OCP.
On the Right, let’s see the script point by point.** //1**: A seperate class Accessory is maintained, which can be considered the standard of all the accessories. class Accessory inherits from customStringConvertible, which makes it bound to implement the necessary functionality description for accessory installation. No modifications are ever made to this class. //2: Consider Paul doesn’t has Ferrari seats which were supposed to be installed, but seats of a different compatible brand, identified with Id: 5. This isn’t a problem, as our class is open to extensions, we simply write code to install accessory Id: 5, that’s it done! //3: Class Ferrari458, now simply has to install the accessories, nothing more, it installs them with function installAccessories() //4: main() function performs the installation of multiple accessories and successfully executes the process.
The example is simplified to the best of my ability, but this is the generic idea, you can absolutely extend it to the limits of your imagination. In the script on the right, class Accessory is open to extension, both the classes are closed to modification, class Accessory uses inheritance to exhibit this behaviour, the code almost needs no refactoring, and all entities comply to OCP.
#swift-5 #design-principles #ios #programming #solid-principles
