javaone’12 session 3992 - software modularity: paradoxes, principles, and architectures
DESCRIPTION
Starting from the JDK itself, a wave of migrations to module systems is bound to propagate throughout the Java landscape. In this session, expand your mental toolbox by learning what modularity is, why it is important, and how to divide your monolithic application into well-designed functional modules. First you will gain an intimate understanding of modularity by hearing about several of its mind-bending paradoxes. Then you will learn how popular design principles apply to creating modules and their APIs. Finally you will learn how common monolithic software architectures exhibit various degrees of modularization of functional features and what that means for your forthcoming modularization efforts.TRANSCRIPT
![Page 1: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/1.jpg)
Software Modularity: Paradoxes, Principles, and Architectures
Andrzej Olszak
Jaroslav Tulach
![Page 2: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/2.jpg)
Andrzej Olszak
• Ph.D. Research fellow @ SDU
• Creator of Featureous tool
• Fights cancer @ Dako
![Page 3: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/3.jpg)
Jaroslav Tulach
• Founder and architect of NetBeans IDE and RCP
• API designer
• Speaker and author
http://paradoxes.apidesign.org
![Page 4: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/4.jpg)
Agenda
1. Dividing into modules (Andrzej):
1. Architectures
2. Principles
2. Designing module APIs (Jaroslav):
1. Paradoxes
2. Principles
![Page 5: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/5.jpg)
Motivation
Getting out of the monolithic cave
![Page 6: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/6.jpg)
The starting point
A monolithic system
• No apparent logical parts– Everything changes
together
– Difficult to control complexity
![Page 7: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/7.jpg)
The goal
A modular system
• Decomposed into logical modules
• Modules partial:– Comprehension
– Change
![Page 8: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/8.jpg)
The tool
A module system
• Wraps logical modules into physical modules– a.k.a. advanced JARs
– Enforce code isolation
![Page 9: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/9.jpg)
A possible result
• Module system ⇏Modular code– It all depends on how you design
the modules
![Page 10: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/10.jpg)
Part I
Architectures
![Page 11: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/11.jpg)
A running example
• Let’s assume that this is our system
– 3 layers of code that provide 3 features to the users
• This is the essence of your architecture if you use:
– MVC, MVP, Onion arch, Hexagonal arch, …
“UI”
“Logic”
“Domain Model”
![Page 12: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/12.jpg)
Modularizing layers
• There are at lease three options:
View
Controller
Model
![Page 13: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/13.jpg)
Modularizing layers
• There are at lease three options:
View
Controller
Model
View
Controller
Model
App
feat
ure
1
feat
ure
2
feat
ure
3
![Page 14: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/14.jpg)
Choosing ‘best’ modularization
• Modularity is relative to change– Modularization quality depends on the future changes [Parn’72]
• Let’s consider two change scenarios:
View
Controller
Modelfe
atu
re1
feat
ure
2
feat
ure
3
![Page 15: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/15.jpg)
Choosing ‘best’ modularization
• Modularity is relative to change– Modularization quality depends on the future changes [Parn’72]
• Let’s consider two change scenarios:
View
Controller
Modelfe
atu
re1
feat
ure
2
feat
ure
3
1. Modify user functionality
![Page 16: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/16.jpg)
Choosing ‘best’ modularization
• Modularity is relative to change– Modularization quality depends on the future changes [Parn’72]
• Let’s consider two change scenarios:
View
Controller
Modelfe
atu
re1
feat
ure
2
feat
ure
3
1. Modify user functionality
![Page 17: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/17.jpg)
Choosing ‘best’ modularization
• Modularity is relative to change– Modularization quality depends on the future changes [Parn’72]
• Let’s consider two change scenarios:
View
Controller
Modelfe
atu
re1
feat
ure
2
feat
ure
3
1. Modify user functionality
![Page 18: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/18.jpg)
Choosing ‘best’ modularization
• Modularity is relative to change– Modularization quality depends on the future changes [Parn’72]
• Let’s consider two change scenarios:
View
Controller
Modelfe
atu
re1
feat
ure
2
feat
ure
3
1. Modify user functionality
![Page 19: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/19.jpg)
Choosing ‘best’ modularization
• Modularity is relative to change– Modularization quality depends on the future changes [Parn’72]
• Let’s consider two change scenarios:
View
Controller
Modelfe
atu
re1
feat
ure
2
feat
ure
3
1. Modify user functionality
![Page 20: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/20.jpg)
Choosing ‘best’ modularization
• Modularity is relative to change– Modularization quality depends on the future changes [Parn’72]
• Let’s consider two change scenarios:
View
Controller
Modelfe
atu
re1
feat
ure
2
feat
ure
3
2. Migrate UI to JavaFX1. Modify user functionality
![Page 21: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/21.jpg)
Choosing ‘best’ modularization
• Modularity is relative to change– Modularization quality depends on the future changes [Parn’72]
• Let’s consider two change scenarios:
View
Controller
Modelfe
atu
re1
feat
ure
2
feat
ure
3
2. Migrate UI to JavaFX1. Modify user functionality
![Page 22: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/22.jpg)
Choosing ‘best’ modularization
• Modularity is relative to change– Modularization quality depends on the future changes [Parn’72]
• Let’s consider two change scenarios:
View
Controller
Modelfe
atu
re1
feat
ure
2
feat
ure
3
2. Migrate UI to JavaFX1. Modify user functionality
![Page 23: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/23.jpg)
Choosing ‘best’ modularization
• Modularity is relative to change– Modularization quality depends on the future changes [Parn’72]
• Let’s consider two change scenarios:
View
Controller
Modelfe
atu
re1
feat
ure
2
feat
ure
3
2. Migrate UI to JavaFX1. Modify user functionality
No silver-bullet modularization
![Page 24: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/24.jpg)
Anticipating future changes
![Page 25: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/25.jpg)
Feature-oriented evolutionary changes
75%
Other evolutionary changes25%
Anticipating future changes
Software costs in organizations [Moad’90, Nose’90, Erli’00]
![Page 26: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/26.jpg)
Evolution &maintenance
60-90%
Initial development10-40%
Feature-oriented evolutionary changes
75%
Other evolutionary changes25%
Anticipating future changes
Software costs in organizations [Moad’90, Nose’90, Erli’00]
![Page 27: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/27.jpg)
Modularization in practice:the case of NDVis
• Neurological analysis tool by VisiTrend
– Monolithic -> NetBeans MS
– Improve functional customizability
– Improve reusability of core algorithms
• Starting point– 10 KLOC, 27 use cases
– Unfamiliar source code
– Complex and unfamiliar domain
View
Controller
Model
feat
ure
1
feat
ure
2
feat
ure
3
Feature-oriented restructuring
![Page 28: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/28.jpg)
Modularizing features with Featureous tool
![Page 29: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/29.jpg)
Modularizing features with Featureous tool
1. Feature location(a.k.a. traceability)
![Page 30: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/30.jpg)
Modularizing features with Featureous tool
1. Feature location(a.k.a. traceability)
2. Feature-orientedanalysis
![Page 31: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/31.jpg)
Modularizing features with Featureous tool
1. Feature location(a.k.a. traceability)
2. Feature-orientedanalysis
3. Iterative Restructuring
4. Module APIs
![Page 32: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/32.jpg)
Modularization @ 35 man-hours
• Explicit and pluggable features
• Reusable core
![Page 33: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/33.jpg)
Part II
Principles
![Page 34: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/34.jpg)
Separation of Concerns
• “To study an aspect of a subject matter in isolation”[Dijk’74]
• Software consists of “concerns”– Features
– Persistence
– Security
– Caching
...
• Refined by AspectJ [Kicz’96] and Hyper/J [Tarr’99]
– Multiple dimensions of concern – one dominant
– Scattering & Tangling
![Page 35: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/35.jpg)
Reducing Scattering & Tangling
• Low Scattering
– “a concern implemented by few modules“
– reduces change scope and delocalization [Leto’86]
View
Controller
Model
feature 1
scattering
![Page 36: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/36.jpg)
Scattering & Tangling
• Low Scattering
– “a concern implemented by few modules“
– reduces change scope and delocalization [Leto’86]
• Low Tangling
– "modules dedicated to a single concerns“
– reduces change propagation and interleaving [Ruga’95]
View
Controller
Model
feature 2
feature 1
tangling
scattering
![Page 37: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/37.jpg)
A real-world metaphor
![Page 38: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/38.jpg)
A real-world metaphor
http://xkcd.com/657/
![Page 39: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/39.jpg)
Mapping SoC to other principles
SEPARATION OF CONCERNS
![Page 40: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/40.jpg)
Mapping SoC to other principles
SEPARATION OF CONCERNS
LOW SCATTERING LOW TANGLING
![Page 41: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/41.jpg)
Mapping SoC to other principles
SEPARATION OF CONCERNS
Low coupling[Stev’74]
Information hiding[Parn’72]
DRY[Hunt’99]
LOW SCATTERING LOW TANGLING
![Page 42: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/42.jpg)
Mapping SoC to other principles
SEPARATION OF CONCERNS
Low coupling[Stev’74]
High cohesion[Stev’74]
Information hiding[Parn’72]
DRY[Hunt’99]
Single responsibility[Mart’02]
Common closure[Mart’02]
LOW SCATTERING LOW TANGLING
![Page 43: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/43.jpg)
Measuring SoC
• Concern location + concern-oriented metrics
– Trialed at Motorola [Simm’06]
• Static analysis + Cohesion and Coupling
– Issues: coupling vs. DRY, “uncohesive” java.util
• Repository mining for change-sets:
http://swerl.tudelft.nl/bin/view/Main/TestHistory
clas
ses
![Page 44: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/44.jpg)
Summary
• Module system is a tool, not the goal
• No “silver-bullet” modularization
• Restructuring layers into features is viable
• SoC – the root of all principles
![Page 45: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/45.jpg)
References[Parn’72] Parnas, D.L. (1972). On the criteria to be used in decomposing systems into modules. Communications of the
ACM, 15(12).
[Moad’90] Moad, J. (1990). "Maintaining the competitive edge". Datamation 61-62, 64, 66.
[Erli’00] Erlikh, L. (2000). "Leveraging legacy system dollars for E-business". (IEEE) IT Pro, May/June 2000.
[Nose’90] Nosek, J. & Palvia, P. (1990). "Software maintenance management: changes in the last decade". Journal of Software Maintenance: Research and Practice 2 (3).
[Mart’11] Martin, R.C. (2011). http://blog.8thlight.com/uncle-bob/2011/09/30/Screaming-Architecture.html
[Dijk’74 ] Dijkstra, E. W. (1974). On the role of scientific thought. Selected Writings on Computing: A Personal Perspective.
[Kicz’96] Kiczales, G., Irwin, J., Lamping, J., Loingtier, J., M., Lopes, C., V., Maeda, C. and Mendhekar, A. (1996). Aspect-oriented programming. ACM Computing Surveys, vol. 28.
[Tarr’99] Tarr, P., Ossher, H., Harrison, W. and Sutton, S. M. (1999). N degrees of separation: multi-dimensional separation of concerns. In ICSE’99: Proceedings of the 21st international conference on Software engineering.
[Leto’86] Letovsky, S. and Soloway, E. (1986). Delocalized Plans and Program Comprehension. IEEE Software, 3(3).
[Ruga’95] Rugaber, S., Stirewalt, K. and Wills, L. M. (1995). The interleaving problem in program understanding. In WCRE’95: Proceedings of the 2nd Working Conference on Reverse Engineering.
[Simm’06] Simmons, S., Edwards, D., Wilde, N., Homan, J. and Groble, M. (2006). Industrial tools for the feature location problem: an exploratory study. Journal of Software Maintenance and Evolution Research and Practice, 18(6).
[Mart’02] Martin, R. C. (2002). Agile Software Development, Principles, Patterns, and Practices. Prentice Hall.
[Stev’74] Stevens, W. P., Myers, G. J. and Constantine, L. L. (1974). Structured Design. (E. Yourdon, Ed.)IBM Systems Journal, 13(2).
[Hunt’99] Hunt, A., & Thomas, D. (1999). The Pragmatic Programmer: From Journeyman to Master. Addison-Wesley Professional.
(Many of these papers are available online through Google Scholar, Citeseerx and the authors’ websites)
![Page 46: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/46.jpg)
Feature tracer [backup]
![Page 47: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/47.jpg)
![Page 48: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/48.jpg)
Part III
Paradoxes of API Design
![Page 49: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/49.jpg)
Modularity is relative to change
• API are like stars (paradox 19)
• Designing a universe
• Distributed development (paradox 2)
• Can't know all your users
• Envisioning them via use-cases
• Sustaining (paradox 3)
• One try to get API right
![Page 50: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/50.jpg)
How to anticipate future changes?
• Client vs. Provider APIs (paradox 9)
• Open spaces
• Fixed points
• Stable API evolves
• Backward compatibility (paradox 6)
• Beware of API-less APIs (paradox 8)
• Mediawiki experience
• Loyal customer
![Page 51: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/51.jpg)
Logical vs. Physical Design
• Design oriented on class relationship
• UML, specifications
• Packaging into JARs ignored (paradox 17)
• Influences deployment (paradox 7)
• Defines APIs
• Good common ground (paradox 11)
• Improves your design
![Page 52: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/52.jpg)
A „weight“ of a module
• Environment for a module
• Modules don't live in vacuum
• Expressed by dependencies (paradox 17)
• Weight
• Number & scope of outgoing dependencies
• Less is more (paradox 19)
• Single responsibility principle
![Page 53: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/53.jpg)
Use vs. Re-use
• Kirk Knoernchild
• Monolithic API is easier to use
• Modular API is easier to re-use
• Blackbox pattern (paradox 18)
• OSGi Capabilities
• Good tooling
• Wizards
![Page 54: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/54.jpg)
SOLID APIs
• Single responsibility principle
• Meaning of modifiers (paradox 15)
• Client vs. provider APIs (paradox 9)
• Lightweight API modules
• Open/closed principle
• OK for provider APIs
• Disastrous for client APIs
• Proliferation of instanceof in user code
• Alternative behavior (paradox 16)
![Page 55: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/55.jpg)
SOLID APIs II
• Liskov substitution principle
• AWT Frame extends Component!
• Don't expose deep hierarchies
• Use delegation rather than inheritance
• Client API should be in final classes
• 1:N factory methods
![Page 56: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/56.jpg)
SOLID APIs III
• Interface segregation principle
• Lookup & discover
• OSGi declarative services
• Dependency inversion principle
• Code against interfaces, not implementations
• Does not imply classes are bad (paradox 9)
• Don't fear (injectable) singletons (paradox 14)
![Page 57: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/57.jpg)
API in User Eyes
• Clueless users (paradox 1)
• Have always something else to do
• Evaluation of an API (paradox 4)
• Coolness
• Time to market
• Total cost of ownership
![Page 58: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/58.jpg)
Collaboration
• Maintenance (paradox 10)
• Rely on patches
• Accepting unacceptable (paradox 13)
• Beauty (paradox 5)
• One writer and dozens of users
• Sacrifice the writer
![Page 59: JavaOne’12 Session 3992 - Software Modularity: Paradoxes, Principles, and Architectures](https://reader033.vdocument.in/reader033/viewer/2022051111/5562c209d8b42aaf178b4bfe/html5/thumbnails/59.jpg)
Summary
• http://paradoxes.apidesign.org