Re: What's the Criteria for Promoting a "Thing" to a Class

Responding to MySpamB8...

I'm an OOAD noob, and I'm thinking that "State" (as in the "S" of the
U.S.A.) qualifies as a class, and should be represented as a Class in
my Class Diagram, with its two properties: name and abbreviation.

The answer is a definite Maybe. B-)

The notion of "state", as you have defined it does, indeed, exist in the problem space. It is also clearly a conceptual entity in the problem space with unique characteristics like name, population, location, etc.. There may even be behaviors, like computing state income tax, that you can attribute to it via anthropomorphization to solve some problem.

But whether the notion of 'state' qualifies as a first class object or not depends upon what particular problem you are solving. If the problem you are solving needs to access multiple specific characteristics like name and population, it is worthy of being abstracted as an object. Similarly, if one must attribute behaviors to it through anthropomorphization or it has special relationships, such as adjacent states, that are important to the problem in hand, it qualifies as a first class object.

Suppose your software is a tax preparation application. Each state stipulates things like tax rates and you need to distinguish differences in those values for each state. In addition, you might find it useful for a State entity to compute the tax based upon its own characteristics. In that problem context each State is a unique, identifiable entity that is worthy of being abstracted individually as an object. Since all such objects have the same characteristics that you need for the problem, you define the set of such objects with a class.

Now suppose your software application prints address labels from a list of customers. The only place where the notion of 'state' is needed is to print the state mnemonic on the label. Now the relevant object may be something like Customer that has attributes like {name, addressLine1, addressLine2, city, state, zipCode}. Thus the notion of 'state' is abstracted only as a characteristic of some other object. Thus the relevant objects to abstract are customers and the class that defines that set of objects is Customer. Now State is simply an attribute of that class that each Customer must have.

Similarly, I think that any type of lookup (in DB ERD terms) should be
modeled as a Class in the class diagram.

An ERD is not a Class Model despite the similarities. ERDs only model data while Class Models also model behavior responsibilities. There are also fundamental differences around things like generalizations. So they tend to be constructed differently in detail even when they both abstract from the same problem space.

One way that is manifested is that, though lookup tables are common in OO applications, they are rarely explicitly identified at the OOA/D level in an Class Model. Instead they are usually only explicitly defined during OOP as part of the implementation of other objects. IOW, they appear as tactical implementations of the objects that one deals with to actually solve the customer's problem.

The fact that OOPL type systems find it convenient to express /all/ data structures as classes is really serendipity. There is <usually> a big difference in the the level of abstraction of the objects needed in OOA/D to specify the solution and the objects needed during OOP for implementation within the constraints of OOPL type systems.

The situation is similar to collection classes for relationships:

1 R1 *
[A] -------------- [B]

The R1 relationship is fully expressed in the OOA/D Class model as a 1:* relationship. At OOP time one will almost always implement the [A]-side of the relationship with a collection object that will be a member of some generic library class.

My colleague is of the opposite opinion, and thinks that there
shouldn't be classes for these "lookups." I'm not sufficiently
following her logic well enough to represent her viewpoint, but here's
a thread:

her: to me [State] would just be an element of the "conference" class.

me: an element of what type?
her: ah
her: let me think on that for a minute
her: a record type
her: a generic reference table type that has a code and description
her: so, for example, we'll have something similar for ethnicity, i'm
guessing
her: a code and description
her: i wouldn't see an ethnicity class - i would just see that as an
element of target population
her: and it's type would also be the generic record class
me: sounds weird to me, but i'm not enough of an OOAD guru to be
confident of my "weirdness" determination

Can anyone help me settle this matter specifically, and more
importantly, settle the general matter of what gets modeled as a class
and what doesn't?

Forget about types. Type systems only exist at the 3GL level. They are concerned with property access within the constraints of procedural message passing and binding. Class Models are based on class systems at the OOA/D level. Classes are about set membership. The classes of a Class Model just need to map unambiguously into OOPL types.

I think you are mostly right. However, getting into "record" types is just confusing things. It sounds like what you have is:

[Conference]
+ conferenceID
...
| 1
|
| R1
|
| located in
| 1
[State]
+ code
+ description

You are right that you need to abstract a State object with multiple properties. However, you references to databases and lookups concern me

The real key is whether you actually need both State::code and State::description to solve the customer problem in hand. If the only reason you need both those values is to do a lookup for description given a particular conference because that is the way it is done in your RDB, then I don't think you need a separate [State] class.

For example, suppose the RDB tables are:

[Conference]
+ conferenceID
+ stateCode ------------+
... |
|
[State] |
+ Code <----------------+
+ description
...

where Conference::stateCode is a referential attribute to the [State] table and the relationship between [Conference] and [State] is 1:1. Now suppose the only thing you need is the State::description for each Conference to solve the problem in hand. You could literally map the [State] table into a [State] object as my Class Model above.

But emulating the RDB that way that would be silly because the R1 relationship is 1:1. IOW, there is only one [State] object at the end of the R1 relationship and it is the right one already. Thus you don't need a lookup to get the description; you just navigate the R1 relationship that was instantiated. That's because object relationships are instantiated at the object level (e.g., a pointer in each Conference to a single State object) while ERD relationships are instantiated at the table level (e.g., a join does a table lookup on the entire [State] index for a given stateCode).

Given that you only need the description AND the 1:1 relationship, to solve the problem in hand you might eliminate the [State] class and simply abstract:

[Conference]
+ conferenceID
+ stateDescription
...

in the Class Model because you know that each Conference object will have exactly one stateDescription value because the conference can only be held in one state. Now you don't need any sort of lookup through a collection of [State] objects.

Instead, you leave the linking of ConferenceID to stateDescription to an RDB query invoked to initialize a Conference object. IOW, you use the DBMS join to do the lookup when you actually instantiate a [Conference] object. That join yields a dataset containing exactly the right data to initialize your [Conference] object in the application.

The main point here is that OO relationships are instantiated differently than RDB relationships. As a result one can often eliminate the join-like lookups one has in the RDB when tailoring an OO solution to a particular problem. That, in turn, might lead to eliminating classes like [State] and relationships like R1 in the problem context.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



.