This content has been marked as final. Show 6 replies
no, a subclass implements all the methods of its superclass
it seems like your BookObject is poorly designed. If you have a BookObject, how do you know if that specific object will be using a List or a Map? how do you know what methods you are allowed to call on it?
why not have two classes, ListBookObject and MapBookObject or something like that, and each just has the methods that apply to it?
Thank you both for your responses--
That's a good idea to split the classes based on the data structure, Spoon, I'm definitely going to do that. And thanks jverd for the suggestion on the naming, but the class isn't actually a book, it's one of many types of object that a book can contain.
In any case, thanks to you both; I'll be doing some refactoring today.
jezzica85 wrote:So, a BookObject is a book that may contain a List or a Map? Am I understanding correctly? If so, then I don't think this is a good hierarchy. I wouldn't expect to be able to perform the same kinds of operations on a List container as on a Map container, and I'm a little confused what this BookObect is really supposed to represent.
thanks jverd for the suggestion on the naming, but the class isn't actually a book, it's one of many types of object that a book can contain.
If you do keep the hierarchy, I'd still suggest a more descriptive name than BookObject. Perhaps ContainingBook or WrapperBook or something, though, without really understanding what it's for, I can't say for sure.
jezzica85 wrote:Regardless, "BookObject" doesn't really tell you anything, except that it has something to do with books, and the name "Book" would tell you just as much.
No, BookObject is just sort of a general wrapper class. It has subclasses like BookCharacter, BookSetting, and BookAction, for different parts of the book.
I get the impression that you might be making a single hierarchy where you don't really need it. You don't have to make every class in your project extend a particular single class in your project.
Having subclasses called BookCharacter, BookSetting, and BookAction, doesn't necessarily make BookObject a wrapper class. What you said is a non sequiter. What exactly does BookObject wrap?
Also I'd argue that if everything here is about books or a book, then having the word "Book" in every name doesn't help you either. Instead, having a package called "book" might be more useful, with the class names being more specific.
From the names you've chosen, I'm going to guess that a more reasonable design and naming might have an interface called Analysis, with implementing classes named, say, BookAnalysis, CharacterAnalysis, SettingAnalysis, and ActionAnalysis. BookAnalysis would contain collections of the other analyses, and the word "Book" in the title would suggest that it's an analysis of the whole book, as opposed to elements of the book, and in fact would be one of the few objects with "Book" in its name. It wouldn't be a superclass of the other Analysis implementations -- there's no need for that.