In our above class, there are 3
private methods having different responsibility. It is very difficult for testing this class and methods as its private.
Solution is to make different classes for different behaviour or responsibilities and make one more class and call above classes methods from this class. So code is readable and also testing can be done easily.
class ViewClaimDetailController {
let netcore = NetCore()
let conversationFactory = ConversationFactory()
let coredata = coredataController()
func getAllClaimDetail() {
let jsonData = netcore.getDataFromAPI()
let claims = conversationFactory.parseJsonAndFillToArray(data : jsonData)
coredata.saveDataToLocalDB(claims: claims)
}
}
class NetCore {
func getDataFromAPI() {
// save to coredata
}
}
class ConversationFactory {
func parseJsonAndFillToArray(data: Any) {
// save to coredata
}
}
class coredataController {
func saveDataToLocalDB(claims: [Any]) {
// save to coredata
}
}
2. Open Closed Principle : Classes and Module should be open for extension and closed for modification. According to this principle, we should write such a class or code that should not be change when new requirement comes.
Code for Example :
class Rectangle {
var width : Double = 0
var height : Double = 0
init(inWidth: Double, inHeight: Double) {
self.width = inWidth
self.height = inHeight
}
}
class AreaCalc {
func calculateArea(rectangel: Rectangle) -> Double {
return rectangel.width * rectangel.height
}
}
If we want to calculate area for new shape, then we have to modify existing calculateArea() method like following :
class AreaCalc {
func calculateArea(shape: AnyObject) -> Double {
if (shape is Rectangle) {
return shape.width * shape.height
} else if (shape is Square) {
return shape.width * shape.width
}
}
}
Again, if want to add area of circle, triangle, we modify method and expand our if....else if... condition.
This is not good according open-closed principle. According to open-closed principle above code should be like following :
protocol Shape {
func calculateArea() -> Double
}
class Rectangle: Shape {
var width : Double = 0
var height : Double = 0
init(inWidth: Double, inHeight: Double) {
self.width = inWidth
self.height = inHeight
}
internal func calculateArea() -> Double {
return self.width * self.height
}
}
class Circle: Shape {
let radius : Double = 0
internal func calculateArea() -> Double {
return M_PI * radius * radius
}
}
class AreaCalc {
func calculateArea(shape: Shape) -> Double {
return shape.calculateArea()
}
}
We can achieve open-closed principle with help of protocol.
3. Liskov's substitution Principle : New derived classes should extend the base classes without changing the base class behaviour. Subclass should override the parent class methods in a way that doesn't break the functionality of base class from client point of view.
Code for example :
We have rectangle class in open-closed principle. Assume there it is not confirming Shape protocol.
Now we make square class
class square : Rectangle {
override var width: Double {
didSet {
height = width
}
}
override var height: Double {
didSet {
width = height
}
}
}
Now we write test cases :
func testAreaOfRectang1eFor4X3()
{
let rectangle: Rectangle = Square()
rectangle.height = 3
rectangle.width = 4
let areaCa1cu1ator = AreaCalc()
let areaOfRectang1e = areaCa1cu1ator.calculateArea(rectang1e: rectangle)
XCTAssertEqua1(areaOfRectang1e , 12, "Area of Rectangle not matching" )
}
Here, rectangle is of square type finding area of rectangle. As we saw override property of square, we can not lost rectangle (base) class definition and we violate liskov principle of Derived class (Square) breaking the parent class (Rectangle) funtionality of caluculating the area.
Solution of this is only to make protocol and confirm that. That means, we can conclude that violating Liskov’s Principle violates Open Close Principle as well.
4. Interface segregation principle :
This principle solves FAT interface problems of Object Oriented Programming. A interface is called FAT when it has too many methods which contains more information than we really want.
Code for example :
protocol Gesture {
func didTap()
func didDoubleTap()
}
class View1 : Gesture {
func didTap() {
//required this method
}
func didDoubleTap() {
// not required this method
}
}
class View2 : Gesture {
func didTap() {
// not required this method
}
func didDoubleTap() {
//required this method
}
}
Here view1 required only didTap() method and view2 require only didDoubleTap() method still both class has to implement both methods. So solution, to make two different protocol and define each method in each protocol. Class can confirm multiple protocol to achieve functionality. This is rule of interface seggregation. Or we can use @objc to make optional method.
Example 2 :
class User {
var firstName : String
var lastName : String
var imageURL : String
init(firstName : String, lastName: String, imageURL : String) {
self.firstName = firstName
self.lastName = lastName
self.imageURL = imageURL
}
}
class UserProfileImageView {
func loadProfilePhoto(user: User) {
//load user.imageURL
}
}
Here in loadProfilePhoto method, User instance is passed so all other information except imageURL are also passed. It is not good.
Solution : Use protocol
protocol UserProfileViewDetails {
var imageURL: String { get }
}
class User : UserProfileViewDetails {
var firstName : String
var lastName : String
var imageURL : String
init(firstName : String, lastName: String, imageURL : String) {
self.firstName = firstName
self.lastName = lastName
self.imageURL = imageURL
}
}
class UserProfileImageView {
func loadProfilePhoto(user: UserProfileViewDetails) {
//load user.imageURL
}
}
Now the UserProfileImageView’s loadProfileFor(user:UserProfileViewDetails) which is the client has only the imageURL information with it to display the User Profile Image, which agrees with the Interface Segregation Principle.
5. Dependency Inversion Principle : In the context of DIP:
- High-level modules (e.g., classes handling business logic) should not directly depend on low-level modules (e.g., specific implementations). Instead, they should both depend on abstractions (e.g., protocols).
- This promotes flexibility and reusability by allowing you to swap out low-level modules without changing the high-level logic.
Example with WiredKeyboard and WiredMouse
Without DIP (Violation of Dependency Inversion Principle)
Here, the Computer class directly depends on the concrete classes WiredKeyboard and WiredMouse. This makes it difficult to replace or extend these peripherals.
Problem:
- If we want to use a wireless keyboard or mouse, we would have to modify the
Computer class, violating the Open/Closed Principle as well.
With DIP (Using Abstractions)
Here, we introduce protocols (Keyboard and Mouse) as abstractions. The Computer class depends on these abstractions rather than specific implementations.
Benefits of Using DIP
Flexibility: You can easily introduce new peripherals without changing the Computer class.
Testability: You can mock Keyboard and Mouse for unit testing the Computer class without needing actual implementations.
Summary :
- Each an every class should have only one responsibility
- Should not modify the existing class for change requirement, rather extent the class
- Extending or Inheriting a child/derived class should not break any parent or base class functionality
- The Interface or class API’s to client should have minimum information required by the client
- Class A should not depend on Class B or vice versa, both should be losely coupled
If you have any comment, question, or recommendation, feel free to post them in the comment section below!
