Java Application Architecture
Pearson (Verlag)
978-0-321-24713-1 (ISBN)
- Keine Verlagsinformationen verfügbar
- Artikel merken
This isn’t the first book on Java application architecture. No doubt it won’t be the last. But rest assured, this title is different. The way we develop Java applications is about to change, and this title explores the new way of Java application architecture.
Over the past several years, module frameworks have been gaining traction on the Java platform, and upcoming versions of Java will include a module system that allows you to leverage the power of modularity to build more resilient and flexible software systems. Modularity isn’t a new concept. But modularity will change the way we develop Java applications, and you’ll only be able to realize the benefits if you understand how to design more modular software systems.
Java Application Architecture will help you
Design modular software that is extensible, reusable, maintainable, and adaptable
Design modular software today, in anticipation of future platform support for modularity
Break large software systems into a flexible composite of collaborating modules
Understand where to place your architectural focus
Migrate large-scale monolithic applications to applications with a modular architecture
Articulate the advantages of modular software to your team
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. That’s why Uncle Bob is dancing.
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. You can visit his website at techdistrict.kirkk.com.
Foreword by Robert C. Martin xix Foreword by Peter Kriens xxi
Acknowledgments xxv
About the Author xxvii
Introduction 1
Object-Oriented Design 2
Logical versus Physical Design 3
Modularity 4
Who This Book Is For 6
How This Book Is Organized 7
Pattern Form 10
Pattern Catalog 12
The Code 13
An Opening Thought on the Modularity Patterns 14
Reference 14
Part I: The Case for Modularity 15
Chapter 1: Module Defined 17
1.1 Defining a Module 17
1.2 Succinct Definition of a Software Module 20
1.3 Conclusion 20
Chapter 2: The Two Facets of Modularity 21
2.1 The Runtime Model 21
2.2 The Development Model 22
2.3 Modularity Today 25
2.4 Conclusion 27
Chapter 3: Architecture and Modularity 29
3.1 Defining Architecture 29
3.2 A Software Architecture Story 30
3.3 The Goal of Architecture 33
3.4 Modularity: The Missing Ingredient 36
3.5 Answering Our Questions 43
3.6 Conclusion 44
3.7 References 44
Chapter 4: Taming the Beast Named Complexity 45
4.1 Enterprise Complexity 46
4.2 Technical Debt 47
4.3 Design Rot 48
4.4 Cyclic Dependencies–The Death Knell 50
4.5 Joints, Modules, and SOLID 56
4.6 Managing Complexity 57
4.7 Benefits of Modularity 59
4.8 Conclusion 60
4.9 References 60
Chapter 5: Realizing Reuse 61
5.1 The Use/Reuse Paradox 62
5.2 The Reuse Disclaimer 63
5.3 Reuse or Use 64
5.4 Modular Tension 65
5.5 Modular Design 66
5.6 Conclusion 67
5.7 Reference 68
Chapter 6: Modularity and SOA 69
6.1 All the Way Down, Revisited 69
6.2 Granularity–Architecture’s Nemesis 72
6.3 An Alternate View 79
6.4 Conclusion 80
Chapter 7: Reference Implementation 83
7.1 Why No OSGi? 83
7.2 Background on This Exercise: Building the System 84
7.3 Version 1 85
7.4 First Refactoring 87
7.5 Second Refactoring 90
7.6 Third Refactoring 93
7.7 Fourth Refactoring 95
7.8 Fifth Refactoring 98
7.9 Sixth Refactoring 99
7.10 Seventh Refactoring 102
7.11 The Postmortem 103
7.12 Conclusion 110
7.13 Reference 110
Part II: The Patterns 111
Chapter 8: Base Patterns 115
Manage Relationships 116
Module Reuse 125
Cohesive Modules 139
Chapter 9: Dependency Patterns 145
Acyclic Relationships 146
Levelize Modules 157
Physical Layers 162
Container Independence 170
Independent Deployment 178
Reference 185
Chapter 10: Usability Patterns 187
Published Interface 188
External Configuration 200
Default Implementation 206
Module Facade 212
Chapter 11: Extensibility Patterns 221
Abstract Modules 222
Implementation Factory 229
Separate Abstractions 237
Reference 244
Chapter 12: Utility Patterns 245
Colocate Exceptions 246
Levelize Build 253
Test Module 263
Part III: Poma and OSGi 271
Chapter 13: Introducing OSGi 273
13.1 Some History 273
13.2 Benefits of OSGi 274
13.3 Digesting OSGi 276
13.4 OSGi Bundle 277
13.5 OSGi Runtime Management 279
13.6 The Two Facets of Modularity, Revisited 279
13.7 OSGi and the Patterns 279
Chapter 14: The Loan Sample and OSGi 283
14.1 Getting Started 283
14.2 The Manifests 285
14.3 μServices 286
14.4 Installation and Execution 292
14.5 Conclusion 293
Chapter 15: OSGi and Scala 295
15.1 Getting Started 295
15.2 The Scala Code 296
15.3 Scala Bean Configuration 299
15.4 Scala μService Configuration 299
15.5 Building the Scala Module 300
15.6 Installation and Execution 300
15.7 Conclusion 301
Chapter 16: OSGi and Groovy 303
16.1 Getting Started 303
16.2 The Groovy Code 304
16.3 Groovy Bean Configuration 306
16.4 Groovy Service Configuration 307
16.5 Building the Groovy Module 307
16.6 Installation and Execution 308
16.7 Conclusion 309
Chapter 17: Future of OSGi 311
17.1 OSGi as an Enabler 312
17.2 The Disruption 312
17.3 The Power of Ecosystems 314
17.4 The Ecosystem 316
17.5 Conclusion 317
Appendix: SOLID Principles of Class Design 319
Single Responsibility Principle (SRP) 320
Open Closed Principle (OCP) 320
Liskov Substitution Principle (LSP) 323
Dependency Inversion Principle (DIP) 325
Interface Segregation Principle 327
Composite Reuse Principle (CRP) 329
References 335
Index 337
| Reihe/Serie | Robert C. Martin Series |
|---|---|
| Sprache | englisch |
| Maße | 179 x 231 mm |
| Gewicht | 618 g |
| Einbandart | kartoniert |
| Themenwelt | Informatik ► Programmiersprachen / -werkzeuge ► Java |
| Mathematik / Informatik ► Informatik ► Web / Internet | |
| ISBN-10 | 0-321-24713-2 / 0321247132 |
| ISBN-13 | 978-0-321-24713-1 / 9780321247131 |
| Zustand | Neuware |
| Haben Sie eine Frage zum Produkt? |
aus dem Bereich
