Renaming a class

[jafrum]

Hi i was wondering if there is a quick and easy way to rename a class, and all references to this class. There are also other files associated with each class, and i would therefore need all of these files to be renamed. I know of Rational Software Architect which provides a solution to this problem, but was wondering if anyone knows of any freeware solutions.

[r.3volved]

??
Search and replace??

[Clayton]

why do you need to rename the class? The name means nothing to functionality, just readability...

[[Gandalf]]

Search and replace is the simplest way, unless it's a really massive project.

Also, Freakman, why pass this problem off because it doesn't relate to functionality? If you have a class called Square, and you slowly build it into a grid based Map, can you justify referring to it as Square instead of Map for the entire program?

[wtd]

If you understand OOP, you should have simply had Grid subclass Square.

[Clayton]

that is exactly the point I was trying to get across, even if it wasn't so clear. Also, if you had made a square class, and made it into a Grid class, that would be poor organization on the programmer's part. A new pencil and fresh paper should be the first thing you use before you even think about starting to type code for a large project (usually).

[[Gandalf]]

Sigh... Some things are easier said than done. Freakman, be honest and consider how often, or if ever, you have sat down and seriously planned a program. Yes, bash me for not being an idealist, but it's simple fact that unless you're doing something along the lines of a final project you're not going to do all that pre-coding work.

It wasn't the best example on my part, but simply overlooking "readability" for "functionality" is a poor way to write code.

[wtd]

Freakman @ Sat Jan 13, 2007 6:42 am wrote:

that is exactly the point I was trying to get across, even if it wasn't so clear. Also, if you had made a square class, and made it into a Grid class, that would be poor organization on the programmer's part.

Yes, it would represent poor organization, in hindsight. However, that is part of the learning process. Remember, you first have to make stupid mistakes before you can learn from them.

But yes, modifying a class in the way being hinted at here does seem to indicate a lack of understanding of basic OOP concepts and how to apply them. That's not a sin... just a lack of understanding that needs to be rectified. This may take some time, and a great deal of frustration, especially in C++, but try not to let that deter you.

[[Gandalf]]

Can you seriously not see a reason for renaming an existing class? I am continuously astounded by some of the things said here... The one time I can remember doing this was changing Grid to Board; same class but better described as a Board. Sure a Board is a Grid, but for that problem I didn't have to break it down that far since there was little to no difference between a Board and Grid.

And for the record, I'm not talking about spontaneously writing code without thinking it through beforehand. More about doing a written UML-type (though most definately not UML) chart or something of that sort.

[ericfourfour]

If you want to rename a class, the easiest way is to use an IDE that supports refactoring. In Netbeans, for example, you can right click on the name and do refactor -> rename. From there it will ask you the new name and change everything using its name.

[wtd]

[quote="[Gandalf] @ Sat Jan 13, 2007 2:22 pm"]Can you seriously not see a reason for renaming an existing class?[/quote]

Yes, I can see a reason.

What I am trying to say is that having to rename a class isn't a deadly sin, but it does indicate to me that the potential of OOP may not be fully leveraged.

What do I mean by this? Well, my typical approach is to try to break down a problem into the smallest pieces available. When using an OO language, this means creating the smallest classes possible that do something useful and increasing the functionality of those classes either via inheritance or composition.

In short, feel free to rename a class, but don't make a habit of it.

[r.3volved]

No matter what the size of the project, I always take some time for UML.

No matter if it's a few class descriptions or a full system class diagram. I often find statecharts useful, as well as most UML diagrams. Usually by the time I'm done designing the system on paper or with visio, my coding time is [b]significantly[b] decreased. I been assess risks and chokepoints throughout the analysis and design phases of the project so I don't run into any unexpected suprises.

Granted, no matter how much research, analysis and design, you will still run into little unexpected setbacks throughout the coding, but this can be substantially reduced with a good project plan.

In this case, renaming a class is not a huge deal...it is a very minimal correction with the use of search and replace, and yes there are a lot of reasons why you would want to rename a class...it doesn't mean he's changing class square to class circle.

Some of you guys need to jump off that high horse you think you're riding and realise that everyone here is at a different level of skill. A simple question like this deserves a simple answer. No one asks a simple question just so they can get some douche telling them how stupid they are for not knowing. This should have been a little more constructive criticism and a lot less argument.

[wtd]

You provided the perfect bit of immediate help in the first reply. Most of what followed was attempting to point the original poster on the right path. This is absolutely essential, especially with C++, as there is quite a bit of lousy instructional material out there.

Additionally, the criticism offered was constructive. It offered practical alternatives, if ones that might require further learning.

If I and others are not permitted or desired to offer constructive criticism and guiding comments in addition to immediate direct solutions, then I will immediately cease participating in this community.

[[Gandalf]]

r.3volved, in my experience UML has been one huge, colossal, massive pain to work with.

Also, keep in mind that there's nothing wrong with deviating from the original topic a bit, as long as it's still for a good purpose.

wtd @ 2007-01-13, 8:08 am wrote:

Well, my typical approach is to try to break down a problem into the smallest pieces available. When using an OO language, this means creating the smallest classes possible that do something useful and increasing the functionality of those classes either via inheritance or composition.

Ideally... But you can't expect everyone to go down to a what? Molecule class? In my case Grid/Board both extended and was extended by other classes, as well as contained various objects within. The only thing that happened was me deleting the Board class, which was essentially just another layer for the Grid class, and then renaming Grid to Board. I just decided that that layer wasn't neccessary. At worst, you can blame this on an alteration in plans. Please tell me how that's not justified, or what you would have done in the scope of this small project?

[wtd]

Indeed. If I suggest organization, I am in no way endorsing UML. Though if you find it useful, I'm not going to stop you.

AS for the Grid/Board issue, I probably would have kept both, with Board as a thin layer over Grid.