Java Application Architecture lays the foundation you’ll need to incorporate modular design thinking into your development initiatives. Before it walks you through eighteen patterns that will help you architect modular software, it lays a solid foundation that shows you why modularity is a critical weapon in your arsenal of design tools. Throughout, you’ll find examples that illustrate the concepts. By designing modular applications today, you are positioning yourself for the platform and architecture of tomorrow.
Salient Features * Introduces 18 new modular patterns, identified by the author - the next logical step in the evolution of object-oriented programming * These patterns help developers break up large software projects into smaller, more accessible chunks, or modules * This modular structure makes the software system less complex to develop, and easier to maintain and update
About the Author Kirk Knoernschild is a software developer who has filled most roles on the software development team. Kirk is the author of Java Design: Objects, UML, and Process (Addison-Wesley, 2002), and he contributed to No Fluff Just Stuff 2006 Anthology (Pragmatic Bookshelf, 2006). Kirk is an open source contributor, has written numerous articles, and is a frequent conference speaker. He has trained and mentored thousands of software professionals on topics including Java/J2EE, modeling, software architecture and design, component-based development, service-oriented architecture, and software process.
Table of Contents Part I: The Case for Modularity Chapter 1: Module Defined
1.1 Defining a Module 1.2 Succinct Definition of a Software Module 1.3 Conclusion
Chapter 2: The Two Facets of Modularity 2.1 The Runtime Model 2.2 The Development Model 2.3 Modularity Today 2.4 Conclusion
Chapter 3: Architecture and Modularity 3.1 Defining Architecture 3.2 A Software Architecture Story 3.3 The Goal of Architecture 3.4 Modularity: The Missing Ingredient 3.5 Answering Our Questions 3.6 Conclusion 3.7 References
Chapter 4: Taming the Beast Named Complexity 4.1 Enterprise Complexity 4.2 Technical Debt 4.3 Design Rot 4.4 Cyclic DependenciesThe Death Knell 4.5 Joints, Modules, and SOLID 4.6 Managing Complexity 4.7 Benefits of Modularity 4.8 Conclusion 4.9 References
Chapter 5: Realizing Reuse 5.1 The Use/Reuse Paradox 5.2 The Reuse Disclaimer 5.3 Reuse or Use 5.4 Modular Tension 5.5 Modular Design 5.6 Conclusion 5.7 Reference
Chapter 6: Modularity and SOA 6.1 All the Way Down, Revisited 6.2 GranularityArchitectures Nemesis 6.3 An Alternate View 6.4 Conclusion
Chapter 7: Reference Implementation 7.1 Why No OSGi? 7.2 Background on This Exercise: Building the System 7.3 Version 1 7.4 First Refactoring 7.5 Second Refactoring 7.6 Third Refactoring 7.7 Fourth Refactoring 7.8 Fifth Refactoring 7.9 Sixth Refactoring 7.10 Seventh Refactoring 7.11 The Postmortem 7.12 Conclusion 7.13 Reference
Part II: The Patterns Chapter 8: Base Patterns Manage Relationships Module Reuse Cohesive Modules
Abstract Modules Implementation Factory Separate Abstractions Reference
Chapter 12: Utility Patterns Colocate Exceptions Levelize Build Test Module
Part III: Poma and OSGi Chapter 13: Introducing OSGi 13.1 Some History 13.2 Benefits of OSGi 13.3 Digesting OSGi 13.4 OSGi Bundle 13.5 OSGi Runtime Management 13.6 The Two Facets of Modularity, Revisited 13.7 OSGi and the Patterns
Chapter 14: The Loan Sample and OSGi 14.1 Getting Started 14.2 The Manifests 14.3 Services 14.4 Installation and Execution 14.5 Conclusion
Chapter 15: OSGi and Scala 15.1 Getting Started 15.2 The Scala Code 15.3 Scala Bean Configurtion 15.4 Scala Service Configuration 15.5 Building the Scala Module 15.6 Installation and Execution 15.7 Conclusion
Chapter 16: OSGi and Groovy 16.1 Getting Started 16.2 The Groovy Code 16.3 Groovy Bean Configuration 16.4 Groovy Service Configuration 16.5 Building the Groovy Module 16.6 Installation and Execution 16.7 Conclusion
Chapter 17: Future of OSGi 17.1 OSGi as an Enabler 17.2 The Disruption 17.3 The Power of Ecosystems 17.4 The Ecosystem 17.5 Conclusion
Appendix: SOLID Principles of Class Design Single Responsibility Principle (SRP) Open Closed Principle (OCP) Liskov Substitution Principle (LSP) Dependency Inversion Principle (DIP) Interface Segregation Principle Composite Reuse Principle (CRP)
References Index
Title
Java Application Architecture: Modularity Patterns with Examples Using OSGi
Hello, Sign in 
Cart 
