Part IV: Professional Database Development
994
m_ReorderLevel = -1
m_Discontinued = False
‘Also assign default value to ProductID.
‘This will serve as a signal to the consumer
‘that a product was not found:
m_ProductID = -1
‘An alternate approach would be to raise an
‘event telling the consumer that the product
‘could not be found.
End If
End Property ‘Property Let ProductID
This is a good example of encapsulation. Instead of requiring a consumer of the Product class to
select the product data, the Product class easily supplies the data through the ProductID setting.
This small example also illustrates one of the major benefits of object-oriented programming: In a
well-designed application, the only way to retrieve product data should be through the Product
class. No other portion of the application needs to know anything about where the product data is
stored, how to select or insert product data, and so on. In the future, should the need arise to
change the product data source, only the Product class is updated, and all other portions of the
application continue to function as before, without any changes.
Consider the time savings in a large application where the product data is used in dozens or even
hundreds of different places. Good object-oriented design enforces modular programming and
provides significant efficiencies when maintaining medium to large applications.
Adding a new property to provide extra information
One of the things that bothers me about the Northwind Traders application is that it relies very
heavily on Access-only constructs. In particular, most of the tables, when viewed in Datasheet
view, display related data. For example, opening the Products table in Datasheet view shows the
product category and supplier information, and not the ID values associated with each of these
items. The supplier name is shown in the Products table because the lookup properties of the
SupplierID field are set to display a combo box containing the supplier names.
I’ve found these constructs to be confusing to users, especially people new to Access. Most people,
when they see the supplier’s name in the Products table, expect to find the supplier name among
the data stored in the table. However, the only type of supplier information in the Products table
is the SupplierID. If the supplier name is required, you must extract it the from the
Suppliers table, using the SupplierID as the criterion.
An enhancement to the Product class is to make the supplier and category names accessible as
read-only properties. You probably can guess how this is done: Simply extract this information
from the respective tables, using the property variables for the SupplierID and CategoryID
properties.
Here’s the Property Get procedure for the new SupplierName property. The Property Get
for the CategoryName property is virtually identical:
