Jump to content
  • Advertisement
Sign in to follow this  
EverIce

Class data members know each other, How?

This topic is 5399 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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 :
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();
      ...
   }
};

It's works, but it's ugly. Has onyone know some better solution to this problem ?

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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 ?


class A
{
...
virtual int getNum() = 0;
void calc();
...
};

class X : public A
{
...
int getNum() { ... }
...
};

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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);

};

Share this post


Link to post
Share on other sites
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() { ... }
}

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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...)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!