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