SOLID principles
SOLID: dependency inversion principle: information hiding
- a class should only expose necessary functions to outside - abstraction hides complexity by emphasizing on essential characteristics and suppressing detail - caller should not assume anything about how the interface is implemenrted - effects of internal changes are localized
SOLID: single responsibility principle: cohesion
- cohesion refers to how closely the functions in a module are related - modules should contain functions that naturally belong together - and/or check: a class description that describes a class in terms of alternatives is probably not a class but a set of classes - e.g.: "a ClassRoom is a location where students attend tutorials or labs" means may need model as TutorialRoom and ComputerLab
types of cohesion
- coincidental (bad): when parts of modules grouped together (like utilities) - logical cohesion (bad): put together as logically same category, like mouse and keyboard - temporal cohesion: put together by when they are processed - procedural cohesion: grouped together because they follow certain sequence of program execution - communicational cohesion: grouped together because they operate on the same data - sequential cohesion (very good): put together because output of one is the input of another - functional cohesion (best): put together because they all contribute to a single well defined task of module
types of coupling
- content coupling (high): when one module modifies or relies on the internal workings of another module - common coupling: two modules share the same global data (or resource), so changing the shared resource results in changing the two modules - external coupling: two modules share an externally imposed data format/communication protocol/device interface - control coupling: one module controlling the flow of another, passing it information on what to do - stamp coupling (data structured coupling): sharing a composite data structure, may lead to changing the way a module reads a record because a field that the module doesn't need has been modified - data coupling: when modules share data - message coupling (low): loosest type of coupling... - no coupling: modules don't communicate with eachother
SOLID: single responsibility principle: coupling
- coupling assesses how tightly a module is related to other modules - goal is loose coupling, as modules should depend on as few other modules as possible - changes in modules should not impact other modules
SOLID: liskov substitution principle
- if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program - subclass must have weaker pre-condition and stronger post-condition
SOLID: interface segregation principle
- many client-specific interfaces are better than one general-purpose interface - move towards role-based interfaces - clients need only know about the methods that are relevant to them - almost like high cohesion
why modularity
- minimize complexity - reusability - extensibility - portability - maintainability
SOLID: dependency inversion principle
- one should depend upon abstractions - 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
SOLID
- single responsibility principle - high cohesion, low coupling - open/closed principle - liskov substitution principle - interface segregation principle - dependency inversion principles
SOLID: open/closed principle
- software entities should b open for extension, but closed for modification - class must be closed for internal change - but must be open for extensions - often violates the long method code smell - often dealt with by method extraction
semantic coupling
- when one module makes use of some semantic knowledge of another module's inner workings - dangerous because changing code in the used module can break code in the using module in undetectable ways to the compiler
SOLID: single responsibility princple
class should have only a single responsibility (only one potential change in the software's specification should be able to affect the specification of the class