Menu
Is it good practice to make sure that all abstract classes have names prefixed with "Abstract"?
533
If all the subclasses were in individual files in a dir, I'd put the abstract class right next to them in its own file. The reason I'd put the abstract class somewhere else is if I'm separating off utility code that can be reused with other projects. In short, an abstract class is just a piece of code.
Abstract classes are never strictly necessary. You can always use a non-abstract class and provide stubs for methods that would otherwise be abstract. You can also approximate aspects of abstract by giving a class only protected constructors. But non of this is the point.
In general, a class should be abstract when you have absolutely no reason to create an instance of that class. For example, suppose you have a Shape class that is the superclass of Triangle, Square, Circle, etc.
The short answer: An abstract class allows you to create functionality that subclasses can implement or override. An interface only allows you to define functionality, not implement it. And whereas a class can extend only one abstract class, it can take advantage of multiple interfaces.
You can but I tend not to do this since it is an implementation detail.
I don't like adding implementation detail information in the names of types and identifiers as that kind of information may change in the future. In my opinion it is best to name things what they are, not how they happen to be implemented.
172
I think this naming convention is just used because it is hard to come up with another good name. If you already have an interface called "List", how would one name the "AbstractList" class? It's more about avoiding name clashes then telling implementation details.
23
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
