Preface

A Different (and Possibly Controversial ) Kind of Software Book

This book will be deliberately different from almost any other object analysis/ design, component-based development, software development methodology, or extreme programming (XP) book you may have encountered . It s also likely to be controversial, which is not intended but is, perhaps, inevitable. Several factors contribute to this book s differences:

• The reader will be asked to read and digest a lot of history and philosophy before embarking on the more pragmatic aspects of object thinking.

• The author will unabashedly, adamantly, and consistently advocate behavior as the key concept for discovering, describing, and designing objects and components .

• The centrality of CRC (Class-Responsibility-Collaborator) cards as an object thinking device or tool will likely be viewed as anachronistic and irrelevant since UML (Unified Modeling Language) has achieved the status of de facto standard.

• The apparent indifference, or even antagonism, toward formalism and the formal approaches to software specification that are intrinsic to the behavioral approach will concern some readers, especially those trained in computer science departments at research universities.

• The emphasis on analysis and conceptualization ”that is, on thinking ”instead of on implementation detail might strike some readers as academic.

It will take the rest of the book to explain why these differences are important and necessary, but the motivation behind them is found in this 1991 quote from Grady Booch:

Let there be no doubt that object-oriented design is fundamentally different than traditional structured design approaches: it requires different ways of thinking about decomposition, and it produces software architectures that are largely outside the realm of the structured design culture.

Different ways of thinking is the key phrase here, and the word culture is equally important. The history of objects in software development is characterized by the mistaken notion that the object difference was to be found in a computer language or a software module specification. But objects are fundamentally different because they reflect different ideas ”particularly about decomposition ”and because they reflect a different set of values and a different worldview (that is, culture) from that of traditional software development. Understanding objects requires understanding the philosophical roots and historical milestones from which objects emerged.

Readers will be expected to review and reflect on two competing philosophical traditions ”formalism and hermeneutics-postmodernism ”that are responsible for the value systems and ideas leading to the competition and heated disagreements between advocates of software engineering (who value formalism) and advocates of XP/agile methodologies/behavioral objects (who value hermeneutics). A quick look at the history of programming in general will show that XP and agile methodologies are but the latest manifestations in this long-standing philosophical feud, which has also influenced our (mis)understanding of objects and patterns.

Distractions to object thinking, such as which programming language is best, will be shown to be mostly irrelevant with a brief recap of classical languages claiming to be object-oriented. This historical excursion will also show you how ideas become manifest in tools ”in this case programming languages ”and how philosophical principles and cultural values shape software development methods and processes.

Metaphor and vocabulary play a major role in shaping object thinking. Metaphors are essential for bridging the familiar and the unfamiliar, and selection of the right metaphors is critical for further development of fundamental ideas. Likewise, vocabulary provides us with one of the essential tools for thinking and communicating. It s important to understand why object advocates elected to use a different vocabulary for object thinking and why it s inappropriate to project old vocabulary onto new concepts.

As you might expect by now, the prominent role of formally defined models, methods, and processes will be discounted in this book; their claim to be repositories of objective truth will be challenged. This book will suggest that methods are little more than helpful reminders of things to think about and that models are only a form of external short- term memory useful in the context of a particular group of people at a particular point in time. These biases will be linked to XP/agile approaches.

Note that I ll also provide applications of the ideas this book offers. I ll provide several examples as illustrations of how the ideas exhibit themselves in practice.

However focused on a particular topic each section of this book might be, an overarching bias or perspective colors every discussion: behaviorism . If a single word could be used to capture the different ways of thinking about decomposition noted by Booch, it would be behavior . The centrality of behavior will be most evident when we consider and compare traditional definitions and models of objects.

A majority of the published books on objects mention using behavior as the criterion for conceptualizing and defining objects. Many claim to present behavioral approaches to object development. However, with one or two exceptions, ^[1] they provide object definitions and specification models that owe more to traditional concepts of data and function than to behavior. Even when behavior is used to discover candidate objects, that criterion is rapidly set aside in favor of detailed discussions of data attributes, member functions , and class/ entity relationships. This book s focus on behavior, on its aspects and implications, is consistent, I believe, with both the origins of object ideas and the design tradition assumed by XP/agile.

Material in this book is presented in a matter-of-fact style, as if everything stated were unequivocally correct. I ll cite alternative ideas and approaches, but I ll make little effort to incorporate those alternatives or to discuss them in detail. This is not because I am unaware of other viewpoints or because I am dismissive of those viewpoints. Alternative ideas are best expressed by their advocates. To the extent that this book is used as a classroom text, discussion of alternative viewpoints and alternative texts is the purview of the instructor.

^[1] Wirfs-Brock, Weiner, and Wilkerson s Objected Oriented Design offers a behavior-based method, as does Wilkinson s Using CRC Cards .