Eh, I suppose some overloading couldn't hurt.

Kayle - any reason why you haven't defined a common ShipComponent superclass which handles the name and mass properties, and have the rest of your components inherit from that? You might possibly put componentHitPoints on it as well.

My immediate instinct would be to have the total mass of the components calculated dynamically when needed rather than cached by the chassis; but it depends how you want to use it.

Weapon and Launcher might well have a common superclass too, which handles things like refire rate. Similarly, anything which uses energy could potentially inherit from (or use an instance of) a class that models energy use.

Er. Wow. I dunno. I'm still learning this OOP stuff, and I'm honestly having a hard time wrapping my head around most of it, coming from a procedural background.

At one point, I did have a Part class that all the components inherited from, but I gave up on that when it didn't really make sense, because while they all shared one or two common fields, the majority of them didn't really share much at all, and I guess it seemed like a waste of a class for a class with only a std::string in it.

It wouldn't save you anything but a little typing anyways in terms of resources. Although, sometimes that's a powerful reason. Careful not to let your design be driven by this though.

Well, at the moment that class might contain only a couple of properties; but, further down the line, it might well end up also handling some of the behaviour that depends on those properties. The idea is that the code to deal with any given set of functions should (other things being equal) appear only in one place. There is (presumably) eventually going to be some behaviour that depends on ComponentHitPoints: a component has to have the ability to take damage, to have damage repaired, to be entirely destroyed, etc. If each component class implements that behaviour itself, then you have duplication of code. That means more typing; but, more importantly, it also means a maintenance nightmare, because if you want to change some aspect of ComponentHitPoint handling, instead of changing it in just one place you have to change it in several different places at once and make sure you haven't missed any, and that they all now do the same. Probably the single most important objective of OOP is to make code easier to maintain.
:smile:

That's what I was going to say too. :)

To expand a bit, rather than having the values for currentMass be public variables (which the OO purists are screaming at you for doing anyways), you might want to make them private variables with accessors because you could then use the same method to get the mass value of anything.

If it's a simple object, it will just return whatever the value of m_currentMass is. However, asking for the mass of the ship (as a whole) might do a function that returns the sum of the mass values each component returns. That eliminates the need for any kind of "update" loop, or for the code that lets you assemble/disassemble ships to have to know anything about it.

Aaaaaargh!

No but srsly, one of my bugbears with Java (and yes, I know this isn't Java) is the endless boiler plate code of getters and setters you have to wade through.

Even though I could be seen as an OO purist, getters and setters really serve no purpose other than to give an ability to override the behaviour of setting or getting that value. If you have no immediate need to do this, then I don't see a problem with using the variable until you do.. Most ide's allow refactoring of this sort of thing anyway.

Not to blow the Groovy horn too loudly, since I expect ruby does this too, is that it has implied getters and setters. That is to say that obj.a and obj.getA() are treated as the same call.

Anyhew, like anything, setters and getters have their place and can be overused. If you're worried about protecting your variable, is their a Cpp equivalence of package level protection you could use? I forget now.

Actually in Ruby you have to explicitly use getters and setters. Otherwise there is no way to access an object. In other words, you can't expose an object in any other way.

To be fair, Ruby uses meta programming to make it painless. For example:

class Roar
  attr :variable
end
r = Roar.new

r.variable

However, behind the metaprogramming it's simply def variable; @variable; end

The point is that doing it now is essentially free, and typing x.foo and x.getFoo() are not really that different, as opposed to having to later on have to go in and rewrite all occurrences. I actually disagree with the statement that most IDEs make this kind of refactoring easy; Java IDEs tend to do it, but do you have examples for other languages?

No, I just sort of .. ahem .. assumed they did :shrug:

*quick google*

Well Eclipse can, and that does do C++.

I CBA to find any more, I'll leave it as an exercise for the reader.

"Doing it now" /could/ be seen as premature generalization, even in this situation… it may save time now, but is it really worth doing?

Premature generalization is wrong when it costs you something. The statements made against premature optimization are made when the optimization actually introduces complexity, without having first established that the code in question needs to be optimized (hence "premature"). If something introduces no complexity or real work, people wouldn't argue against it.

I would argue that adding getters and setters to n properties creates 2n methods and is quite a bit of code bloat for no benefit, and if your ide doesn't refactor for you it could be a lot of typing.. But eh, I ain't gonna argue wiv ya DH.

edit: oops fixed that up :)

My IDE shouldn't be changing my code for me. And I'm quite glad it doesn't.

Premature generalization or not, using getters and setters from the start ensures proper encapsulation and that things that shouldn't be changing the variable can't change it.

2n, not n^2. :smile:


Refactoring comes into play when you decide to change it later, no? When you're writing it from the start, you only add the getters/setters once. Then referring to them is just x.getFoo() rather than x.foo.

When I said refactor I meant generate but I am guessing more non-java ides generate boiler plating than do refactoring? Was that the point?

Anyway, it's so much of a biggy that I'm going to spend two pages arguing the toss over it. It's just nice to know it doesn"t have to be done and I feel quite liberated by that thought :)

… And as I said, this could also be achieved by package protection of your variable. It's a moot point tho if you don't mind the extra keystrokes :)

I guess I don't really understand your usage of the term 'refactor'; the stuff you seem to be talking about is code templates. Refactoring means changing code structure, not generating boilerplate. Eclipse can do both structure changing and template addition; many people who use vi/emacs/etc. can do templates but typically not restructuring.

Anyhow in many languages it's a formally unsolvable problem to automatically rearrange things like this unless you apply a liberal dose of guess-work. (C++ is not such a language.) In languages like this (typically the dynamically typed ones without type inference) you can't rely as much on "easy magic refactoring" from an IDE. That was my point.

BTW you keep saying you're not going to argue about this; I don't think anybody is arguing here… why does an exchange of ideas have to be an argument? It makes it all sound unpleasant and confrontational…

For clarity, Eclipse allows you to "refactor" your code so that when it generates getters and setters, it updates all instances of the variable used directly everywhere and hides them behind the method call. I understand templates to be pre-generated code boilerplating, but I think perhaps I meant specifically "generating boilerplate", so sorry for the confusion.



Yes, I would agree (if I understand you correctly). I thought we were talking about CPP tho, not Ruby. In languages like ruby, this sort of refactoring isn't required, because as Runter pointed out, it's part of the language constructs to do it far more simply.



Yea well, I don't mean argument in a negative context. I was just aware that it could turn into a full blown debate, and I wasn't looking for one. I was just tossing in some experience into the mix :D

And now back to your regularly scheduled content.