Jump to content

  • Log In with Google      Sign In   
  • Create Account

[OOP] Two classes that can acces each other's members


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
16 replies to this topic

#1 cold_heats_.--.   Members   -  Reputation: 127

Like
0Likes
Like

Posted 28 July 2012 - 04:26 PM

Hello.
Suppose I have two classes : class A and class B .
In my program , A needs to acces some of B's members but B also has to acces some of A's members.
If it's possible, how do I implement this in C++ ?
A and B are separate entities.I do not want to include one of them as a member of the other one .

Sponsor:

#2 Madhed   Crossbones+   -  Reputation: 2891

Like
6Likes
Like

Posted 28 July 2012 - 05:29 PM

A. Make all members public
B. Expose a public interface to those members on either class
C. Declare A and B as mutual friend classes.
D. Rethink your design

Edited by Madhed, 28 July 2012 - 05:32 PM.


#3 Mussi   Crossbones+   -  Reputation: 1965

Like
0Likes
Like

Posted 28 July 2012 - 05:34 PM

Could you tell us more about what you're trying to implement?

#4 cold_heats_.--.   Members   -  Reputation: 127

Like
0Likes
Like

Posted 28 July 2012 - 06:14 PM

@Mussi Well the A and B are the player and the enemy.
The enemy's AI is implemented as a state machine. By default , he leaves the player alone.
The player can however trigger the "Attack" stance of the enemy, but for that he needs to read some info from the enemy object(the enemy position for example).
In order to run the "Attack" stance, my enemy also has to read the player object's informations (like player position and speed for example);
Also, he must modify the player's speed at begining of the "Attack" stance and set it back after the "Attack" finishes.
I've adopted this method because it seems more logical to me. Only the enemy knows when he stops the attack and its reasonable that he reinitializes the player's speed too.There's no point in querying the player object
" Are you in a "chased" stance ? " at each iteration, at least I dont think so.

@Madhed
C.How do I do that ?
From what I know , if A is a friend of class B, then there must be an object of type B in A's declaration so that A can acces the private B's stuff.

I used to classes just for this example.In reality , the player must acces the members of a second class too, C containing the obstacles .

Edited by cold_heats_.--., 28 July 2012 - 06:16 PM.


#5 PeterF   Members   -  Reputation: 605

Like
0Likes
Like

Posted 28 July 2012 - 06:58 PM

I think what you're looking for is forward declaration and friendship. Here's the best I can do without any more information:
[source lang="cpp"]class A;class B{ friend class A; int x; // can be any data type, I chose int for simplicity public: void do_stuff(A a_object); // some function that acts on an A's private members};class A{ friend class B; int y; public: void do_stuff(B b_object);};[/source]
Now you can do something like:
[source lang="cpp"]B::do_stuff(A a_object){ a_object.x += 1;}A::do_stuff(B b_object){ b_object.y += 1;}[/source]

#6 Mussi   Crossbones+   -  Reputation: 1965

Like
1Likes
Like

Posted 28 July 2012 - 08:10 PM

A few alternatives to consider: only feed the information that's necessary instead of the entire object and/or introduce a third class/function that takes both objects and passes on information to each other.

Edited by Mussi, 28 July 2012 - 08:12 PM.


#7 hstubbs3   Members   -  Reputation: 172

Like
2Likes
Like

Posted 29 July 2012 - 01:10 AM

"Player" and "Enemy" don't sound like distinct classes to me - they are "combatant"

"Combatant" has speed, position, possibly weapons, inventory, etc..

Then "Player" is a class derived from "Combatant" - uses input (keyboard,mouse, etc.) to change animations, positions, etc.

And "Enemy" is also class derived from "Combatant" - but this uses AI to drive it...

This would also allow later for AI characters to fight on either side, or possibly have multiple factions...
And networked / LAN players could be derived as well...

#8 hstubbs3   Members   -  Reputation: 172

Like
0Likes
Like

Posted 29 July 2012 - 01:12 AM

Oops.. forgot the last bit as well...

So - if any combatant needs info on another combatant, it just accesses the base-class ( or higher class through an interface / virtual function )..

No combatant knows or cares what is "brains" - only if they are "friend" or "foe" or if they're attacking, etc.. etc..

#9 Madhed   Crossbones+   -  Reputation: 2891

Like
0Likes
Like

Posted 29 July 2012 - 05:28 AM

I should have posted a more detailed reply. Actually you should first consider points B or D from my list. Using friend declarations is almost always a bad code smell and you should consider doing it differently.

Why don't you introduce another layer as Mussi has suggested. A system that keeps track of object positions, where the Enemies can create triggers that get executed when a player enters. That way the logic is a level higher than the individual players or enemies and the enemies just get notified when a player enters their field of view.

#10 Bacterius   Crossbones+   -  Reputation: 8817

Like
0Likes
Like

Posted 29 July 2012 - 05:37 AM

I have to agree with Madhed here. If you end up having a circular reference between two distinct classes, it usually implies your code design has failed, and there is often a better solution to achieve what you are after.

The slowsort algorithm is a perfect illustration of the multiply and surrender paradigm, which is perhaps the single most important paradigm in the development of reluctant algorithms. The basic multiply and surrender strategy consists in replacing the problem at hand by two or more subproblems, each slightly simpler than the original, and continue multiplying subproblems and subsubproblems recursively in this fashion as long as possible. At some point the subproblems will all become so simple that their solution can no longer be postponed, and we will have to surrender. Experience shows that, in most cases, by the time this point is reached the total work will be substantially higher than what could have been wasted by a more direct approach.

 

- Pessimal Algorithms and Simplexity Analysis


#11 cold_heats_.--.   Members   -  Reputation: 127

Like
0Likes
Like

Posted 29 July 2012 - 08:41 AM

Well, this is my second try to OOP design a game :P .I never would have thought this field is so complicated.
It seems I missed a lot.It would have never occured to me to try an idea like hstubb's one.
I guess I'll try for the moment Mussi's first suggestion.
Thanks for the time to reply :) .

#12 ASnogarD   Members   -  Reputation: 212

Like
0Likes
Like

Posted 29 July 2012 - 09:22 AM

Wouldnt it be worth experimenting with inheritance ?

Make a base class , say Entity ( controls all types of movable objects) , and have Player inherit this Entity class, and your Enemy inherit the class... so both are a Entity, and share the basic structure of an Entity but have special functions related to themselves.

I am not too comfortable with OOP myself, but that would be something I would experiment with as a attempt to see if it solves my issues.

#13 kuramayoko10   Members   -  Reputation: 386

Like
0Likes
Like

Posted 29 July 2012 - 05:18 PM

You have some freedom in C++ that you shouldn't use if you want to follow correctly the OO paradigm. For example, suggestion A of Madhed said:

A. Make all members public


This is very wrong. C++ allows you to do that, but you will create a strong relationship between A and B that may cause you greater problems in the future. Besides, those classes won't be easily reused throughout your code or other projects.

Try looking a little into OO basics and search for some Design Patterns like MVC first.
Programming is an art. Game programming is a masterpiece!

#14 cold_heats_.--.   Members   -  Reputation: 127

Like
0Likes
Like

Posted 29 July 2012 - 11:37 PM

Thanks, I'll look at it .

#15 CaptainKraft   Members   -  Reputation: 266

Like
0Likes
Like

Posted 30 July 2012 - 02:18 PM

I'm a beginner and only have experience with Java so far, but accessing another classes members should be as simple as creating a public method that returns the wanted information.

Maybe I don't understand the question properly.

#16 cold_heats_.--.   Members   -  Reputation: 127

Like
1Likes
Like

Posted 31 July 2012 - 04:28 AM

I'm bumping because I wanted to show you my design for the game.
http://imgur.com/aez1h

The dots represent pointers .Order of declaring classes is bottom up .
Tell me , how bad is it ..

#17 Mussi   Crossbones+   -  Reputation: 1965

Like
0Likes
Like

Posted 31 July 2012 - 08:16 AM

Your current design will quickly turn into spaghetti code if it hasn't already. I think you should start with reading this and then read up on some other OO design principles(hope someone else can provide some good resources, don't have any at hand).

Edited by Mussi, 31 July 2012 - 08:17 AM.





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS