FAQ 4.15 What is the secret to achieving reuse?

Building a reuse culture.

Some aspects of reuse are technical (such as carrying out successful domain analysis and building extensible, domain-specific frameworks), but the real problems come from human issues. Developers need to lose the attitude that says, "I want to build my own infrastructure because it's more fun and enhances my career" and "I don't trust or want to understand someone else's work, so I'll do everything from scratch." If the human issues aren't resolved, the technology questions become immaterial.

Enlightened leadership and an appropriate reward system can sometimes overcome these problems, but sometimes the project team itself can foster the right attitude. In one case the developers decided that working together was important, and they used the word "big" to describe people and actions that contributed to reuse (as in "That is big of you") and conversely the word "small" to describe people and actions that were petty or self-centered. Thus the words "big" and "small" became an informal mechanism for the team to enforce and reinforce their culture in a reasonably nonthreatening way.

The architectural perspective is to recognize that reuse is much more than a technical question and that there are inherent limits on what is possible. There is no point in investing development effort to achieve reuse if the organizational culture will keep the reuse from actually occurring.

Part II: Object-Oriented Design

Chapters 5 through 10 cover design issues related to the use of C++ as an object-oriented programming language. An understanding of these principles is essential to using C++ effectively, particularly for large projects.

Chapter 5. Object-Oriented Fundamentals

FAQ 5.01 What is the purpose of this chapter?

FAQ 5.02 Why is the world adopting OO technology?

FAQ 5.03 What are some of the benefits of using C++ for OO programming?

FAQ 5.04 What are the fundamental concepts of object-oriented technology?

FAQ 5.05 Why are classes important?

FAQ 5.06 What is an object?

FAQ 5.07 What are the desirable qualities of an object?

FAQ 5.08 How are classes better than the three basic building blocks of procedural software?

FAQ 5.09 What is the purpose of composition?

FAQ 5.10 What is the purpose of inheritance?

FAQ 5.11 What are the advantages of polymorphism and dynamic binding?

FAQ 5.12 How does OO help produce flexible and extensible software?

FAQ 5.13 How can old code call new code?

FAQ 5.14 What is an abstraction and why is it important?

FAQ 5.15 Should abstractions be user -centric or developer-centric?

FAQ 5.16 What's the difference between encapsulation and abstraction?

FAQ 5.17 What are the consequences of encapsulating a bad abstraction?

FAQ 5.18 What's the value of separating interface from implementation?

FAQ 5.19 How can separating interface from implementation improve performance as well as flexibility?

FAQ 5.20 What is the best way to create a good interface to an abstraction?

FAQ 5.21 How are get/set member functions related to poorly designed interfaces?

FAQ 5.22 Should there be a get and a set member function for each member datum?

FAQ 5.23 Is the real purpose of a class to export data?

FAQ 5.24 Should OO be viewed as data-centric?

FAQ 5.01 What is the purpose of this chapter?

To explain fundamental OO concepts.

C++ is a huge language that can be used in many ways. The preceding chapters on management and architectural perspectives limit the ways the language is used, which makes life simpler for developers and maintainers. This chapter further limits the ways in which the language can be (mis)used.

In this book, we assume an OO approach and the C++ presentation reflects this bias. Some readers will need a refresher on OO concepts, and others need to become familiar with our terminology. Hence this chapter presents the basic OO ideas and philosophies that are used throughout the book. Don't take this to mean that all programs must use OO (they don't) or that "C++ as a better C" has no place in life (it does).

Buy on amazon.com >>

Cline M., Lomow G., Girou M.

<< Previous page

Table of contents

Next page >>