Introduce
SOLID is a very important set of principles in object-oriented programming. And for Swift it is no exception. SOLID was introduced in 2000 by Robert C. Martin (Uncle Bob) in the article Design Principles and Design Patterns. SOLID is combined from the first 5 letters of the 5 rules.
- S Responsibility:
This principle states “Each class should have only one function.”
- Consider the following example
In the example on the class AirConditioner has 4 functions, turn on, off, switch mode, adjust speed. In practice such a class will contain a lot of functions. This makes the class increasingly bulky and difficult to manage. Therefore, this principle was created to solve the above problem.
Back to the original example. We see the functions of the air conditioner will be divided into the following groups:
- Toggle
- Mode change
- Change the speed
Thus, we can create 3 classes with 3 functional groups as follows
- In the above example the functions were broken down according to SOLID principles.
Finally in the AirConditioner class we create entities to use each of the following functions
As such, it will become easier to manage the class later because the functions are broken down and each class performs a task.
- O pen / close principle:
This principle is meant to mean that classes need to be designed for expansion but closed for changes.
- Back to the old example. Suppose we want to add a new function called air direction to AirConditioner class. If we modify the code in the old class this is a violation of SOLID’s rules so we have the following solution
In the above example, it is possible to add a property, but there is no need to change the AirConditioner class by using the extension.
- L islov substitution principle:
If S is a subtype of T. Then the entity of T can be replaced with the entity of S.
This definition can be roughly understood as. If we have a child class, we must own all the properties and functions of the parent class.
Observe the following example:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 | class Post { void CreatePost(Database db, string postMessage) { db.Add(postMessage); } } class TagPost : Post { override void CreatePost(Database db, string postMessage) { db.AddAsTag(postMessage); } } class MentionPost : Post { void CreateMentionPost(Database db, string postMessage) { string user = postMessage.parseUser(); db.NotifyUser(user); db.OverrideExistingMention(user, postMessage); base.CreatePost(db, postMessage); } } class PostHandler { private database = new Database(); void HandleNewPosts() { List<string> newPosts = database.getUnhandledPostsMessages(); foreach (string postMessage in newPosts) { Post post; if (postMessage.StartsWith("#")) { post = new TagPost(); } else if (postMessage.StartsWith("@")) { post = new MentionPost(); } else { post = new Post(); } post.CreatePost(database, postMessage); } } } |
The above example violates SOLID’s Liskov rule because the MentionPost class does not override the func CreatePost of the post class. Therefore, the MentionPost class cannot replace its parent class, Post.
So to ensure compliance with SOLID MentionPost class must inherit all properties and funcs of the parent class.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | class MentionPost : Post { override void CreatePost(Database db, string postMessage) { string user = postMessage.parseUser(); NotifyUser(user); OverrideExistingMention(user, postMessage) base.CreatePost(db, postMessage); } private void NotifyUser(string user) { db.NotifyUser(user); } private void OverrideExistingMention(string user, string postMessage) { db.OverrideExistingMention(_user, postMessage); } } |
As such, the Post class can be completely replaced with the Memtion Post
- I nterface Seregration:
This principle states: “A client should not be forced to depend on a method that it does not use”.
- Going back to the air conditioner example
We see that the CentralizedAC and SplitAC classes both conform to the ACFeature protocol, but the SplitAC class does not use the getCentralizedAirConditioner () method. To solve this problem, we must separate the getCentralized method from the NewFeature protocol as follows. 
Thus, separating the getCentralizedAirConditioner () method from the ACFeature protocol has helped SplitAC class not be dependent on this method.
- D ependency Inversion:
High-level modules should not depend on low-level modules. they should depend on an abstract layer.
Consider the following example
In the above example, the CoversationData class is a high-level module, CoreDataController is a low-level module. We see the ConverstionData class is not yet a CoreDataController entity. It can be seen that the high-level module has been dependent on the low-level module, so it would be difficult to replace the CoreDataController module with another module. To solve this problem, we create an abstract class to reduce the dependence of the two parties.
Thus, instead of containing a CoreDataController instance, the ConverstionData class only contains an abstract DataBase entity. Therefore the dependence of 2 modules will be significantly reduced. In case you want to replace the CoreDataController module, you just need to create a new module and conform to the Database protocol
Conclude
SOLID is a very important set of rules in OOP programming in general and iOs in particular. The thorough application and compliance with these rules makes the source code easy to understand and maintain.