Book contents
- Frontmatter
- Contents
- List of Figures
- List of Tables
- Preface
- Acknowledgments
- Disclaimer
- PART I THE TAO OF SCIENTIFIC OOP
- PART II SOOP TO NUTS AND BOLTS
- 4 Design Patterns Basics
- 5 The Object Pattern
- 6 The Abstract Calculus Pattern
- 7 The Strategy and Surrogate Patterns
- 8 The Puppeteer Pattern
- 9 Factory Patterns
- PART III GUMBO SOOP
- Appendix A Mathematical Background
- Appendix B Unified Modeling Language Elements
- Bibliography
- Index
9 - Factory Patterns
from PART II - SOOP TO NUTS AND BOLTS
Published online by Cambridge University Press: 01 June 2011
- Frontmatter
- Contents
- List of Figures
- List of Tables
- Preface
- Acknowledgments
- Disclaimer
- PART I THE TAO OF SCIENTIFIC OOP
- PART II SOOP TO NUTS AND BOLTS
- 4 Design Patterns Basics
- 5 The Object Pattern
- 6 The Abstract Calculus Pattern
- 7 The Strategy and Surrogate Patterns
- 8 The Puppeteer Pattern
- 9 Factory Patterns
- PART III GUMBO SOOP
- Appendix A Mathematical Background
- Appendix B Unified Modeling Language Elements
- Bibliography
- Index
Summary
“Separate the physics from the data.”
Jaideep RayThe Problem
The patterns discussed in Chapters 6–7 adhere closely to the GoF philosophy of designing to an interface rather than an implementation. That maxim inspired the use of abstract classes in defining an abstract calculus, a strategy, and a surrogate. The puppeteer definition in Chapter 8 represented the one setting in which client code manipulated concrete implementations directly – although an exercise at the end of that chapter describes a way to liberate the puppeteer from the tyranny of implementations also.
Independent of whether the classes comprising the pattern demonstrations are abstract, the client codes (main programs in the cases considered) exploit knowledge of the concrete type of each object constructed in Chapters 6–8. Although we were able to write polymorphic procedures such as integrate in Figures 6.2(b) and 6.3(b)–(c), in each case, the actual arguments passed to these procedures were references to concrete objects the client constructed. One can write even more flexible code by freeing clients of even this minimal knowledge of concrete types. This poses the dilemma of where object construction happens. Put simply, how does one construct an object without directly invoking its constructor? Or from another angle, how does an object come to be if the client knows only the interface defined by its abstract parent, but that parent's abstract nature precludes definition of a constructor? By definition, no instance of an abstract type can be instantiated.
- Type
- Chapter
- Information
- Scientific Software DesignThe Object-Oriented Way, pp. 202 - 228Publisher: Cambridge University PressPrint publication year: 2011