我此时是否应该为此目的使用抽象基类？

Question

I only very recently began developing professionally. I studied OOP while at University, but don't feel as if I ever really used it in a "real world" scenario.

Basically, in trying to create/manipulate a specific type of document within the organization, I created a class for it, with the thinking that anytime we wanted to create/manipulate that specific type of document, we could just create an instance of it and give it certain information and have it take care of itself.

I know we're planning on working with other types of documents (I guess I should note, when I say types of documents , I mean something like "expense report" or "inventory list", as in I'm referring to the content.) I assumed all of these kinds of documents would share certain kinds of functionality (for example, working with shared strings or defined names in Excel), so I then created an abstract Document class, and thought each type of document we wanted to create could extend this class.

Of course, I'm still only working with one type of document, so while I sort of have an idea of methods that might be common to all documents, I still at this point only have one abstract class and one that extends it, so it seems sort of unneccesary.

I guess my questions are:
1) Should I even be using an abstract class here. Like does this seem like the appropriate use of one or have I completely missed the point?
2) If I should be using one, should I not be using it this early? I mean, should I wait until I actually have several documents in front of me so I can actually determine what kind of functionality is shared between all of them rather than sort of assume I know for now even though I only have one class implementing it?

Thanks.

Answer 1

Abstract class sounds about right from your description: there are certain properties and behaviours that are common to all the derived types (some of these may be 'default' behaviours that derived classes may change). However, some of the derived classes may have additional/alternative behaviour from the others. If there were no 'default' behaviours and only a method specification, then an interface would have been more appropriate.

As to whether it's too early: How certain are you that you will definitely need more than one derived class. I wouldn't bother with setting up abstract base classes until there was no possible doubt that it would be needed. This is known as YAGNI (You Aren't Going To Need It); don't create code until the last possible minute, otherwise you might never need it and you've saddled yourself with extra potential maintenance.

Answer 2

As the purpose of an abstract class is to provide a common definition of a base class that derived classes can share. so it is perfect to use here.

Answer 3

Should this be abstracted: Yes.

For should you use it this early. Yes, it's a simple 1, 2, 3 rule. If you have to write something once, ok. Twice, think about making it common depending on its size. Three times definitely make it common.

I am a big fan of making things as generic as possible. I get mad when I have to write the same thing more than once.

Answer 4

I would suggest that it may be helpful to define both an abstract class and one or more interfaces. Generally use parameters and variables of the interface types except in routines which deal with object creation (use the abstract class for those). The basic document and interface might support some basic functions like GetPageCount, RenderToScreenBitmap, RenderToPrinter, RenderToHtml, GetVersionInfo, etc. A document class which inherits from the abstract document class could use default logic for any of those functions it didn't need to change. Using interface rather than the base type, however, would make it possible for someone to retrofit another document type (which might inherit something completely different) to be usable on your system by adding the necessary interface functions.

Note that it would probably be good to use some sort of adapter pattern for things like printing and rendering, but that's going beyond the scope of the original question. Rendering for screen viewing is different from rendering for printing (there may not be a firm subdivision into "pages" when viewing on-screen), so it's probably sensible to have different methods for those functions, though the details of implementation will require some careful thought.