code structural analysis

Code Structural Analysis

Eduards Sizovseduards.sizovs@gmail.com

www.linkedin.com/in/eduardsi

@eduardsi on Twitter

Who is broadcasting?

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!