- Objects, Components, and COM
- Abstraction and Class Modeling
- Encapsulation
- Polymorphism
- Inheritance
- Association Relationships
- One-to-One Relationships
- One-To-Many Relationships
- Class and Object Naming Conventions
- Component-Based Development
- Component-Based Development and COM
- COM-Definable Entities
- Component Coupling
- Summary
Abstraction and Class Modeling
What is most striking about object-orientation is that it follows the true sense of the business world. In this world, anything that a business deals with, whether it is a widget that a company produces or a financial account that a bank maintains on behalf of a client, is definable in software terms through a class model. This class model defines the information pertinent to the business entity, along with the logic that operates on that information. Additionally, a class definition can contain references to one or more external classes through association or ownership relationships. In the case of a financial account, informational elements might include the account number, the names of the account owners, the current balance, the type of account, and so on. We call these items properties (also known as attributes) of the class. Similarly, the class can define a function to add a new transaction to the account or modify/delete an existing transaction. We call these items methods (also known as operations) of the class. What differentiates a class from an object is that a class is a definition, whereas an object is an instance of that definition.
We can also graphically represent our objects using a class diagram. There are many different views on how to represent these diagrams, but the most pervading forms are the Yourdon/Coad and the Rumbaugh methods, named after the individuals who developed them. Many drawing programs have templates predefined for these models, whereas many modeling tools can support some or all of the more popular styles. You can also create your own object modeling technique using simple lines and boxes. We have chosen to use the Rumbaugh model in this book because of the popularity of the Unified Modeling Language (UML), of which it is a component. It also happens to be the model used by the Microsoft Visual Modeler that is bundled with Visual Studio 6.0 Enterprise Edition. Figure 3.1 shows an example of a graphical depiction for a financial account class.
){kind=link}
Figure 3.1 The CAccount class using the UML graphical model.
TIP
It is important to decide on a graphical object representation model early in the project. Make sure that everyone understands how to read it and feels comfortable with it. This model will be your roadmap as you work your way through all phases of the application development process and will be critical as the complexity starts to build.
As you can see, we modeled our real-world Account business entity in terms of properties and methods. We call this modeling process abstraction, which forms the basis for object orientation. With this in mind, we can further our discussion of other features of object-orientation.