Should I use an abstract base class for this purpose at this time?

Question

I just recently began to develop professionally. I studied OOP at a university, but I don’t feel like I have ever used it in a “real world” scenario.

In principle, trying to create / manipulate a certain type of document within the organization, I created a class for it, believing that at any time when we wanted to create / manipulate this specific type of document, we could simply create an instance of it and give it certain information and take care of yourself.

I know that we plan to work with other types of documents (I think I should note that when I say types of documents, I mean something like a "expense report" or "inventory list", as in relation to content .) I assumed that all these documents would have certain functions (for example, work with common strings or certain names in Excel), so I created an abstract class Document and thought that every type of document we wanted to create could extend this class.

Of course, I still work with only one type of document, so although I have an idea of ​​methods that can be common to all documents, I still have only one abstract class and one that extends this, so this looks somehow unnecessary.

I think my questions are:
1) Should I use an abstract class here. How does it feel like using one correctly or have I completely missed the point?
2) If I should use it, should I not use it before? I mean, should I wait until I actually have several documents in front of me so that I can determine what functionality is shared between them, and not like what I know at the moment, although I only have one class implementing it?

Thanks.

Answer 1

An abstract class sounds straight from your description: there are certain properties and behaviors that are common to all derived types (some of them may be the default behavior that derived classes can change). However, some of the derived classes may have additional / alternative behavior from others. If there were no default behavior and only a specification of the method, then the interface would be more appropriate.

As for this, it's too early: How confident are you that you will definitely need more than one derived class. I would not worry about creating abstract base classes until there is no doubt that this will be necessary. This is known as YAGNI (you do not need it); do not create the code until the last minute, otherwise you may not need it, and you saddled yourself with additional potential maintenance.

Answer 2

Since the purpose of an abstract class is to provide a general definition of a base class that derived classes can share. therefore, it is ideal for use here.

Answer 3

If it is abstracted: Yes.

For this you must use it before. Yes, this is just rule 1, 2, 3. If you need to write something, fine. Think twice about making it generic depending on its size. Three times definitely make this a common occurrence.

I am a big fan of making things as general as possible. I get angry when I have to write the same thing several times.

Answer 4

I would suggest that it can be useful to define both an abstract class and one or more interfaces. Usually, parameters and variables of interface types are used, with the exception of procedures associated with creating an object (use an abstract class for them). The main document and interface can support some basic functions, such as GetPageCount, RenderToScreenBitmap, RenderToPrinter, RenderToHtml, GetVersionInfo, etc. A document class that inherits from an abstract document class can use the default logic for any of those functions that do not need to be changed. However, using an interface rather than a base type would allow someone to modify a different type of document (which could inherit something completely different) for use on your system by adding the necessary interface features.

Please note that it would probably be useful to use some kind of adapter template for things like printing and rendering, but this is beyond the scope of the original question. The rendering for viewing the screen is different from the rendering for printing (when viewing on the screen there may not be a solid subdivision into "pages"), so it is probably wise to have different methods for these functions, although implementation details will require some thought.