S.O.L.I.D Principles in iOS -Some Simple Tips

Ok, you probably already hear this term, but in practice which all cases we should apply it. Let’s check some simple tips.

SOLID are principles that lead you to write great code without additional effort. With great application comes great responsibility. It means that the code base should be flexible, expandable without much effort, and easy to test. SOLID principles are the exact things that let you support the top level of quality.

?? Components for the S.O.L.I.D principles :

S -Single Responsibility Principle: A module, class or function should be responsible for a single purpose, focusing on a single task. This single focus helps create code that doesn’t grow out of proportion by solving the entire problem.

Tips to check & apply

• Ask yourself for every entity ( classes / functions ) : this entity, does more than one thing?
• You shouldn't have use the word and when have to talk the responsibility to entity

O- Open/Closed Principle: Define modules, classes, and functions open for extension but closed for modification. In other words, you extend its behavior without modifying its implementation.

Tips to check & apply

• If you want to modify a class every time a new behavior is added, something isn't quite right
• If/else/switch statements don't be used to modify a behavior

L- Liskov Substitution Principle: Replace classes with their subclasses without breaking the code. You can also apply this idea in Swift by using protocols where you can use another type as long as it conforms to the same protocol.

Tips to check & apply

• Instead of one monolithic interface, break an interface up based on what implementers should be doing
• Keeps consumers from having to much power

I- Interface Segregation Principle: A module shouldn’t depend on requirements that it doesn’t use. Instead of creating a protocol that defines the whole behavior of a type, creating a different protocol that covers other use cases helps modules use only what they need.

D- Dependency Inversion Principle: A module shouldn’t depend on external dependencies, but the module should define its requirements. This states that your modules should depend on abstractions, not other modules. For example, by following this principle, you’ll be able to test your networking module in isolation without having to depend on the concrete implementation of other parts of the app.

Tips to check & apply

• We’re used to this : High level -> (uses) Low level
• High level -> (expects) interface <- ( fulfills ) low level