Chapter 1 of API Design
The Object
Guideline 1. Design objects for people, not for computers
by Bill Venners

Part 2 of 21

Managing Complexity

Moore's law says that computer hardware capability doubles every 18 months. For programmers, this is good news and bad news. The good news is that programmers get to work with ever more blazing machines. The bad news is that as hardware becomes more powerful, software becomes larger and more complex. One way objects assist programmers is by helping them manage software's increasing complexity .

Large software systems are difficult to understand. If a system is composed of individual object pieces, however, each object can embody an amount of complexity that programmers can fully grasp. Programmers can then understand the system's behavior as a whole in terms of the behavior of its object pieces and the interactions between them. A well-designed object, therefore, is understandable.

During an object-oriented design, you divide the system functionality into areas of responsibility. You assign each area of responsibility to a class, and give each class a name. For each named class, you devise a bundle of services (each service offered by a method) through which that class's instances fulfill their responsibilities. By focusing each object on an area of responsibility that encompasses a reasonable level of complexity, you help programmers who use your objects deal with the overall complexity of their systems.

Understanding is further enhanced through the practice of naming classes after relevant concepts from the problem domain, such as Account, Matrix, or StampDispenser. To the extent that classes model familiar real-world concepts from the problem domain, programmers can find it easier to understand and use instances of those classes.

Programmers can also find it easier to comprehend object-oriented systems because their organization is similar to that of human activities. If you have a goal, you can hire people to help you achieve that goal. Each person agrees to perform a particular job. You organize and direct their individual efforts to help you achieve your overall goal. Similarly, to accomplish a goal in a system, you enlist the help of objects. Each object must fulfill the obligations delineated in its contract. By organizing and directing the services provided by the objects, you can achieve your overall goal for the system.

Objects also help programmers manage complexity by facilitating communication. Types have names that have meaning to the programmers working on a system. A type name implies an areas of responsibility. It implies the methods through which instances fulfill those responsibilities. It imples intended usage, performance characteristics, and so on. As programmers discover, name, and define types during an object-oriented design, a vocabulary develops. This vocabulary, comprised of type names and their meanings, facilitates communication among the programmers. The more effectively programmers can communicate about their system, the more effectively they can tame its complexity.

Lastly, objects help programmers create systems that, despite being complex, are robust. When you organize your system with objects, you tend to encapsulate code that manipulates particular data inside the class that contains the data. This keeps code that operates on particular data from replicating and spreading throughout the system. If you detect a bug that corrupts certain data, you need only look in one place to find the bug: the code that defines the class's methods. Once you fix that bug in the class's code, you know it is fixed everywhere, because that code is the only code that can manipulate the data. This process of encapsulating code with data in classes, combined with a strong separation of interface and implementation, helps programmers build objects that are thoroughly debugged and, therefore, reliable and robust. To build a robust system, you must to the extent possible construct the system out of robust parts. Objects help programmers build systems that, despite their overall complexity, are robust because their systems are constructed out of robust object parts.

Part 2 of 21

API Design | Contents | Book List | Printer Friendly Version | Previous | Next

Last Updated: Friday, April 26, 2002
Copyright © 1996-2002 Artima Software, Inc. All Rights Reserved.
URL: is created by Bill Venners