Design Pattern: Treating Objects as Descriptors
I think frequently about the design of software while I drive between home and work. I frequently come across the problem of designing user-defined, compound types or classes. Determining a compound type’s member fields and methods requires a lot of effort. The problem’s complexity is increased when an instance of a class consists of fields drawn from multiple tables in a database. Designing a class that is used in a web application is made more complicated by the stateless nature between each request of a browser. The general problem is stated as designing a class that draws information from multiple sources and supports class instances with short lifetimes.
In practice, determining the interface of an object is difficult. The use of “accessors” and “modifiers,” functions that access and modify an object’s state or internal data, is common practice among software engineers. The use of these functions helps control the operations that can be performed on an object, and it it helps maintain consistency in an object’s state. It also allows the internal implementation of a class to be modified without affecting the code that operates on instances of the class. There may be problems, however, with the tying functions and data into classes too tightly.
An example of an original Person class design is presented below with several interface functions.
class Person
{
private Name m_name;
private Date m_birthdate;
private String m_password;
public function SetName( Name name );
public function GetName();
public function SetBirthdate( Date date );
public function GetBirthdate();
public function SetPassword( String password );
public function GetPassword();
}
The m_password field of the Person object may be retrieved from a database table named User_Passwords while the other information is fetched from the User_Pedrigree table. In the example system, code that accesses or modifies user passwords is spread throughout the system, but execution of the code is infrequent. Although the password information may be used in only 5% of operations that deal with Person object, because the object’s consistency is maintained, the password is always retrieved. With this interface, “person->GetPassword()” and “person->SetPassword( new_password )” may be in multiple places of the code.
Assuming that retrieving the password information is later found to be an expensive operation and that expense is paid every time a Person object is created, a couple of modifications to the operations on the class may be used to improve system performance. The underlying operation of retrieving a password can be reworked, or the password information can be separated from the type definition. Two refactorings of the Person object are presented below. The first treats the object as a descriptor to a function. The second refactoring reimplements the class to delay the retrieval of the password information.
Separating the password information from the Person object may force the removal of the GetPassword() and SetPassword() functions, and this will further require updates to code that rely on these functions. The need would have been avoided, if these interface functions were not present in the original class and independent functions were implemented to provide the same functionality. Code that operated on Person objects would appear as “GetPassword( person )” and “SetPassword( person, new_password )” instead of “person->GetPassword()” and “person->SetPassword( new_password )” as mentioned above.
Separating the password functions from the class is problematic, because it is against the goal of tightly grouping data and functions with classes. The code becomes less cohesive with this approach.
Delaying the retrieval of password information until it is first requested improves the example system’s performance. Resources are not used to retrieve password information, until it is first used. This has the benefit of allowing the object’s state to continue appearing consistent, and it allows code to continue enjoying the benefit of using classes to group functions and data.
The second option described above appears to be the better solution that addresses the example problem. Considering the first option may still be desirable in cases such as when the degree of cohesion between the class and its member data is unstable.
I decided to make the move this weekend. Witnessing