6 Replies Latest reply: Dec 23, 2007 3:35 PM by 807603 RSS

    Abstract classes question

    807603
      Hi everybody,
      I have a base class called BookObject that is abstract; it has a constructor and accessors/mutators for its data members, then some abstract methods. The classes that extend it can have, as a data structure, either a list or a map, depending on what's needed. I'd like to, based on the data structure, be able to inherit certain abstract methods, but not others -- that is, the map abstract methods I wrote for when the data structure is a map, or the list methods for when the data structure is a list. If I inherit everything, it results in multiple methods with empty bodies that I don't need. Does anyone know if there is such a thing as inheriting only specified abstract methods, based on a criterion in the class? If anyone could give me any information on this, I'd appreciate it.

      Thanks,
      Jezzica85
        • 1. Re: Abstract classes question
          807603
          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?
          • 2. Re: Abstract classes question
            796440
            spoon_ wrote:
            no, a subclass implements all the methods of its superclass

            it seems like your BookObject is poorly designed.
            And poorly named. "Book" would be just fine.
            • 3. Re: Abstract classes question
              807603
              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
              • 4. Re: Abstract classes question
                796440
                jezzica85 wrote:
                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.
                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.

                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.
                • 5. Re: Abstract classes question
                  807603
                  No, BookObject is just sort of a general wrapper class. It has subclasses like BookCharacter, BookSetting, and BookAction, for different parts of the book.

                  Hope that helps.
                  Jezzica85
                  • 6. Re: Abstract classes question
                    807603
                    jezzica85 wrote:
                    No, BookObject is just sort of a general wrapper class. It has subclasses like BookCharacter, BookSetting, and BookAction, for different parts of the book.
                    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.

                    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.