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.
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.