I am implementing a template method type of pattern and have several classes to implement the behaviour.
As an example, my structure is as follows:
TemplateAbstract
Type
CustomType1
CustomType2
CustomType3
Default
The 'Default' class holds the behaviour should none of the custom types be needed. My question is, is 'Default' a bad name for the class?
I guess, since I am asking this question, I already have some serious doubts over the name, but what else would you call a class that provides the default behaviour amongst types?
For sake of example, do you mean something like this?
Number
Integer
PositiveInteger
NegativeInteger
OddInteger
EvenInteger
As Tom B pointed out in his comment, how you approach this depends on composition or inheritance; but I assume given this structure you laid out you mean to use inheritance. In my example having a "DefaultInteger" type seems rather awkward to use, but in your particular problem it may not be. And if Integer is just an interface a StandardInteger could make sense. Think about how a developer will use this type, and whether a "Default" makes sense as its own, separate thing:
Bread
YeastLeavened
Wheat
TwelveGrain
Default
Now I'm not sure what a Default yeast-leavened bread would be, but if it's a useful construct to your Baking program, then there's nothing inherently 'wrong' about it. Although I personally prefer to not have Default as its own type and instead just have a method on YeastLeavened.getDefault() to return the correct one.
Edit: So to answer your question directly, in general yes I would say "Default" is bad name unless you're always using it via a scope (Integer::Default), and in general is a hard class to have on its own conceptually (it's either abstract base functionality, or some concrete, "real" class functioning as what is used by default in the system)
Just expand upon the name, call it:
DefaultTypeBehaviour
That is very unlikely to cause a conflict, and tells you a little bit more about what the class does.
Ideally, the class name should describe the purpose.
"Default" is a vague term and doesn't have any significance with the functionality the class provides.
You can name your Default class something which tells that "this class has all the basic features implemented"
e.g. You can put the name something like "BaseType" or "BasicType" or "SimpleType" or anything else suits your need.
Related
Do you know programming languages where changing the class of an object at runtime is allowed (supported)?
Please give a short example regarding the syntax. Give a use case, if you know any. Examples involving duck typing are welcome as well, so do not shy away from mentioning these languages.
Update: I figured out that Smalltalk has changeClassTo and become. CLOS can do change-class. I found a paper suggesting to use these mechanisms to implement 'husk objects' that are referenced at runtime, but only constructed from some persistence when actually accessed, providing some nifty lazy loading of related objects.
I assume, you mean the following:
You have an object of class A. But you would like to treat it as an object of class B.
There are some constructions possible:
If B is a subclass of A you can cast the object to B (but it should be created as B else you have unexpected (and hopefully unwanted) results).
In some languages you can cast anything to anything. If you know what you are doing, this is great, else prepare for several holes in your foot.
You mention ducktyping. I have no practical experience with it. But As far as I know, duck typing is something like this: "I need an object that support methods X, Y and Z." In that case you don't care about the class. You just want it to quack, swim and walk at your command.
Give a usecase
??? I'd expect you to ask for a solution on a specific use case.
Changing type of an object? I think "No."
But if you like to change part of an objects capabilities or behaviours have a look at loosely coupling!
For example your class holds a member of type File_Saver. There's a public setter accepting any instance of File_Saver and you can inject File_Saver_XML, File_Saver_PDF, ...
It's no common way, but any processing inside a class can be done by 1-n loosely coupled handlers, which you can exchange from outside.
Melt down to your question: You need a wrapper + a setter. :-)
Coming back to the case after some time, I've come to the conclusion that you want duck typing if you feel the need of changing an objects class.
Is it acceptable to use the word 'Base' in a class name which is a the bottom of the inheritance tree?
I have always found this a bit of a cop-out, just wondering if anyone agrees with me.
For example, if I am refactoring certain elements from MyClassA and MyClassB into a common base class, I'd be tempted to create a MyBaseClass from which the two inherit.
But what happens if I ever need to refactor MyBaseClass? MyBaseBaseClass? Now that's just silly.
I know that Rocky Lhotka doesn't mind with his CSLA framework, but I'm always uneasy about 'definites' in programming.
Thoughts?
Let me clarify why I'm even worrying about this.
I have two namespaces - MySpecificNamespace and MyCommonNamespace. MyNamespace uses MyCommonNamespace, as you might expect.
Now, I like to make maximum use of Namespaces wherever possible to describe the context of the problem, and avoid adding the context to the class name. So, for example, consider that I have a class in MyNamespace which descends from one in MyCommonNamespace.
Option A
I could call this
MySpecificClass: MyClass
{
}
But then I'm adding 'Specific' (the context) to the name - which is redundant as it's already in MySpecificNamespace.
Option B
MyClass: MyCommonNamespace.MyClass
{
}
You can see how we could get confused here, right?
Option C
The one I think is fishy:
MyClass: MyBaseClass
{
}
I tend to add a Base suffix to the name of the base class only if it exists from technical perspective (to share some code), and doesn't really constitute any usable class on its own (so all of these classes are abstract). These are quite rare cases though, and should be avoided just as Helper classes.
"All your BaseClass are belong to us."
I side with a definitive no, with a single exception. If you are writing an app to manage military installations or baseball stadiums, go for it.
I side with "no" for exactly the refactoring reason you've cited.
A class should be named after what it logically represents, and nothing but the Object class is really really Base. Metaphysics ftw :)
re: Option B, there is nothing confusing about
namespace MySpecificNamespace
{
MyClass: MyCommonNamespace.MyClass
{
}
}
Classes that have the same name as their parent classes bug me to no end. In Java java.sql.Date extends java.util.Date. This is very annoying because you have to specify the exact class you want to import or else specify the classname fully (including package/namespace).
Personally I prefer to name things as they are; if a Base or Abstract class exists only to provide a partial implementation of something, and doesn't represent the interface for that thing, it is often acceptable to put the word Abstract or Base in its name. However, if that class represents the interface as well, then you should just name it after what it does.
For example, in Java, we have the Connection interface (for DB connections). It's just called Connection, not IConnection. You use it like this:
Connection con = getConnectionFromSomewhere();
If you are making a JDBC driver and need to implement connection, you could have a ConnectionBase or AbstractConnection which is the lower layer of the implementation detail of your particular Connection. You might have
abstract class AbstractConnection implements Connection
class OracleConnection extends AbstractConnection
or something like that. The clients of your code, however, never see AbstractConnection nor do they see OracleConnection, they only see Connection.
So, in general, classes that are meant to be generally useful should be named after what they represent/do, whereas classes that are helpers for code maintenance/organization can be named after what they are.
*ps I hate naming Interfaces with I. Do people name all their classes with C? It's 2009! your IDE can tell you what type of object that is, in the odd case when it even matters if it's an interface or a class.
I think it's worth wiki-fying this question.
FWIW, I agree. I usually try to find a more "generic" term for my base classes. So if I have a "Customer" class and need to introduce a new base class for it, I'd go with "Contact" or something rather than "CustomerBase".
I too would suggest No, but not cast in stone...
Following OO mantra, your naming system should best represent the underlying objects that the code is supposed to be encapsulating. There should really be no 'meta language', related to the actual syntactical makeup of the programming language of choice in there.
That said, if your object is truly abstract and you really don't see it changing anytime soon, there is an argument that adding 'Base' helps with general readability.
As with most things, there's no blanket right and wrong answer - it depends on the overall layout of your codebase, what this specific code is supposed to be representing and the in-house style that you have. Just try to be consistent.
Is base used anywhere else?
In Java I tend to provide a base implementation of an interface Foo in an abstract class FooBase. I think that is perfectly ok, and makes the connection to the interface very clear and regular.
Without the interface I would call the abstract base class Foo.
I also side with the no camp...place a Base in there today and in 6 months someone will whack a MyDerivedClass class in you code base while you're not looking.
"Abstract" prefix maybe?
I usually go with IFoo for the interface and AbstractFoo for the skeletal implementation, which is a mix of .NET and Java conventions.
I think it should probably be avoided where possible in favour of an identifier that actually describes what it is!
This question is difficult to answer because it's abstract. I might, for example, consider calling the base of MyClassA and MyClassB, "MyClass".
I agree, AbstractFoo is a decent solution. I try to pick names that don't need additional adjectives. I would shy away from using Base.
It seems like any principled answer will end up being no... However, comma, when I'm looking at code I'm not particularly familiar with, which happens a lot in python (where the source code is sometimes the only dependable documentation), I find it really helpful when a class has Base in it. Python is different from other OO languages where the class is defined with an "abstract" or "interface" specifier though. For naming, I like to ask myself "if I have never seen this code before, which way would make it easier for me to understand this code?" (Then, depending on how lazy I'm feeling, I name it accordingly).
In the last year and a bit of working on my team's code base I have noticed a steady progression of naming conventions.
For example, there are a lot of classes that are named to express that they are a class that helps you do something.
Here's the ones I've spotted:
MyClassUtil
MyClassFactory
MyClassHelper
MyClassManager
MyClassService
It just seems to me that over time people come up with naming conventions for relatively the same thing and so instead of having everything named in a consistent manner you wind up with a code base that has a bit of every convention. All the new stuff is named based on the latest fad naming convention and so you can pretty much tell the age of a bit of code by what convention was in fashion at the time.
What is the best way to deal with this tendency? Is it really a problem? As these naming fads come into vogue, should one use the latest fad? Should one rename all existing items with the new naming convention? Or should one just accept the variety as something that is inescapable?
They don't seem like fads... all these names hint at the purpose of the class, and those purposes are different. With programming, it's all in the name, and they should be chosen very carefully. The variety doesn't need to be escaped. The names vary because the purposes of the classes vary.
MyClassUtil
-Some utilities for working with MyClass that it didn't come with. Maybe MyClass belongs to a library you're using, but you often use some higher level functions with it and you need somewhere to put them.
MyClassFactory
-Creates instances of MyClass in an abstracted way. This allows you to write code that needs MyClass instances. It can get those new instances from a MyClassFactory. This would allow the Factory to modified in future to serve up different specific implementations of MyClass. Maybe under unit testing, the Factory just serves up dummy/mock MyClasses. This means a class that uses the factory can be tested without needing to change it, just change the factory, and voilà you can isolate the class being tested.
MyClassHelper
-Ok, I may agree, perhaps this can be more specific. It does something to help with MyClass, but what. Maybe this is a bit similar to MyClassUtil. But, probably MyClassUtil is general functions that work with MyClass, whereas the helper is initialized with a specific instance of MyClass and then can do operations on that one instance. You need a new helper for each MyClass you want to help.
MyClassManager
-Maybe this deals with a pool of MyClass instances and stores or orchestrates them. Eg. in a CommunicationsManager, the class would handle wiring together classes that handle talking to a port or connection like ethernet or serial, and a class that deals with the comms protocol being sent over it so it can transport packets, and a class that deals with the messages in those packets.
MyClassService
-A service can do things for you, like given a postcode convert it into a grid-reference. Usually a service can resolve to many specific things. With the postcode example, this class might be have implementations that can talk to different web sites to do the conversion.
All of the names of classes you've given above indicate to me a striking departure from object-oriented principles. There's no way of telling what "MyClassUtil" or "MyClassService" does. It could be anything. Class naming should be specific, and should relay clearly the actual function of the class. None of these do. The best way to deal with this tendency is to brush up on object oriented programming skills and name the classes accordingly.
Now, it could be that these examples point out the function, within the application architecture, that these classes represent, and your use of "MyClass" is simply a placeholder for something more definitive at runtime, in which case, I wouldn't view these as naming fads, but rather as descriptive indicators of the function of the class itself, with a loose hint of the application's underlying architecture.
If this is pervasive, the team needs to spend some time studying OO design: reading the source code to well-respected OO frameworks, books on design patterns or books such as Evans "Domain Driven Design".
"Util" and "Manager" are often symptoms of poor design - "code smells". So is "Helper" outside of special contexts (Rails apps) where it's well entrenched.
"Factory" and "Service" have precise technical meanings, you can check the code to see if it conforms to those design patterns.
The general remedy is to sit down with the team, and have an explicit discussion about what benefits you're expecting from these naming schemes, what makes sense and what doesn't, and then over the next few months apply refactoring techniques to phase out the names you've all decided are code smells.
Naming is important. It shouldn't be taken lightly, nor is it a subjective matter. True, there is often more than one correct answer to a given naming issue. However, there are seldom many answers consistent with previous choices, which is key.
Renaming the names to better ones and refactoring the code so that each class has a clear responsibility, is recommended. To know what kind of names to use, read Tim Ottinger's article about Meaningful Names.
When a class does only one thing, then giving it a descriptive name is usually easy. Words such as "manager" are vague and may indicate that the class is responsible for doing so many unrelated things, that no simple name is able to describe what the class does. If you can know what the class does just by looking at the name of the class, then the class has a good name.
I don't really see how Factory or Service fit in to a particular fad...
Factory is a design pattern and if the class really is a factory then it's a perfectly appropriate name.
If a class is a Windows service what's wrong with calling it service?
There isn't a problem unless you find that performing all the rename refactors is too costly even though you really want to do them.
Why not use a static analysis tool to help enforce a set of style and consistency rule?
If you're in the .NET world Microsoft provides a tool called StyleCop
In the classname examples you give does "MyClass" stand for an actual class name, so that you are really seeing names like "PersonnelRecordUtil" or "GraphNodeFactory"? MyClassFactory is a really bad actual name for a class.
I am often in a situation where I have a concept represented by an interface or class, and then I have a series of subclasses/subinterfaces which extend it.
For example:
A generic "DoiGraphNode"
A "DoiGraphNode" representing a resource
A "DoiGraphNode" representing a Java resource
A "DoiGraphNode" with an associated path, etc., etc.
I can think of three naming conventions, and would appreciate comments on how to choose.
Option 1: Always start with the name of the concept.
Thus: DoiGraphNode, DoiGraphNodeResource, DoiGraphNodeJavaResource, DoiGraphNodeWithPath, etc.
Pro: It is very clear what I am dealing with, it is easy to see all the options I have
Con: Not very natural? Everything looks the same?
Option 2: Put the special stuff in the beginning.
Thus: DoiGraphNode, ResourceDoiGraphNode, JavaResourceDoiGraphNode, PathBaseDoiGraphNode,
etc., etc.
Pro: It is very clear when I see it in the code
Con: Finding it could be difficult, especially if I don't remember the name, lack of visual consistency
Option 3: Put the special stuff and remove some of the redundant text
Thus: DoiGraphNode, ResourceNode, JavaResourceNode, GraphNodeWithPath
Pro: Not that much to write and read
Con: Looks like cr*p, very inconsistent, may conflict with other names
Name them for what they are.
If naming them is hard or ambiguous, it's often a sign that the Class is doing too much (Single Responsibility Principle).
To avoid naming conflicts, choose your namespaces appropriately.
Personnally, I'd use 3
Use whatever you like, it's a subjective thing. The important thing is to make clear what each class represents, and the names should be such that the inheritance relationships make sense. I don't really think it's all that important to encode the relationships in the names, though; that's what documentation is for (and if your names are appropriate for the objects, people should be able to make good guesses as to what inherits from what).
For what it's worth, I usually use option 3, and from my experience looking at other people's code option 2 is probably more prevalent than option 1.
You could find some guidance in a coding standards document, for example there is the IDesign document for C# here.
Personally, I prefer option 2. This is generally the way the .NET Framework names its objects. For instance look at attribute classes. They all end in Attribute (TestMethodAttribute). The same goes for EventHandlers: OnClickEventHandler is a recommended name for an event handler that handles the Click event.
I usually try to follow this in designing my own code and interfaces. Thus an IUnitWriter produces a StringUnitWriter and a DataTableUnitWriter. This way I always know what their base class is and it reads more naturally. Self-documenting code is the end-goal for all agile developers so it seems to work well for me!
I usually name similar to option 1, especially when the classes will be used polymophically.
My reasoning is that the most important bit of information is listed first.
(I.e. the fact that the subclass is basically what the ancestor is,
with (usually) extensions 'added').
I like this option also because when sorting lists of class names,
the related classes will be listed together.
I.e. I usually name the translation unit (file name) the same as
the class name so related class files will naturally be listed together.
Similarly this is useful with incremental search.
Although I tended to use option 2 earlier in my programming career, I avoid it now because as you say it is 'inconsistant' and do not seem very orthogonal.
I often use option 3 when the subclass provides substantial extension or specification, or if the names would be rather long.
For example, my file system name classes are derived from String
but they greatly extend the String class and have a significantly different
use/meaning:
Directory_entry_name derived from String adds extensive functionality.
File_name derived from Directory_entry_name has rather specialized functions.
Directory_name derived from Directory_entry_name also has rather specialized functions.
Also along with option 1, I usually use an unqualified name for an interface class.
For example I might have a class interence chain:
Text (an interface)
Text_abstract (abstract (base) generalization class)
Text_ASCII (concrete class specific for ASCII coding)
Text_unicode (concrete class specific for unicode coding)
I rather like that the interface and the abstract base class automatically appear first in the sorted list.
Option three more logically follows from the concept of inheritance. Since you're specializing the interface or class, the name should show that it's no longer using the base implementation (if one exists).
There are a multitude of tools to see what a class inherits from, so a concise name indicating the real function of the class will go farther than trying to pack too much type information into the name.
Let's say you have a Person object and it has a method on it, promote(), that transforms it into a Captain object. What do you call this type of method/interaction?
It also feels like an inversion of:
myCaptain = new Captain(myPerson);
Edit: Thanks to all the replies. The reason I'm coming across this pattern (in Perl, but relevant anywhere) is purely for convenience. Without knowing any implementation deals, you could say the Captain class "has a" Person (I realize this may not be the best example, but be assured it isn't a subclass).
Implementation I assumed:
// this definition only matches example A
Person.promote() {
return new Captain(this)
}
personable = new Person;
// A. this is what i'm actually coding
myCaptain = personable.promote();
// B. this is what my original post was implying
personable.promote(); // is magically now a captain?
So, literally, it's just a convenience method for the construction of a Captain. I was merely wondering if this pattern has been seen in the wild and if it had a name. And I guess yeah, it doesn't really change the class so much as it returns a different one. But it theoretically could, since I don't really care about the original.
Ken++, I like how you point out a use case. Sometimes it really would be awesome to change something in place, in say, a memory sensitive environment.
A method of an object shouldn't change its class. You should either have a member which returns a new instance:
myCaptain = myPerson->ToCaptain();
Or use a constructor, as in your example:
myCaptain = new Captain(myPerson);
I would call it a conversion, or even a cast, depending on how you use the object. If you have a value object:
Person person;
You can use the constructor method to implicitly cast:
Captain captain = person;
(This is assuming C++.)
A simpler solution might be making rank a property of person. I don't know your data structure or requirements, but if you need to something that is trying to break the basics of a language its likely that there is a better way to do it.
You might want to consider the "State Pattern", also sometimes called the "Objects for States" pattern. It is defined in the book Design Patterns, but you could easily find a lot about it on Google.
A characteristic of the pattern is that "the object will appear to change its class."
Here are some links:
Objects for States
Pattern: State
Everybody seems to be assuming a C++/Java-like object system, possibly because of the syntax used in the question, but it is quite possible to change the class of an instance at runtime in other languages.
Lisp's CLOS allows changing the class of an instance at any time, and it's a well-defined and efficient transformation. (The terminology and structure is slightly different: methods don't "belong" to classes in CLOS.)
I've never heard a name for this specific type of transformation, though. The function which does this is simply called change-class.
Richard Gabriel seems to call it the "change-class protocol", after Kiczales' AMOP, which formalized as "protocols" many of the internals of CLOS for metaprogramming.
People wonder why you'd want to do this; I see two big advantages over simply creating a new instance:
faster: changing class can be as simple as updating a pointer, and updating any slots that differ; if the classes are very similar, this can be done with no new memory allocations
simpler: if a dozen places already have a reference to the old object, creating a new instance won't change what they point to; if you need to update each one yourself, that could add a lot of complexity for what should be a simple operation (2 words, in Lisp)
That's not to say it's always the right answer, but it's nice to have the ability to do this when you want it. "Change an instance's class" and "make a new instance that's similar to that one" are very different operations, and I like being able to say exactly what I mean.
The first interesting part would be to know: why do you want/need an object changes its class at runtime?
There are various options:
You want it to respond differently to some methods for a given state of the application.
You might want it to have new functionality that the original class don't have.
Others...
Statically typed languages such as Java and C# don't allow this to happen, because the type of the object should be know at compile time.
Other programming languages such as Python and Ruby may allow this ( I don't know for sure, but I know they can add methods at runtime )
For the first option, the answer given by Charlie Flowers is correct, using the state patterns would allow a class behave differently but the object will have the same interface.
For the second option, you would need to change the object type anyway and assign it to a new reference with the extra functionality. So you will need to create another distinct object and you'll end up with two different objects.