Classes
Last updated
Was this helpful?
Last updated
Was this helpful?
Was this helpful?
Instantiated mostly by the DI framework - Spring, Java EE
If stateful, create it from the code with new
Entity, DTO (Data Transfer Object)
Only data members
No business logic
Always instantiated as new - by the database layer or with new from the code
Accessors/mutators are questionable - getters/setters
One reason to exist, change
"Small"
No "God" class - "Sack", "Blob"
Encapsulation (hiding, protection) decreases dependency - Other classes cannot depend on this
Tight cohesion
Implements the "one thing" rule
Contains only dependent members
Refactor to cohesive classes
There will be many small classes - Like a toolbox with drawers
Reduces amount, cost and risk of changes
Create interfaces for service classes -but not always paranoidly for everything
Prefer interfaces to parent classes
Create marker interfaces
You cannot give a meaningful name - e.g. "Parent", "Common", "Processor", etc.
Polymorphic class is not used as polymorphic - never declared to parent type - see later
Many methods - "God" or "Blob" class
Methods of a class can be split into distinct call chains - they should be in separate classes
Test coverage is not visible or cheating
Refactor to composition + Facade pattern
Example: Refactoring low cohesion