When are Description classes useful

Question

A book called 'Applying uml and patterns by craig larm' emphasized the use of Description classes in software designing. For example, the book pointed out why putting attributes such as description, price etc in a separate class ProductDescription and associating it with Item class which only have a serialNumber attribute is better. How does it makes any difference if we list those attributes directly in Item class rather than making a separate class. The book gave some reasons which I dont get. The book gives this reason,

The Need for Specification or Description Conceptual Classes · Preceding problem illustrates the need for a concept of objects that are specifications or descriptions of other things. · To solve the Item problem, what is needed is a ProductSpecification (or ItemSpecification, ProductDescription, ...) conceptual class that records information about items.

1. A ProductSpecification does not represent an Item, it represents a description of information about items.
   

2.  Note that even if all inventoried items are sold and their corresponding Item software instances are deleted, the ProductSpecifications still remain.
   

See the second point. How is it useful? If an item in the inventory is sold or deleted, the stock count will be updated from the database. I am attaching a complete screenshot of what is written exactly or see http://csis.pace.edu/~marchese/CS616/Lec5/se_l5a.htm ( search by Specification or Description Conceptual ).

Thank you.

Answer 1

"If an item in the inventory is sold or deleted, the stock count will be updated from the database" -

It's not about that. This is not a generalized OOP recommendation, this is about the kinds of relationships that arise in certain domains.

If an item is sold out, you still can go to the database and query the price or details of that product. The table that stores product details, as well as the stock count is a description of a product. But sometimes it's not enough to just store the count, sometimes you need extra data, perhaps better represented by a separate table or an object. Again, this whole discusion is not really related to OOP itself, it's about domain modeling.

E.g., suppose you're selling stuff online. You may want to keep generalized product descriptions & specs (something that people might search for) separate from data about the concrete items you have on stock (e.g., these might store info on whether the item is new or second-hand, if it's damaged, a note about the item itself, etc.)

Answer 2

You have to appreciate that they are keeping track of inventory using individual object instances (1 object : 1 inventoried item) — rather than collecting inventory into a single class-representing entity with tally count.

This is odd, to say the least, but perhaps useful if each inventoried item has its own unique serial number that the system wants to record & track.  Using this approach, shared stuff like description should be moved to a common object rather than being repeated in the individual instances.

Answer 3

I have to disagree with the existing answers as there are cases where the separation between concrete objects and descriptive objects makes a lot of sense.

For example, the contract management software that I'm co-maintaining has money flow objects representing account postings, which naturally need to be present per contract because the amounts and dates are specific to each contract. But the accounting rules for each kind of flow are parameterized in description objects which are referenced from the concrete flows, so they don't need to be stored redundantly with the flows.

You're likely aware of database normalization, which serves a similar purpose.

Answer 4

Ehh, this is weird advice. Shifting the description off to another class/table because it doesn’t represent the object is taking cardinality to impractical extremes.

That said, there are three reasons I can think of where you might want to do this:

1. In something like a database, you won’t want to duplicate the description text across all of the items. This is probably what the book is aiming for, but described it awkwardly. In a class you can make the string static or flyweight it to reduce usage.
2. Depending on your implementation, the description might make the item serialize poorly and/or screw around with your cache access.
3. Descriptions might need to be localized, meaning you’ll want to separate the localization bits separate from the locale invariant parts of the item.