List vs. Category: Part 1: Introduction to the problems

Published on
9,554 Points
4 Endorsements
Last Modified:
This article explores the difference between two entities: List and Category.   In part one,  we'll look at the basic concepts, and set some groundwork.  In part two, we'll get to some conclusions.

I know that these two things are different, but I need to find out a method using which I make my software program identify the distinction.  I am trying to be methodical.  After a search/research and brainstorming for some hours, I am able to come up with this much:

A List is a collection of items.
Properties of a list:
name of the list
list of items
list of sublists
A Category is a class or division in a scheme of classification.
Properties of a category:
list of items
list of subcategories
While I am aware that List and Category are two different things or entities, I am not able to find one attribute in any of these entities which is not in the other one.  So, I am unable to see the difference either due to:

My inability to describe the entity in terms of its attributes, or...
It is impossible to describe an entity in terms of only its attributes and something else is required, or...
The difference in entities is not because of the difference in attributes.
I have made two assumptions so far:
It is possible to compare entities.
One of the way to do so is to compare the properties and behavior first.
There are some questions to be asked which challenges the assumptions first.

How do we compare two entities?
Should we compare the attributes of those entities to describe the difference between them?
If the attributes of the two entities are same, could they still be differentiated based on the values of those attributes and be grouped into a common class?
Or Does it mean that two entities with identical attributes are same?

Given two entities, I will first explore the possibility of comparing the entities by comparing their attributes and behavior.  Comparing the attributes could mean comparing the number of attributes as well as type of those attributes.  If there is one property/attribute which is in one entity and not in the other, that would mean these two entities are different.  If the properties themselves of the entities are different, that would also mean that entities are different.

So, if the attributes are identical, then does it mean that the entities are same? Let's say that I have two instances, which have the same properties/attributes, just the values of those attributes are different.  Would that imply that these instance belong to the same entity? Could the behavior of those entities also makes a difference whether they belong to the same entity or different?  Let's look at a few examples:

1) Blue vs. Green
Now what could be the properties of an instance 'Blue'? Name and RGB Value is all I could think of. It would be the same for 'Green' as well.

It's not hard to make out that both these instance belongs to class 'Color', though the behavior of both colors are different. Blue color and Green color signifies separate things also, and have different usage. So, would this mean that two instances could belong to same class even if their behavior is not same? One answer would be that there could be two subclasses of 'Color' class, one of which will have 'Blue' as its instance and the other ones will have 'Green' as its instance. Both of these subclasses could add to the default behavior of a color.

So, Blue and Green, while both of them being the part of Color class, can have different behavior. One thing to note here is that, we have created the hierarchy as per the context, keeping in mind the difference in behavior. For example, since Green color can be used in a traffic signal, and Blue color cannot be, so subclassing could be done in way that there would be two subclasses of Color, TrafficSignalColor (whose instance would be Green), and other would be NonTrafficSignalColor (whose instance would be Blue). But if the difference is something else, then subclassing would be done differently. We can identify all such usages and argue that we can make subclassing non-contextual, but the success of this exercise would be entirely dependent on how capable we are in finding out all the behavioral aspects and usages of the instances.

Also, another point to be noted is, I am assuming the class's instances to exhibit properties, behavior, and usages rather than the usual notion of just properties and behavior.

2) A 'Harry Potter' Novel vs. A 'Rotomac' ball-point pen
Now this looks pretty straight-forward in terms of difference between them as entities. Attributes of that Book would be book name, author name, publication source, price, genre, type,  release date, and released media. Attributes of that pen would be pen brand name, pen size, ink color, price, type, release date, and released media. Both these instance belong to a different entity each. It will be interesting though to find out the classes to which these instances belong.
a) An instance of that book could belong to multiple classes (if we allow the addition/removal of few attributes) such as Book, or Novel (if we remove the attribute 'type'). If we keep just the author name, publication source, type, price, genre, release date, and release media, then the instance could be belong to class called 'Publication.'  

If we keep on adding or removing the attributes, this instance could belong to any number of classes (apart from) like SaleableItems (if we keep price, type, release date, release media), or RentalItems, or SoldItems (if we add sold date, buyer name), FavoriteList (if we add buyer name, etc.) and many more such classes. So, there are a few things to notice here:
>> Which class would an instance belong to, would be determine by what all attributes, one could think of for an instance. In other worlds, the answer to 'where this instance fits in?' is limited-by/subjected-to your knowledge-of/ability-to-describe that instance.

>> An instance could belong to a set of classes which can be mutually exclusive to each other. For example, in the above example RentalItems, RentedItems, and SoldItems.
b) An instance of that pen could also belong to multiple classes, such as: Pen, ball-point pen, etc. It could also belong to a class of WritingDevice, WritingTool, etc. if we look from the point of view of its usage.  It could also belong to a class of StationaryItem, GeometryBoxItems, SchoolBagItems, etc. if we look from the point of view of where it fits in. As above, this instance could belong to many number of classes (apart from) like SaleableItems (if we keep price, type, release date, release media), or RentalItems, or SoldItems (if we add sold date, buyer name), FavoriteList (if we add buyer name, etc) and many more such classes. So, another few set of things to note here is:
>> By looking from different points of view, we can figure out many sets of classes an instance can belong to.  So, which class an instance belongs to is limited by our imagination and also the current context in which you are looking at the instance.
c) Both the Pen and Book as described above in terms of attributes have some common attributes like type, price, genre, release date, and release media. So, another few set of things to note here is:
>> If we ignore rest of the attributes, then we can make both of these instances belong to the same class. This is a familiar conclusion since it is the case generally that common attributes can be re-factored to the super class, and then rest of the attributes will go to the subclasses.

>> As we can see (in both a) and b) and also above mentioned point), that both the instance belongs to SaleableItems, RentalItems, SoldItems, FavoriteList etc.

Now this is where the real trouble begins for me. As per Object Oriented Programming (OOP) principles, an object must exhibit Inheritance hierarchy.  In other words, if an object (instance in our case) belongs to multiple classes, these classes should be in an hierarchical order.  But these classes SaleableItems, RentalItems, SoldItems, and FavoriteList class are not in a hierarchical order, instead they are either mutually exclusive to each other, or they do not fall in the same hierarchy. This could mean two things:

i) Either, I have made a mistake in reaching to a conslusion in c) above. (which I have tried my best to avoid),...

ii) Or, the OOP principal of inheritance is erroneous, (which is a big conclusion to make since OOP has been around for long time, widely used, appreciated, and I haven't read about this problem before, probably no one has).

As much as I want to think, revise and adjust the first point 'i)' above, it appears to me 'ii)' is true. It is easy to verify that using any language that claims to support OOPs fully, like Java. Say that there is class called Pen and Book. As already explained both of them can either belong to SaleableItems, RentalItems, SoldItems, FavoriteList etc class. Now, since all of them are not in a hierarchical order, you won't be able to up-cast a Pen or a Book object to all of them (unless, of course you can figure out a way to force a hierarchy here, which will incorrect semantically).

Some more questions that can be asked after the conclusion made above are:

How do we represent this in terms of OOPs, is there a work-around?
How do we represent this in terms of RDBMS and HDBMS at least, since they may not have all the restrictions of OOP?
Going back to the original problem of 'List vs. Category', we have probably found no answers to the questions asked earlier.  Having few attributes extra does really tells me the difference. It actually confirms that (as in case of List vs Category) that either: List is a super class of Category or vice versa.  In other words, it means either a list is a special kind of category or category is a special kind of list.

I feel this is not a satisfactory conclusion, since semantics of both List and Category are entirely different.  Even if attributes are same and the behaviour is varying, then also objects could belong to the same class (check the Blue vs. Green example above).  Even if I consider Usage of an entity apart from properties and behaviour, then also no real progress is made.

More question than answers have emerged from this article and I am more confused than ever.  While I am trying to research and explore about classes, objects, entity and attributes, it is becoming increasing obvious to me that there is more to OOP than I know (or what I am told).  I guess more limitations will surface as I am beginning to explore OOP and entity/attribute relationships.
Ask questions about what you read
If you have a question about something within an article, you can receive help directly from the article author. Experts Exchange article authors are available to answer questions and further the discussion.
Get 7 days free