Today’s world of software design and development is all about managing
complexity. Computer-savvy users want more and more features. Software
products, such as Microsoft Word and Excel, set high expectations. The
business environment requires software to react quickly to shifting corporate
needs. And tools and technologies are changing faster than ever. It is
easy to become overwhelmed by the complexity.
The key to successful software is managing this complexity—and managing
complexity is one of the goals of object orientation (OO). Object-oriented
means looking at a software system in terms of the things, or
objects, that are relevant to that system and how those objects interact. As
you design and then build your application, you can focus on one object at
a time, temporarily ignoring the complexities of the rest of the system.
OO concepts are used in many professions. For example, when
designing an office, an architect thinks about working spaces, foundations,
frameworks, and plumbing systems. These are the real-world objects. The
architect does not concentrate on the process of pouring the foundation,
hammering nails, or connecting the plumbing, nor on the details of the
data, such as how much concrete or how many nails. These lower-level
processes and details are important but not applicable to the high-level
design of an office building. And without the high-level design, the processes
and data details are irrelevant.
Object orientation does not ignore the data or the process. It combines
the best of a procedure-oriented view (where the focus is on the
process) and a data-centric view (where the focus is on the data) and adds
productivity concepts such as reuse, testability, and, of course, managing
complexity.
Consider a time sheet. Using a data-centric view, the key data elements
are the employee name, date, and hours worked. But just looking at the
data does not provide the full picture of time sheet processing. Using a
procedure-oriented view, the focus is on the process of generating the time
sheet. But this does not consider the bigger picture of how the time sheet
fits into an overall system.
From an object-oriented perspective, the time sheet has data (called
properties) and processes (called methods). It also has relationships to
other objects in the system, such as an employee object, a logging object,
a data access object, and so on.
Thinking about an application in an object-oriented way makes it
easier to break the application into its parts (objects), focus on the most
important aspects of each part, and look at the relationships between those
parts. And since Visual Basic is now a fully object-oriented programming
language, using an object-oriented approach to thinking about your application makes it easier to map these thoughts into object-oriented code.
Excerpt from "Doing Objects in Visual Basic 2005".
For more information on using object-oriented techniques, see the following links:
Enjoy!