Carrying on from here, to answer NwN
See my description of an example below:
With the friend functions, I was trying to find out if it was worth factoring out as much as possible from the Data class. Given MiiNiPaa
's answer, it is not worth doing that for member interface functions. I managed to move some of the heavy calcs to the Input Validation class though. The problem with friend functions or classes between the Data class and an Algorithm class is that I would have to keep adding friend declarations to the Data class for each new algorithm function, which I definitely don't want to do - the Data class shouldn't change.
Although I would also say that friends don't necessarily break encapsulation, but they do seem to increase coupling.
Crikey, I hope that people don't get the Data & Container class concepts mixed up - maybe I should refer to it as the Item class?
Thanks for your comments - appreciated.
When you say Obscure data, is that in reference to the idea of a Container class, or an Algorithm class?
If it is the container class, how is that different to say a
? Another example may be a Bank class which has a private member that is a vector of Account objects, with say a find function that returns an individual account, which then can used via it's interface.
If it is the Algorithm class, how is that different to the STL algorithms? I mentioned putting a line intersection function into an algorithm class, rather than in the line class.
|Also member functions does not add any weight for class. It is internal variables, keeping synch between different parts of class and large amount of data which makes it heavy for concurrent access.|
Ok, good. I will provide an example to demonstrate what I meant specifically.
I was thinking about a circular arc class. There are lots of ways to specify an arc, one of them is 3 points on the arc. Now this takes a reasonable amounts of calcs to come up with a centre point & radius, startangle and endangle, and involves a number of internal variables and private functions. So I was thinking rather than have constructors for each way of specifying an arc, have them as overloaded functions in the
class. This could possibly be a singleton - whatever we only need 1 object of this type, to be used repeatedly to create CArc objects. The overloaded functions would do all the validation of the input, and all the calcs, and finally call the only
constructor in the
class, using only data for centrepoint, radius, startangle and endangle. So this saves all the internal variables. The
class still has it's interface.
Now the Container class. It has a private member which is a container of CArc objects -
say. The class has an interface that does all the classic container functions - retrieve, add & delete items etc.
The Algorithm class would have functions like
say, but more likely generalised:
bool IsInside(CGeometry Obj1, CGeometry Obj2)
Functions like Move, Rotate, Scale, Copy etc could probably be virtual functions in the Data class.
I hope this example clears up what I was intending.
With your point class example, I see what you are saying - it is a good example of the advantages of an interface, and I can see how it doesn't break existing client code. It bugs me that the set functions are public though - how to prevent malicious use? I already mentioned virtual functions, what about send / receive functions?
Anyway, the good thing about mentioning ideas, is that it gives you guys a chance to shoot it down, and / or provide advice about a better way - all of which is welcome to me
EDIT: I spent ages writing this, so will now have to digest MiiNiPaa's latest post.