MyClassBase is the way to go.
This is subjective but calling it MyClassBase brings readabilty and symmetry in design.
MyClassBase is the way to go.
This is subjective but calling it MyClassBase brings readabilty and symmetry in design.
Subjective... But ok. This is my perception of things: BaseMyClass
sounds like an imperative: "Base my class! Now!" :)
Whereas MyClassBase
is clearer... a class that is a Base
I wouldn't use the words "Base", "My" or "Class" at all but chose a name for the interface that actually describes what it is.
Imagine if you have a chain of abstract classes, would you call it MyClassBaseBaseBase then?
Avoid the use of "Base" in your name if you can. You have an abstract base class because it's somehow more generic than your concrete implementation. Name it in a more generic way then, describing what common ground it supplies for deriving classes.
If the above cant be done for some reason, I agree with the previous poster; use MyClassBase.
A choice between between MyClassBase
and BaseMyClass
is like asking whether I'd prefer a kick in the nuts or a punch in the face.
I don't wish to offend, but both those names are awful. Specifically, there is no reason to include Class
in the class name (unless you're modelling an eduction system). If you really need to use the class name to indicate it can't be instantiated, I would prefer to use the term Abstract
, rather than Base
.
As a general rule, look at how the standard libraries are named and follow that convention. If your standard libraries have names like MyClassBase
and BaseMyClass
, then naming is the least of your problems.
Not sure if this is correct but when I name my base class I want that just by looking at the class name one should understand that this is meant to be inherited. like I have two versions of webpart(GoogleSearch) one for mobile and other for normal brower then I would create an abstract base named GoogleSearchWebpartBase and name the webparts as MobileGoogleSearch and GoogleSearch.