Fog Creek Software
Discussion Board




Entity Class Question

I just returned from holiday and while catching up on my reading, I read over Joel's description of his design for Entity classes.  As described, the entity class appears to function as both an instance of a domain class as well as a collection of instances.  (actually an enumerator of a collection of instances, for any nitpickers) I am wondering if this doesn't go against common wisdom which states that a given class of objects should do one and only one thing.  (I think this is known as the "Single Responsibility Principle"  see: http://www.objectmentor.com/resources/articles/srp).  So, I am wondering if I am missing something.  Does Joel's design have a clear advantage over a similar design which uses one class to capture instance behavior and a separate class to capture enumeration semantics? 

Puzzled Beginner
Thursday, January 09, 2003

Both the instance and the enumeration require a member for each field(column), which would cause a lot of duplication between the two. That's twice as many classes to modify if you add a column.

You could make it so that the enumeration inherited from the instance to avoid this problem, but (a) visual basic doesn't support implementation inheritence, and (b) even if it did, I would rather have the entity classes inheriting from a base class that did all the common entity stuff -- inheritence should be used for "is-a" relationships.

I learned this from experience; FogBUGZ has a separate entity class for the enumeration and the singletons and it's kind of a waste.

Besides, since an enumeration has a concept of "current record," enumerating is really just an operation on a record, and can logically be seen as a method ("getnext") of a record.

Joel Spolsky
Thursday, January 09, 2003

"Both the instance and the enumeration require a member for each field(column), which would cause a lot of duplication between the two."

Why?
If you a set of objects and you separate managing the objects and managing the object data, you would have two distinct objects. One data object, one manager object.
The data object would have members to access the data, and the manager object would have members to access the objects. The latter could be random access or sequential access, that would not matter.
Enumeration would be going to the manager object and ask for the next object, possibly passing it an object of which you want the next. The manager object would then getch that object and pass it back to you.

This way you get separation of responsibilities and decoupling of implementation. Should your data source be modified in terms of data access, you only need to modify the manager. Should your data source be modified in terms of data contents, you only need to modify the data object class.
Another advantage you would be that you can have any kind of access to data objects. Enumerated, indexed, or keyed by whatever key you like. Your manager object can implement (or delegate) whatever logic it needs to provide the type of access you need.

And to whink at another discussion, I am sure I have just described a design pattern or two :-)

Practical Geezer
Friday, January 10, 2003

Actually, here's a fragment of documentation of a piece of software that uses this design. Don't mind the details...

<--->
5.1 Accessing alarm-contact data

5.1.1 Alarm-contact data

Alarm contacts are stored in Contact objects. These objects contain the following data:

- Alphadesk identification number. This is the number that the PS system uses to identify a contact.

- Local identification number. This is the number that the Windesk uses internally to identify a contact.

- Location. This is the number that identifies the location that is associated with a contact. It is the number that PS system uses to identify locations.

- MPC contact. This is the number that identifies the contact input of the MPC that a contact is connected to.

- MPC head. This is the number that identifies the MPC head that a contact is connected to.
Contact objects are managed by the Contact Manager object.

<--->

Practical Geezer
Friday, January 10, 2003

Right, just pasted only half of the content, here's the rest:

<--->
5.1.2 Access to alarm-contact data

The Contact Manager object provides:

- Access by internal (local) identification number. Every contact is assigned a unique identification number. This number remains valid until the contact is discarded.

- Access by external (Alphadesk) identification number. The PS system uses a unique identification number -- that is independent from the internal identification number -- nto reference a specific alarm contact.

- Access by index number. Contact objects are indexed from 1 to the total number of objects. The total number of objects can be retrieved from the Contact Manager.

<--->

Practical Geezer
Friday, January 10, 2003

Joel's approach sits neatly on top of a Recordset object.

John Ridout
Friday, January 10, 2003

*  Recent Topics

*  Fog Creek Home