Feedback on inheritance assignment

Question

So I've got this java assignment for college and was just wondering if anyone here could give me some feedback as to what I've been thinking some of this means.

I've got a .csv file with building details - Here is a sample of the data I'll be working with.

Now part of the assignment states -

Entries in the building list can be categorised in at least three ways: by category A, B or C. Each category is associated with the same data as above, but you will be required to handle them differently in your directory. You should formulate a suitable object model for this data, making use of appropriate (abstract) superclasses, and subclasses. (This is an exercise in inheritance, so although the directory is rather simple, you should create an object model with inheritance.)

So I was thinking of going with a Building superclass and then having a Listed Building subclass. I would then have three more subclasses Category A/B/C Buildings inheriting from Listed Building. But I was then thinking of just having Listed Building be the superclass since there will only be one type of building in this assignment. As for the Category classes, they will not contain any new attributes over what Listed already has by the look of it, but one of the tasks states -

Display suitable information for each entry returned, depending on category. Although the information stored for each category is the same, you should present it as follows: items of category A should appear in ALL CAPITALS with all data fields; items of category B should be in lower case with all data fields; items of category C should be in lower case and omit the council and parish. The object model you have created should take care of these differences.

Now when it says the object model should take care of this, would you say it means there should definitely be a Category A/B/C class and that each class should have getters for the data fields that will manipulate the data the way that is described in the task. e.g output in lower case? And for the omitting some fields for Category C, would I just not include a getter for those in the Category C class since they won't be used?

EDIT Class diagram of what I have just now getEntry() is abstract and will be used by the subclasses to put together an appropriate string determined by the task requirements for each different category.

Answer 1

Wrong direction?

By using a Building superclass and a ListedBuilding subclass you try to meet the following requirement:

You should formulate a suitable object model for this data, making use of appropriate (abstract) superclasses, and subclasses.

However in reality you only introduce an additional artificial class ListedBuilding, because nothing in the assignment narrative (at least the part that you've disclosed here) let us imagine buildings that would not be listed.

Alternative reading

Here's what can be understood:

• From the csv sample and the narrative, we know that all the Building objects have the same attributes, whatever their category. This seem a good candidate for the superclass.
• From the narrative we know that the Building objects will have to be handled differently according to the category. This suggests that BuildingXxx could be a potential candidate of subclass for an object of category Xxx.
• We also know that each Building object has to be represented differently, depending on its category. This suggests that it makes no sense to implement the representation for the superclass, but that each subclass needs to have its own. The representation method is therefore a good candidate for being abstract.
• An abstract class is not an interface: it doesn't require that each subclass implements each method of the superclass ! You can very well have some common getters and setters implemented for the superclass, and have an abstract representation method that is declared in the superclass, but implemented only for the subclasses.

Additional thoughts

Naming the classes is very important. If you see in someone else's code a CategoryXxx class, would you think it's a building of category Xxx ? Or could it be a class describing the category itself independently of any specific building ? So better avoid any risk of misunderstanding and use unambiguous class names.

It's an assignment on inheritance. In the real life, you would however be encouraged to prefer composition over inheritance. For example, with the inheritance model, a Building cannot change Category. This article gives some more insights on how to choose between composition and inheritance.

You seem worried about DRY, which is a good thing. As you see, you can very well avoid repetition of getters and setters because with abstraction, YOU decide what's common and what may differ. You'll certainly appreciate that you can even mix both together, by having a behavior with a common part but making use of abstract behaviors. This is called the template method design pattern.