class X
{
int mNum;
A mA;
B mB;
int num()const{ return mNum;}
};
class A
{
float mFloat;
X *mOuter;
void calcSomething()
{
int i = mOuter->num();
...
}
};
Class data members know each other, How?
Author
I think the one of the problem of OO is this. Because every object act like a machine. It has parts and they dumb like hell.
So i've run into many situation when :
It's works, but it's ugly. Has onyone know some better solution to this problem ?
It Depends. Having both an accessor and a mutator for the same variable is a sign that something is wrong with your design. Having only one of the two is often the best way to handle the variable though. Sometimes it makes sense to have something not quite a direct accessor/mutator. Sometimes you need to shift (part of) the calculation to a different object to make things right.
Every now and then, some people will tell you that it's reasonable to just leave the variable public. The real reason for making things private, after all, is to avoid dependancies between modules. If the variable is a logical part of the object's interface, goes the reasoning, then let it be. But personally, I've never really needed to do that, except temporarily for debugging purposes.
Every now and then, some people will tell you that it's reasonable to just leave the variable public. The real reason for making things private, after all, is to avoid dependancies between modules. If the variable is a logical part of the object's interface, goes the reasoning, then let it be. But personally, I've never really needed to do that, except temporarily for debugging purposes.
i think his point was more that class A has an instance of class X and class X has an instance of class A ... as in they both reference the other.
Anyway most of the time you'll find you don't actually need that if you re-design your solution. Once your pretty comfortable with OO you won't see that problem very often because you'll know when your heading towards it and change your design befor it appears. Still sometimes it is the best way to deal with things, and as far as I know there isn't a nicer way to deal with it (although personally I don't really see whats so wrong/ugly with it).
Anyway most of the time you'll find you don't actually need that if you re-design your solution. Once your pretty comfortable with OO you won't see that problem very often because you'll know when your heading towards it and change your design befor it appears. Still sometimes it is the best way to deal with things, and as far as I know there isn't a nicer way to deal with it (although personally I don't really see whats so wrong/ugly with it).
So A is a part of X, but A needs to call functions on X.
So why not let X derive from A, letting A contain a virtual abstract function getNum() and X has to implement it ?
So why not let X derive from A, letting A contain a virtual abstract function getNum() and X has to implement it ?
class A{ ... virtual int getNum() = 0; void calc(); ...};class X : public A{ ... int getNum() { ... } ...};
There are mainly (on top of my head ) two design patterns that you should use for these kind of situation.
1. The first one is on more of the data kind. You simple abstract all functionality and let all functionality derive form the actual super class.
class Mother
{
calcAandB();
};
class A
{
//Only data
float number
}
class B same as A.
2. That is perhaps in you case the best one and that is also the way they solve these kind of things in bigger system. That is that you derive all classes from a object class and let them talk to eachother. That way you keep the classes from being nested to much.
like so:
class Mother : public CObject;
class Child
{
Child(CObject owner);
};
1. The first one is on more of the data kind. You simple abstract all functionality and let all functionality derive form the actual super class.
class Mother
{
calcAandB();
};
class A
{
//Only data
float number
}
class B same as A.
2. That is perhaps in you case the best one and that is also the way they solve these kind of things in bigger system. That is that you derive all classes from a object class and let them talk to eachother. That way you keep the classes from being nested to much.
like so:
class Mother : public CObject;
class Child
{
Child(CObject owner);
};
This is one of the things that I really like in Java: inner classes solve this problem very nicely.
[source lang = "java"]class X{ class A { void calcSomething() { int i = num(); ... } } int num() { ... }}
Author
Painless : that function of java what i'd believed that c++ knows. Inner classes, :(.
Anonymous poster and nmi thanks. I'll find out wich one fits me mostly.
Anonymous poster and nmi thanks. I'll find out wich one fits me mostly.
Quote:Original post by Painless
This is one of the things that I really like in Java: inner classes solve this problem very nicely.
*** Source Snippet Removed ***
EverIce, please don't take this post as a suggestion, because I'm fishing for ideas myself. But doesn't defining a friend class provide the same basic functionality of an inner class in Java? The only real difference that I see is that A is publically available in C++, whereas in Java it is only accessible through X.
CM
Quote:Original post by Conner McCloud
EverIce, please don't take this post as a suggestion, because I'm fishing for ideas myself. But doesn't defining a friend class provide the same basic functionality of an inner class in Java? The only real difference that I see is that A is publically available in C++, whereas in Java it is only accessible through X.
CM
Not quite. In the Java code I showed, instances of class A are always tied to instances of class X. Therefore, they can access instance members of class X without need to specify an instance of X. This is great, because it removes the need to keep around (not to mention initialize) that annoying mOuter variable. Sure, it is pretty much just "syntactic sugar", but it tastes very good. Java also has an excellent "anonymous inner class" concept.
Quote:Original post by Painless
Sure, it is pretty much just "syntactic sugar", but it tastes very good.
Yes. Too bad it is so expensive :( (in JAR space, mainly; I am working in J2ME, you see...)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
