Re: inheriting from std::vector bad practice?
On 3 Apr, 17:30, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
Alf P. Steinbach wrote:
* Steve Chow:
Originally I had a bunch of related functions that all took a vector
of Point2D as their argument.
Point2D findGreatestDistance(std::vector<Point2D>& points);
However, this didn't strike me as a very C++/OO way to do things, so I
found a solution I was happy with in:
class Path : public std::vector<Point2D>
{
public:
Path();
~Path();
Point2D findGreatestDistance();
/* related functions */
};
eeek!
And it works, at least as far as I can tell. Yet it's been received by
people more knowledgeable than me as disgusting and wrong, without
explaining why.
http://en.wikipedia.org/wiki/Liskov_substitution_principle
Is there a better way I should be doing this?
http://en.wikipedia.org/wiki/Delegation_(programming)
Yes. In terms of knowledge distribution you have ensured that the
knowledge required to do something (findGreatestDistance) is there. But=
in
doing so you have enabled both inadvertent and intentional abuse of
knowledge, like posting a recipe for creating a simple biological
weapon-of-mass-destruction on the net; you have forgotten to /limit/ th=
e
access to those in need to know.
I have difficulties in seeing what you mean; especially with the advice y=
ou
give below.
I must admit the bio-weapon reference confused me...
Someone suggested moving findGreatestDistance into Point2D (struct
with x,y and overload ==) but I don't see how that's possible beca=
use
it'd only be able to look at itself.
Yes, that sounds like a silly suggestion.
Instead, replace inheritance of std::vector<Point2D> with a private
member.
Ok, lets say we had:
class Path {
std::vector<Point2D>
um. shouldn't that have a name?
std::vector<Point2D> m_point_vector;
public:
Path();
~Path();
Point2D findGreatestDistance();
/* related functions */
};
How does that limit the knowledge of findGreastedDistance to those in nee=
d
to know?
it limits access to the vector
--
Nick Keighley
Let q(x) be a property provable about objects x of type T.
Then q(y) should be true for objects y of type S where S is a subtype
of T.