@freeworld - if you've got a class with a lot of accessors and/or mutators, it's often a sign that the class doesn't have a very solid responsibility.
Often in those cases, I'd just make it a struct with no member functions at all. Then perhaps a useful class can be built around that struct.
e.g. your variables could go into an
EngineInfo struct, which many different parts of code can operate on. e.g. a car can own one as a member and perform a simulation on it, a dyno can recieve a const-reference to one to update it's graph, etc... Doing this also breaks the dependency between
Car and
Dyno, as instead, the both have a dependency on
EngineInfo.
Just as food for thought, you could consider some completely different designs. For example, at the moment I assume that your dyno knows about the car class (i.e. in
dyno.cpp, there is a
#include "car.h", etc)? If so, you could consider inverting the relationship:
class Dyno {
void AttachToInput( const float* d );
};
class Car {
Car( Dyno& d ) { d.AttachToInput( &MPH ); }
};Or eliminating the relationship altogether so neither class is aware of the other:
class Dyno {
void AttachToInput( const float* );
};
class Car {
const float& MPH() const { return m_MPH; }
};
void HigherThirdParty()
{
Dyno d;
Car c;
d.AttachToInput( &c.MPH() );
}@ApochPiQ - you actually
can in C++ using an ugly mix of reference-cast operators and sub-class members with friends, etc, etc, but it ends up being
extremely verbose. I usually just put a comment on my friend declarations saying which members that friend is supposed to be touching, that is, in the rare cases where friend is justified in the first place.
Usually friend issues simply go away when a design is modified to reduce individual relationships and responsibilities.
0
