code structural analysis
TRANSCRIPT
Code Structural Analysis
Agenda
• Introduction to structural analysis• Logical Design principles• Q&A
Introduction to structural analysis
Most apps begin life small and neat.
Time goes by…
Hello. I am your rotting enterprise app.
How do we feel design rot?
Rigidity
Fragility
Immobility
Viscosity
Opacity
Needless Complexity
Needless Repetition
There are different symptoms that smell…
What structural analysis shows…
Structure of Hibernate Core 3.6.6
Artwork by Jackson Pollock
However, it could be better…
Structure of Spring Framework 3.2.0
Structural analysis allows you to keep app’s structure in shape and catch
design flaws early.
Logical Design principles
Package is the first-class citizen and key element of logical design.
Treat packages as hierarchical even if they’re represented flat.
Given packagescom.myproject.clientcom.myproject.client.personalcom.myproject.client.profilecom.myproject.api
Personal and Profile packages are part of Client.
Use packages to group functionally-related artifacts. Do not group artifacts
that do the same thing, but are different by nature.
Avoid
com.myproject.enumscom.myproject.modelcom.myproject.servicescom.myproject.repositorycom.myproject.factorycom.myproject.helpers…
Prefer
com.myproject.clientcom.myproject.lendingcom.myproject.loyality…
The Common Closure Principle
Group tightly coupled classes together. If classes that change together are in the same package, then the impact of
change is localized.
Make sure artifacts are not floating away.
Make packages highly cohesive by following Single Responsibility
Principle.
Keep packages loosely coupled, ideally – completely independent. Reflection
doesn’t count.
Avoid dependency magnets. Sometimes duplication is not that evil.
Aggregate root relationship
com.app.loan
class Loan {
}
com.app.client
class Client {// a bunch of stuff
}@ManyToOneClient client
Aggregate root relationship
com.app.loan
class Loan {
}
com.app.client
class Client {// a bunch of stuff
}@EmbeddedClientId clientId
com.app.client
@Embeddableclass ClientId {
Long value
}
Provide slim package interface and hide implementation details.
Strive for weak package connascence. Keep locality in mind.
Manage relationships. Every dependency arrow has a reason. Burn
bi-directional dependences in fire.
Otherwise
Version 1.0 – A great start
Version 1.1 – Imperfection creeps in
Version 1.2 – Imperfection takes hold
Version 1.3 – Chaos begins
Version 1.4 – Explosion
The Acyclic Dependencies Principle
The dependencies between packages must not form cycles.
Can be solved by:- Merging
- Dependency Inversion
- Escalation
- Demotion
Client.Beans
Merging
Client
Client
Tracking
Dependency Inversion
Guest
TrackingGuest
Billing
Escalation
Customer
class Customer { Collection<Bill> bills def calculateDiscount() { } }
class Bill { def pay(Customer customer) { customer.calculateDiscount() … }}
Billing
Escalation
Customer
class Customer { Collection<Bill> bills}class Bill { def pay(BigDecimal discount) { }}
class DiscountCalculator { def calculate(Customer, Bills)}
Discount
Billing
Demotion
Customer
class Customer { Collection<Bill> bills def getDiscountCalculator()}
class Bill { def pay(DiscountCalculator) { }}
class DiscountCalculator { def calculate()}
Discount
Class design principles (SOLID)
Single Responsibility PrincipleOpen-Closed PrincipleLiskov Substitution PrincipleInterface Segregation PrincipleDependency Inversion Principle
Class should have only one responsibility and
only one reason to change.
The Single Responsibility Principle
Depend on abstractions, as anything concrete is
volatile
The Dependency Inversion Principle
High Level Policy
Abstraction
Abstraction
Impl. Impl.
Package Package
X Y
X Yinterfac
e
X
Package Package
Client B
Service
«Client A method»«Client B
method» «Client C method»
Client C
Client A
Many client-specific interfaces are better than
one general-purpose interface
The Interface Segregation Principle
Interface A
«Client A method»
Client B
Client C
Client A
Interface B
«Client B method»
Interface C
«Client C method»
Service
«Client A method»«Client B
method» «Client C method»
Tools
Macker
JDepend
OO Design Principles & Metrics, Jason Gorman http://goo.gl/RTW9GTThe Economics of Software Design, J.B. Rainsberger http://goo.gl/ra7Q8Q SOLID Principles, Eduards Sizovs http://goo.gl/RpxavdDesigning Object-Oriented Software, Jouni Smed http://goo.gl/iyE1R2Grand Unified Theory Of Software Design, Jim Weirich http://goo.gl/ASqyAsFun With Modules, Kirk Knoernschild http://goo.gl/i8jx8Y
More
Conclusion
Every application requires structure.
Structure must be carefully managed.
Integrate Code Structural Analysis into
development:• Install CSA tool
• Look at the «big picture»
• Manage complexity
• Prevent entropy
Wish you beautiful architectures.
Thank you!