Hello, I have a query regarding the possibilities of a class method (class A) calling the method of another class (class B), with a method of that class (B) calling a method of the first class (A). For example, take the following (which won't compile as is, but please see below):
class A
{
public:
vector<int> a_test;
A_method_1 (int a)
{
//doing something simple to a_test...
a_test.push_back(a);
}
A_method_2 ()
{
//do something else, then call a method from class B...
B_method_1(2);
}
};
class B
{
public:
vector<int> b_test;
B_method_1 (int b)
{
//doing something simple to b_test...
b_test.push_back(b);
}
B_method_2 ()
{
//do something else, then call a method from class A...
A_method_1(1);
}
};
Basically, the aim is for a method in class A (or rather object _A) to modify some data structure in class B (or rather object _B) at some point, and then for a method in class B to modify some structure in class A at some later point. There are multiple instantiations of both classes A and B, so what I have done is the following (using the class A method for example):
1 2 3 4 5 6 7
//redefine A_method_2 to take an argument of type class B by reference
A_method_2 (B &b)
{
//do stuff
b.B_method_1(2);
}
//and then the vice versa for the definition of B_method_2...
My query is: is there a more preferable/logical/efficient means of doing this? For me, classes A and B
are functionally very different (apart from this cross-over!), and so straightforward inheritance won't work here.
Many thanks in advance for any feedback/suggestions you may have.
Nope, that would pretty much be the only way to do it.
However, if the classes are regularly modifying a specific instance of the other class (i.e. each class A has a specific class B that it will always modify), then you could have class A/B contain a pointer/reference (depending on when you set/need it) to the other class.
Thank you both for your very quick and helpful replies!
firedraco:
That's interesting, may use that (even though it just changes the organisation rather than the way its done, as far as I understand) - each instantiation of class A is 'paired' with an instantiation of class B in the sense that object_A1 always interacts with object_B1, object_A2 with object_B2, etc...
onur:
I have A_method_2 as a member of class A since it performs computation within the members of class A, with the result being used on the call to the method in class B. If I understand your suggestion correctly, then it will be useful in certain circumstances, but I don't think here. Hmm, will have a think about it though...
One issue that may become relevant (but I don't think to this example in itself) is that class B (for example) is a 'stub/dummy' for a far more complex class written by someone else. Therefore, I want to be able to minimise the modifications required in that class to interact with my class A. The encapsulation thing is important here :-) Thanks again.
It doesn't matter how far apart you think 2 classes are: You will always find common ground if you look hard enough.
With the above in mind, think about interfaces (in the COM or .Net way). Interfaces excel at providing a contract between 2 otherwise unrelated classes. Examples: A building and a car. Two quite unrelated objects, but in the context of inventory or accounting, you can see each as an asset, with a nominal value, etc. By creating the Car class and the Building class so that they both implement the pure virtual class IAsset, you have a common ground to work with the two.
So find the common ground here and define a pure virtual class that satisfies the scenario.