Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Code Structural Analysis
Eduards Sizovs
eduards.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 ...
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 packages
com.myproject.client
com.myproject.client.personal
com.myproject.client.profile
com.myproject.api
Personal ...
Use packages to group functionally-related
artifacts. Do not group artifacts that do the
same thing, but are different by ...
Avoid
com.myproject.enums
com.myproject.model
com.myproject.services
com.myproject.repository
com.myproject.factory
com.my...
The Common Closure Principle
Group tightly coupled classes together. If
classes that change together are in the same
packa...
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
}
@ManyToOne
Cli...
Aggregate root relationship
com.app.loan
class Loan {
}
com.app.client
class Client {
// a bunch of stuff
}
@Embedded
Clie...
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(Cus...
Billing
Escalation
Customer
class Customer {
Collection<Bill> bills
}
class Bill {
def pay(BigDecimal discount) {
}
}
clas...
Billing
Demotion
Customer
class Customer {
Collection<Bill> bills
def getDiscountCalculator()
}
class Bill {
def pay(Disco...
Class design principles (SOLID)
Single Responsibility Principle
Open-Closed Principle
Liskov Substitution Principle
Interface Segregation Principle
Depend...
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 ...
Client
B
Service
«Client A method»
«Client B method»
«Client C method»
Client
C
Client
A
Many client-specific interfaces a...
Tools
Macker
JDepend
OO Design Principles & Metrics, Jason Gorman http://goo.gl/RTW9GT
The Economics of Software Design, J.B. Rainsberger http:...
Conclusion
Every application requires structure.
Structure must be carefully managed.
Integrate Code Structural Analysis i...
Wish you beautiful architectures.
Thank you!
Upcoming SlideShare
Loading in …5
×

Code Structural Analysis

2,012 views

Published on

Published in: Technology
  • There are over 16,000 woodworking plans that comes with step-by-step instructions and detailed photos, Click here to take a look ➤➤ http://t.cn/A6hKZsXN
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • The #1 Woodworking Resource With Over 16,000 Plans, Download 50 FREE Plans... ◆◆◆ http://tinyurl.com/y3hc8gpw
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

Code Structural Analysis

  1. 1. Code Structural Analysis
  2. 2. Eduards Sizovs eduards.sizovs@gmail.com www.linkedin.com/in/eduardsi @eduardsi on Twitter Who is broadcasting?
  3. 3. Agenda • Introduction to structural analysis • Logical Design principles • Q&A
  4. 4. Introduction to structural analysis
  5. 5. Most apps begin life small and neat.
  6. 6. Time goes by…
  7. 7. Hello. I am your rotting enterprise app.
  8. 8. How do we feel design rot?
  9. 9. Rigidity Fragility Immobility Viscosity Opacity Needless Complexity Needless Repetition There are different symptoms that smell…
  10. 10. What structural analysis shows…
  11. 11. Structure of Hibernate Core 3.6.6
  12. 12. Artwork by Jackson Pollock
  13. 13. However, it could be better…
  14. 14. Structure of Spring Framework 3.2.0
  15. 15. Structural analysis allows you to keep app’s structure in shape and catch design flaws early.
  16. 16. Logical Design principles
  17. 17. Package is the first-class citizen and key element of logical design.
  18. 18. Treat packages as hierarchical even if they’re represented flat.
  19. 19. Given packages com.myproject.client com.myproject.client.personal com.myproject.client.profile com.myproject.api Personal and Profile packages are part of Client.
  20. 20. Use packages to group functionally-related artifacts. Do not group artifacts that do the same thing, but are different by nature.
  21. 21. Avoid com.myproject.enums com.myproject.model com.myproject.services com.myproject.repository com.myproject.factory com.myproject.helpers … Prefer com.myproject.client com.myproject.lending com.myproject.loyality …
  22. 22. 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.
  23. 23. Make sure artifacts are not floating away.
  24. 24. Make packages highly cohesive by following Single Responsibility Principle.
  25. 25. Keep packages loosely coupled, ideally – completely independent. Reflection doesn’t count.
  26. 26. Avoid dependency magnets. Sometimes duplication is not that evil.
  27. 27. Aggregate root relationship com.app.loan class Loan { } com.app.client class Client { // a bunch of stuff } @ManyToOne Client client
  28. 28. Aggregate root relationship com.app.loan class Loan { } com.app.client class Client { // a bunch of stuff } @Embedded ClientId clientId com.app.client @Embeddable class ClientId { Long value }
  29. 29. Provide slim package interface and hide implementation details.
  30. 30. Strive for weak package connascence. Keep locality in mind.
  31. 31. Manage relationships. Every dependency arrow has a reason. Burn bi-directional dependences in fire.
  32. 32. Otherwise
  33. 33. Version 1.0 – A great start
  34. 34. Version 1.1 – Imperfection creeps in
  35. 35. Version 1.2 – Imperfection takes hold
  36. 36. Version 1.3 – Chaos begins
  37. 37. Version 1.4 – Explosion
  38. 38. The Acyclic Dependencies Principle The dependencies between packages must not form cycles.
  39. 39. Can be solved by: - Merging - Dependency Inversion - Escalation - Demotion
  40. 40. Client.Beans Merging Client Client
  41. 41. Tracking Dependency Inversion Guest TrackingGuest
  42. 42. Billing Escalation Customer class Customer { Collection<Bill> bills def calculateDiscount() { } } class Bill { def pay(Customer customer) { customer.calculateDiscount() … } }
  43. 43. Billing Escalation Customer class Customer { Collection<Bill> bills } class Bill { def pay(BigDecimal discount) { } } class DiscountCalculator { def calculate(Customer, Bills) } Discount
  44. 44. Billing Demotion Customer class Customer { Collection<Bill> bills def getDiscountCalculator() } class Bill { def pay(DiscountCalculator) { } } class DiscountCalculator { def calculate() } Discount
  45. 45. Class design principles (SOLID)
  46. 46. Single Responsibility Principle Open-Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle
  47. 47. Class should have only one responsibility and only one reason to change. The Single Responsibility Principle
  48. 48. Depend on abstractions, as anything concrete is volatile The Dependency Inversion Principle High Level Policy Abstraction Abstraction Impl. Impl. Package Package X Y X Y interface X Package Package
  49. 49. 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»
  50. 50. Tools Macker JDepend
  51. 51. OO Design Principles & Metrics, Jason Gorman http://goo.gl/RTW9GT The Economics of Software Design, J.B. Rainsberger http://goo.gl/ra7Q8Q SOLID Principles, Eduards Sizovs http://goo.gl/Rpxavd Designing Object-Oriented Software, Jouni Smed http://goo.gl/iyE1R2 Grand Unified Theory Of Software Design, Jim Weirich http://goo.gl/ASqyAs Fun With Modules, Kirk Knoernschild http://goo.gl/i8jx8Y More
  52. 52. 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
  53. 53. Wish you beautiful architectures.
  54. 54. Thank you!

×