Object Oriented Programming
OOP Paradigm
The original paradigm just to remember:
Encapsulation
Inheritance
Polymorphism
Clean OOP Principles
Tight cohesion
Loose coupling
Responsibility - where to write code?
Separation of concerns
Creation - Dependency Injection
Configuration
Services, components - Business logic
Data - Entities, DTOs
Layers
Logging - Framework or AOP
Dependency Injection
Dependency Inversion
The paradigm
A.k.a. Inversion of Control, IoC
Always depend from the abstraction
The more abstract, the more robust
Example: What is inverted in DI?
Dependency Injection
Implementation of the Dependency Inversion
Mostly done by a DI framework -Spring, Java EE, ...
Easy to test -using mocks, test doubles
Example: Bad: Without dependency injection
Example: Good: Dependency injection by a DI framework
Inheritance over instanceof
Do not use instanceof and isAssignableFrom()
it adds dependency
it adds duplication
refactor to polymorphism or patterns
Composition over inheritance
Problems with inheritance
Too strict
Hard to develop - one child changes a certain way the other one does not
Do not use inheritance only for a "common" code
Parent and children are be changed together - spaghetti code
Favor composition to inheritance - Item 16 in Effective Java (2nd Edition, Joshua Bloch, 2008)
Overridden methods are unreadable and fragile - Item 17 in Effective Java (2nd Edition, Joshua Bloch, 2008)
Code Smells
Parent must be changed when children change, abstract methods should be added
The parent's name is "Common..." - a class should have an intentional business name
Use inheritance only for
Real polymorphism
Polymorphic usage - declared as a "parent" type
Design patterns
Law of Demeter
"Only talk to immediate friends"
Do not depend on the implementation details other classes
Use only one level of abstraction
"Wallet" rule
"Count of dots" rule - But not simply a dot counting law
It depends on that the used class is procedural or a data structure (see Classes)
Example: Bad:
S.O.L.I.D.
Not in the book but also Uncle Bob.
Single Responsibility
A class should have only one reason to change
Only a change in the specification should affect the implementation of the class
Open/Closed
Software entities should be open for extension, but closed for modification
It can be more general:
Software entities should NOT be open for extension
Any class should be closed for modification - not only parent classes
Liskov Substitution
Objects should be replaceable with instances of their subtypes without altering the correctness of that program.
See also design by contract
Interface Segregation
Many client-specific interfaces are better than one general-purpose interface.
Dependency Inversion
Depend on Abstractions. Do not depend on concretions.
Dependency injection is one method of following this principle.
Last updated