Scott Franks
Feb 2013
Rage ATM
These are class level design principles. They allow you to minimize coupling and dependencies. The result is code that is easy to read and refactor.
Single Responsibility Principle (SRP)
Open/Closed Principle (OCP)
Liskov Substitution Principle (LSP)
Interface Segregation Principle (ISP)
Dependency Inversion Principle (DIP)
A class should have only one reason to change and when making that change it should only effect the class.
Every class should only have a single responsibility.
The single responsibility should be entirely encapsulated by its class.
Software entities should be open for extension,
but closed for modification.
You should be able to add new features to and existing system without modifying preexisting code.
The concepts for "extension" are language specific, for example subclasses, extension methods, or categories.
Functions that use pointers or references to base
classes must be able to use objects of derived
classes without knowing it.
A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend upon details. Details should depend upon abstractions.
A design pattern is a general reusable solution to a commonly occurring problem within software design. It is a description or template for how to solve a problem that can be used in many different situations.
Helps developers reuse successful designs by basing new designs on prior experience.
Improves understandability for developers familiar with the pattern.
Identifies participating classes and instances, their roles and collaborators, and the distribution of responsibilities. This helps ensure adherence to Design Principles.
Creational
Structural
Behavioral
Creation of objects for you rather than instantiating objects directly
Composition of classes and objects to obtain new functionality
Communication and interaction between objects
Coupling is a measure of how closely connected two modules are.
Cohesion is a measure of how strongly related each piece of functionality within a module is.
Coupling and Cohesion have an inverse relationship
With tightly coupled systems:
With low cohesion systems:
Step 1:
Make sure that you pull all code not related to presenting the user interface out of the View Controllers. MVC does not stand for Massive View Controller
Step 2:
Abstract common transformations and groupings into separate components or make them reusable though base classes.
As part of our login process we have to handle 4 possibilities: a successful login, MFA is required, the user has no eligible accounts, or an error code was returned.
The code required to do all the service calls and perform the logic to arrive at these possibilities is about 200 lines. Originally this was in our LoginVC be was pulled out into the eApiLoginBS.
Lets look at a few examples:
CashTapp uses custom buttons, text fields, and typography. Instead of recreating these components each time they are used we extended the base UIKit classes.
Lets take a look a few components:
And leverage inheritance for code reuse:
There are some UI aspects that we decided to abstract out of the View Controller despite them only occurring once. These UI components were usually very complicated (200 LOC+).
Examples: