Design Principles For Building Good Software | Mnats Karakhanyan

As a part of https://swiftcoders.org initiative, SwiftCoders Armenia has an ambitious goal - connect passionate professionals to share their experience, create a great network and make an impact in their communities.
Our speakers are invited from the best IT companies to share their experience and knowledge.

YouTube link
https://youtu.be/yj4CVn0TVoo

Contact Mnats:
LinkedIn: https://www.linkedin.com/in/mnats-karakhanyan
Twitter: https://twitter.com/KarakhanyanMn
Facebook: https://www.facebook.com/mnats.karakhanyan

Join SwiftCoders Armenia
https://swiftcoders.am

Facebook
https://www.facebook.com/swiftcoders
Telegram
https://t.me/SwiftCoders
LinkedIn
https://www.linkedin.com/company/swiftcoders-armenia
Eventbrite
https://www.eventbrite.com/o/swiftcoders-armenia-18287883306
Decks
https://speakerdeck.com/swiftcoders
Slack
https://swiftcodersinvite.herokuapp.com

Transcript

1. mnatskar Mnats Karakhanyan Senior iOS developer Buymie KarakhanyanMn April 3, 2019
2. DESIGN PRINCIPLES FOR BUILDING GOOD SOFTWARE
3. Understanding Problem The problem Design Smells Metrics
4. Understanding Problem Design Principles The problem Design Smells Metrics Law of Demeter SOLID
5. Understanding Problem Design Principles Wrapping Up The problem Design Smells Metrics Law of Demeter SOLID Conclusion Bibliography Q&A
7. Software 
 Quality Understandable Reusable Easy to change
8. Design Smells
9. • Rigidity • Fragility • Immobility • Viscosity • Needless complexity • Needless repetition • Opacity
 Design Smells
11. Rigidity The design is hard to change
12. • Rigidity • Fragility • Immobility • Viscosity • Needless complexity • Needless repetition • Opacity
 Design Smells
14. Fragility The design is easy to break
15. • Rigidity • Fragility • Immobility • Viscosity • Needless complexity • Needless repetition • Opacity
 Design Smells
17. Immobility Difficult to reuse
18. • Rigidity • Fragility • Immobility • Viscosity • Needless complexity • Needless repetition • Opacity
 Design Smells
20. Viscosity Hard to do the right thing
21. • Rigidity • Fragility • Immobility • Viscosity • Needless complexity • Needless repetition • Opacity
 Design Smells
23. Needless complexity Over Engineering
24. • Rigidity • Fragility • Immobility • Viscosity • Needless complexity • Needless repetition • Opacity
 Design Smells
26. Needless repetition Duplication (DRY)
27. • Imposed duplication. Developers feel they have no choice—the environment seems to require duplication. • Inadvertent duplication. Developers don't realize that they are duplicating information. • Impatient duplication. Developers get lazy and duplicate because it seems easier. • Interdeveloper duplication. Multiple people on a team (or on different teams) duplicate a piece of information.
28. • Rigidity • Fragility • Immobility • Viscosity • Needless complexity • Needless repetition • Opacity
 Design Smells
30. Opacity Difficulty in Understanding
32. “Vertical and horizontal lines are positioned in layers or planes that do not intersect, thereby allowing each element to exist independently and unobstructed by other elements” Piet Mondrian
33. Orthogonality Self-contained independent Single, well-defined purpose
35. Benefits of Orthogonality Gain Productivity Reduce Risk
36. Gain Productivity Maintainability Reusable Get more functionality per unit effort (M × N)
37. Reduce Risk Isolated (Less rigid) Less fragile Testable Not tightly tied to a particular third-party
39. Good Design High cohesion Low coupling
40. Law of Demeter Talk only to your immediate friend
41. Violation of the law class Employee { var address: Address } class BasicExample { func streetName(for employee: Employee)-> String { return employee.address.streetName } }
42. Respect the law class Employee { private var address: Address = Address() var streetName: String { return address.streetName } } class BasicExample { func streetName(for employee: Employee) ->String { return employee.streetName } }
43. The more objects you talk to, more the risk of getting broken when any one of the object changes.
44. The more objects you talk to, more the risk of getting broken when any one of the object changes. Restrict class interaction in order to minimize coupling among classes.
45. • Only invoke methods that belong to ‣ The object itself ‣ Objects passed in as parameter to method ‣ An object the method created or instantiates ‣ Any components of the object • As a guidance-rule, more than two “dots” 
 means the Law of Demeter is being violated.
47. SOLID S: Single Responsibility Principle(SRP) O: Open-Closed Principle(OCP) L: Liskov Substitution Principle(LSP) I: Interface Segregation Principle(ISP) D: Dependency Inversion Principle(DIP)
49. SRP Class or module should have one, and only one, reason to change
50. Violation of SRP class Handler { func handle() { let data = requestDataToAPI() let array = parse(data: data) saveToDB(array: array) } private func requestDataToAPI() -> Data { // send API request and wait the response } private func parse(data: Data) -> [String] { // parse the data and create the array } private func saveToDB(array: [String]) { // save the array in a database } }
51. Solution class APIHandler { func requestDataToAPI() -> Data { // send API request } } class ParseHandler { func parse(data: Data) -> [String] { // parse the data } } class DBHandler { func saveToDB(array: [String]) { // save the array in a database }
52. Solution class Handler { let apiHandler: APIHandler let parseHandler: ParseHandler let dbHandler: DBHandler func handle() { let data = apiHandler.requestDataToAPI() let array = parseHandler.parse(data: data) dbHandler.saveToDB(array: array) } }
53. Symptoms Accidental duplication Merges
55. OCP Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification
56. Violation of OCP class AnaliticServise { func track(_ event: String, parameters: [String: Any]?) { // tracks an event in Facebook } }
57. Solution protocol AnaliticTracker { func track(_ event: String, parameters: [String: Any]?) }
58. Solution class GoogleAtalitics: AnaliticTracker { func track(_ event: String, parameters: [String: Any]?) { // tracks an event in google GoogleAtalitics } } class FacebookAtalitics: AnaliticTracker { func track(_ event: String, parameters: [String: Any]?) { // tracks an event in Facebook } }
59. Solution class AnaliticServise: AnaliticTracker { private let analiticTrackers: [AnaliticTracker] init(analiticTrackers: [AnaliticTracker]) { self.analiticTrackers = analiticTrackers } func track(_ event: String, parameters: [String: Any]?) { for tracker in analiticTrackers { tracker.track(event, parameters: parameters) } } }
61. The Wrong Abstraction
62. The Wrong Abstraction Duplication is far cheaper than the wrong abstraction
63. The Wrong Abstraction Duplication is far cheaper than the wrong abstraction Composition over inheritance
64. LSP Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it
65. Violation of LSP class Rectangle { var width: Float = 0 var hight: Float = 0 var area: Float { return width * hight } } class Square: Rectangle { override var width: Float { didSet { hight = width } } } let rectangle = Rectangle() rectangle.hight = 4 rectangle.width = 3 print(rectangle.area) // 12 let square = Square() square.hight = 4 square.width = 3 print(square.area) // 9
66. Solution protocol Polygon { var area: Float { get } }
67. Solution class Rectangle: Polygon { private let width: Float private let hight: Float init(width: Float, hight: Float) { self.width = width self.hight = hight } var area: Float { return width * hight } }
68. Solution class Rectangle: Polygon { private let width: Float private let hight: Float init(width: Float, hight: Float) { self.width = width self.hight = hight } var area: Float { return width * hight } } class Square: Polygon { private let side: Float init(side: Float) { self.side = side } var area: Float { return pow(side, 2) } }
69. Solution class Rectangle: Polygon { private let width: Float private let hight: Float init(width: Float, hight: Float) { self.width = width self.hight = hight } var area: Float { return width * hight } } class Square: Polygon { private let side: Float init(side: Float) { self.side = side } var area: Float { return pow(side, 2) } } let rectangle = Rectangle(width: 3, hight: 4) print(rectangle.area) // 12 let square = Square(side: 3) print(square.area) // 9
71. ISP Clients should not be forced to depend upon interfaces that they do not use.
72. Violation of ISP protocol Worker { func work() func eat() }
73. Violation of ISP class StandardWorker: Worker { func work() { print("Standard Worker is working") } func eat() { print(“Standard Worker is eating") } } class SuperWorker: Worker { func work() { print("Super Worker is working") } func eat() { print("Super Worker is eating") } }
74. Violation of ISP class Robot: Worker { func work() { print("Robot working... efficiently") } func eat() { assert(false, “Don't force me to eat, or i will crash") } }
75. Solution protocol Workable { func work() } protocol Feedable { func eat() }
76. class StandardWorker: Workable, Feedable { func work() { print("Standard Worker is working") } func eat() { print(“Standard Worker is eating") } }
77. class StandardWorker: Workable, Feedable { func work() { print("Standard Worker is working") } func eat() { print(“Standard Worker is eating") } } class SuperWorker: Workable, Feedable { func work() { print("Super Worker is working") } func eat() { print("Super Worker is eating") } }
78. class StandardWorker: Workable, Feedable { func work() { print("Standard Worker is working") } func eat() { print(“Standard Worker is eating") } } class SuperWorker: Workable, Feedable { func work() { print("Super Worker is working") } func eat() { print("Super Worker is eating") } } class Robot: Workable { func work() { print("Robot working... efficiently") } }
80. DIP High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions
81. Violation of DIP class Handler { let fm = FilesystemManager() func handle(string: String) { fm.save(string: string) } } class FilesystemManager { func save(string: String) { // Save the string in this file } }
82. Solution protocol Storage { func save(string: String) }
83. Solution class FilesystemManager: Storage { func save(string: String) { // Save the string in the file } }
84. Solution class FilesystemManager: Storage { func save(string: String) { // Save the string in the file } } class DatabaseManager: Storage { func save(string: String) { // Save the string in the data base } }
85. Solution class Handler { let storage: Storage init(storage: Storage) { self.storage = storage } func handle(string: String) { storage.save(string: string) } }
87. Composition over inheritance
88. SOLID Composition over inheritance
89. SOLID DRY Composition over inheritance
90. SOLID DRY KISS Composition over inheritance
91. SOLID DRY YAGNI KISS Composition over inheritance
92. SOLID DRY YAGNI KISS Composition over inheritance Refactoring
93. Clean Code: A Handbook of Agile Software Craftsmanship 
 by Robert C. Martin The Pragmatic Programmer: From Journeyman to Master by Andy Hunt Agile Software Development, Principles, Patterns, and Practices by Robert C. Martin Head First Design Patterns by Eric Freeman
94. karakhanyan.mnats@gmail.com