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

mySpamB8@xxxxxxxxx wrote:
"Daniel T." <danie...@xxxxxxxxxxxxx> wrote:
mySpa...@xxxxxxxxx wrote:

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.

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

My colleague is of the opposite opinion, and thinks that there
shouldn't be classes for these "lookups."

In order to know, ask yourself, what responsibilities do objects
of the class have? If you can come up with an some, then it should
be a class, otherwise it is nothing but data associated with some
other class.

Is it lame to call simple accessors "responsibilities?" For state,
it would be getName() and getAbbreviation(). The same sort of thing
would go for the other "lookups."

Yes. "Here memorize this" isn't what I'm talking about.

If this doesn't qualify, say, State, as a class, then what does this
property (or set of them?) look like (as far as data type, etc.) in
the Class Model of the containing class (say, "Contact")?

What invariant is the class responsible for maintaining? I.E., what
relationship between the member-variables of the class does the it
ensure. If the only relationship you can think of is "all members
represent different aspects of the same thing" then you are working with
a representational class and not an OO class.

Depending on the language, we may represent something that doesn't
fit the definition of class by OO standards as a class in the
language, simply because it is useful to do so. Such data bundles
are used by OO classes to get work done.

Are you just saying that sometimes, you pass data around in a class
as a transfer mechanism, not because the class fits a tidy object,
but because it's convenient? If so, I'm not sure what to make of
this in the context of my question. I think I'm missing your point
here.

Yes, I'm saying exactly that. My point is that you are both right. It is
appropriate to use a class for "State" (thus you are right,) but the
class isn't a class by OO standards (thus your colleague is right as
well.)

It is important not to confuse representational models with OO
models.

Sorry, I don't understand this one either, and it's not Googling
well. What's a representational model?

From the book, "Designing Object-Oriented C++ Applications using the
Booch Method", by Robert C. Martin

The representational paradigm employs data structures to represent
the structure and relationships of elements within the application
domain...

Representations are, by their nature, reusable, but for the
opposite reason that objects are reusable. Objects present an
/abstract behavioral/ interface that hides the underlying
representation. This allows us to reuse high-level policy
functions with many different sets of details. On the other hand,
representations present /concrete static/ interfaces that are
devoid of significant behavior. Thus, we can reuse them in many
different behavioral contexts.

...

... the analysis and design of representational models is not
object-oriented analysis and design. Representational modeling
deals with data structures and the relationships between them.
Object-oriented models deal with abstract behaviors and their
partitioning into classes and categories.
.