![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