You are not logged in.
I am in the process of learning advanced object oriented design, and I am trying to use it in my personal programming project. I'm having a hard time implementing all of the classes I want for it because I can't think of what to call them.
So, my question is, in object oriented design, how do you name the implementations and abstractions that you make?
In other words, "implementations" can be thought of as "classes", and "abstractions" as "interfaces" in Java or "pure abstract classes" in C++. How do you name the classes and interfaces you make?
For example, do you use prefixes or suffixes on your names, such as "I" for "interface" or "Impl" for "implementation"? Do you add "-able" to the end of the name of an abstraction, such as "Decoratable"? Can you always think of simple logical names for all of your classes, and it just has never been a problem for you?
As an example of how the number of classes quickly grows, the Decorator Pattern will use at least five classes. I have no idea what I would name those in a programming project.
Offline
I name a class what they represent. i.e Decorator. No need for suffixes or extensions. Just get straight to the point.
Offline
I name a class what they represent. i.e Decorator. No need for suffixes or extensions. Just get straight to the point.
That seems simple enough. How would you handle the situation where you have more than one type of "decorator" in a single project? Would you use "Decorator" as a suffix?
Offline
For me it depends a lot on the project. Since I have a tendency to do most of my work on projects either where standards have already been established I tend to mostly have a standard to follow.
In general I think that the exact semantics around what you actually name something is far less important than that the name is descriptive so that it is as clear as possible what it does. Also, generally I find that as simple names as possible while keeping them descriptive is generally preferable.
I haven't lost my mind; I have a tape back-up somewhere.
Twitter
Offline
I name my classes alphabetically. Alan, Brian, Cindy, Dean, Ellen, Ford...
Seriously? Whatever it is. If it decorates, it's a Decorator. If it makes things, it's a Factory. If it's a character, call it a Character. If it's a button, call it a Button. If a class or interface doesn't have an obvious name, that's an indicator that what it does probably isn't clearly defined; maybe the design should be reconsidered.
Offline
I always use the business logic name. Currently working on an Inventory management project. So if its inventory, its called Inventory. The site where the inventory is Site. etc etc.
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
If it's a character, call it a Character. If it's a button, call it a Button. If a class or interface doesn't have an obvious name, that's an indicator that what it does probably isn't clearly defined.
In the example of the Decorator Pattern, "Window" would be implemented as an interface. What would you name the implementation of the window? In the Wikipedia example, it's implemented as "SimpleWindow". In a video game, would you make it the "GameWindow", "WindowImpl", or something else?
In my "old style" of OOP, I would just make a "Window" class and be done with it. Now, I'm learning to "program to an interface". Well, in my design, I would make "Window" the name of the interface. Now I don't know what to name the implementation.
Please let me know if I'm using lousy examples.
I used to just name my classes (the implementation) simply what they were. Now that I'm trying to "program to an interface", I give the interfaces the simple obvious names, and now I don't know what to name the implementations.
Offline
Interface: Window
Implementation: WindowImpl
Last edited by Inxsible (2010-07-14 15:50:38)
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
Interface: Window
Implementation: WindowImpl
And you would pretty much only use "WindowImpl" during instantiation, right? After that, you would only refer to it through the "Window" interface.
Offline
Allan wrote:I name a class what they represent. i.e Decorator. No need for suffixes or extensions. Just get straight to the point.
That seems simple enough. How would you handle the situation where you have more than one type of "decorator" in a single project? Would you use "Decorator" as a suffix?
That's what I would do. WindowDecorator, SoldierDecorator, etc.
As for interface/implementation naming conventions, I generally go:
IDecorator = Interface
Decorator = Implementation.
It's simple, compact, and you don't have to have special naming cases for when you aren't deriving a class from an interface.
Offline
In the example of the Decorator Pattern, "Window" would be implemented as an interface. What would you name the implementation of the window? In the Wikipedia example, it's implemented as "SimpleWindow". In a video game, would you make it the "GameWindow", "WindowImpl", or something else?
Theoretically speaking, you'll have multiple implementations of the Window interface, which will have their own unique names suggested by their respective purposes. If not, then Window and its implementation should probably be merged into a single class.
Offline
Theoretically speaking, you'll have multiple implementations of the Window interface, which will have their own unique names suggested by their respective purposes. If not, then Window and its implementation should probably be merged into a single class.
Thank you for bringing that up.
How about this: The name of the implementation class will be HOW its implemented followed by the name of the interface.
A "Window" interface would have implementations such as "AllegroWindow", "GTKWindow", or "HaikuWindow".
In a video game, a "Character" interface would have implementations such as "GeneralCharacter", "ControllableCharacter", "PlayableCharacter", or "EnemyCharacter".
Does that sound like a good idea?
Offline
drcouzelis wrote:In the example of the Decorator Pattern, "Window" would be implemented as an interface. What would you name the implementation of the window? In the Wikipedia example, it's implemented as "SimpleWindow". In a video game, would you make it the "GameWindow", "WindowImpl", or something else?
Theoretically speaking, you'll have multiple implementations of the Window interface, which will have their own unique names suggested by their respective purposes. If not, then Window and its implementation should probably be merged into a single class.
+1
That's what I was thinking. Why separate them if nothing else is going to be implementing the Window interface. And if there are different classes implementing the Window interface, you'd be able to describe what it does.
Offline
Trent wrote:Theoretically speaking, you'll have multiple implementations of the Window interface, which will have their own unique names suggested by their respective purposes. If not, then Window and its implementation should probably be merged into a single class.
Thank you for bringing that up.
How about this: The name of the implementation class will be HOW its implemented followed by the name of the interface.
A "Window" interface would have implementations such as "AllegroWindow", "GTKWindow", or "HaikuWindow".
In a video game, a "Character" interface would have implementations such as "GeneralCharacter", "ControllableCharacter", "PlayableCharacter", or "EnemyCharacter".
Does that sound like a good idea?
Indeed, classes are more specific than interfaces, subclasses are more specific as their superclasses... This should be reflected in their names, the name of a class that implements an interface should somehow make clear exactly what it is (e.g. what kind window). If you have a kind of window (for instance) that is really _just_ a window, nothing else, than the interface should become this class and the implementing classes should become subclasses.
Offline
A "Window" interface would have implementations such as "AllegroWindow", "GTKWindow", or "HaikuWindow".
In a video game, a "Character" interface would have implementations such as "GeneralCharacter", "ControllableCharacter", "PlayableCharacter", or "EnemyCharacter".
Does that sound like a good idea?
Yes, indeed. What you did with Character is actually a very poignant example of what I was trying to get at, but couldn't find a good model for.
Offline
It all depends. I personally define classes the same way that everyone here, unless I mean to be funny or the project is so boring that I name the class Asdf or ChunkyBacon.
I'm also known as zmv on IRC.
Offline