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. enter image description here


4 Answers 4


"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.)


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.

  • So this is mostly impractical, right?
    – Maak
    Oct 21, 2020 at 20:45
  • 1
    Not for their situation, but yeah, its not for everyone.
    – Erik Eidt
    Oct 21, 2020 at 21:32
  • 3
    @MuhammadAhmed - go to Amazon and do a search for the physical copy of the book you got this from; under the 'Add to Cart' box, there's a "More Buying Choices" section, that says "2 new from $71.80 27 used from $26.87 2 Rentals from $24.74, etc." that you can click on and see the details of each item. What you searched for got you to a page that presents you with a description of a product, but now before you buy you can go and inspect data on each item (an instance of that product) that they have on offer - it's two separate data structures. Oct 21, 2020 at 23:20

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.


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.
  • The book further gave another scenerio of a airline company which suffers a crash." Flights are cancelled and flight software objects are deleted from memory. If the only record of what airport a flight goes to is in the Flight software instances, which represent specific flights for a particular date and time, then there is no longer a record of what flight routes the airline has." Why are the software objects concerned about storing data because there will be a database storing every information?
    – Maak
    Oct 21, 2020 at 20:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.