Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
polymorph?
148 views
Skip to first unread message
Jens Kallup
Mar 20, 2016, 7:01:16 AM3/20/16
to
Hello,
How can I create a C++ structure of classes:
Shape
|
PositionOfShape
/ \
Rectangle Circle
\ /
Properties
- Color
- Brush...
I think each class (Rectangle, and Circle) have
same standard properties.
Can i specialize it in sub class?
Like radius of Circle, and radius of borders
circle (as example)?
Is it possible to iterate through Shape to know
how many objects are present?
TIA
Jens
How can I create a C++ structure of classes:
Shape
|
PositionOfShape
/ \
Rectangle Circle
\ /
Properties
- Color
- Brush...
I think each class (Rectangle, and Circle) have
same standard properties.
Can i specialize it in sub class?
Like radius of Circle, and radius of borders
circle (as example)?
Is it possible to iterate through Shape to know
how many objects are present?
TIA
Jens
Victor Bazarov
Mar 20, 2016, 9:09:11 AM3/20/16
to
hint for you: look into virtual inheritance. Keyword: diamond pattern.
V
--
I do not respond to top-posted replies, please don't ask
Mr Flibble
Mar 20, 2016, 1:36:49 PM3/20/16
to
/Flibble
Öö Tiib
Mar 20, 2016, 4:25:10 PM3/20/16
to
On Sunday, 20 March 2016 13:01:16 UTC+2, Jens Kallup wrote:
> Hello,
>
> How can I create a C++ structure of classes:
>
> Shape
> |
> PositionOfShape
> / \
> Rectangle Circle
> \ /
> Properties
> - Color
> - Brush...
>
> I think each class (Rectangle, and Circle) have
> same standard properties.
What book you read about object oriented design?
> Hello,
>
> How can I create a C++ structure of classes:
>
> Shape
> |
> PositionOfShape
> / \
> Rectangle Circle
> \ /
> Properties
> - Color
> - Brush...
>
> I think each class (Rectangle, and Circle) have
> same standard properties.
> Can i specialize it in sub class?
is likely because one of such cases:
* Rectangle is always Circle too.
* Circle is always Rectangle too.
* Rectangle and Circle are always DrawnThingies and the common
properties are those of DrawnThingy.
* Rectangle and Circle have some common to both component DrawingTools.
There are no way out of that puzzle without brain power applied.
Common sub-class does not help you. It is for complex cases when it
happens that something is fully both Circle and Rectangle. For
example RectangularCircle. Does RectangularCircle make sense?
> Like radius of Circle, and radius of borders
> circle (as example)?
ways with previous sentences ... but radius does make no sense about
Rectangle to me, sorry.
>
> Is it possible to iterate through Shape to know
> how many objects are present?
then it is possible. Some things are just little bit more expensive
to implement than others. So start with basics, what objects the
Shape consists of? Why you want to implement iterating over
those?
Juha Nieminen
Mar 20, 2016, 4:54:27 PM3/20/16
to
Jens Kallup <jka...@web.de> wrote:
> Hello,
>
> How can I create a C++ structure of classes:
>
> Shape
> |
> PositionOfShape
> / \
> Rectangle Circle
> \ /
> Properties
> - Color
> - Brush...
>
> I think each class (Rectangle, and Circle) have
> same standard properties.
> Can i specialize it in sub class?
> Like radius of Circle, and radius of borders
> circle (as example)?
If Rectangle and Circle have common properties, then they go into
> Hello,
>
> How can I create a C++ structure of classes:
>
> Shape
> |
> PositionOfShape
> / \
> Rectangle Circle
> \ /
> Properties
> - Color
> - Brush...
>
> I think each class (Rectangle, and Circle) have
> same standard properties.
> Can i specialize it in sub class?
> Like radius of Circle, and radius of borders
> circle (as example)?
a common base class. That's object-oriented design 101.
> Is it possible to iterate through Shape to know
> how many objects are present?
in C++. (They don't necessarily have the same meaning as in other
object-oriented languages.)
--- news://freenews.netfront.net/ - complaints: ne...@netfront.net ---
Jerry Stuckle
Mar 20, 2016, 11:02:48 PM3/20/16
to
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================
Jerry Stuckle
Mar 20, 2016, 11:09:42 PM3/20/16
to
On 3/20/2016 7:01 AM, Jens Kallup wrote:
always a "type of" relationship - that is, both Rectangle and Circle are
a "type of" shape.
However, "PositionOfShape" is not a type of Shape - it is an attribute
of a Shape. So it should be an attribute of Shape, not a derived class.
Jerry Stuckle
Mar 20, 2016, 11:26:36 PM3/20/16
to
On 3/20/2016 4:24 PM, Öö Tiib wrote:
> On Sunday, 20 March 2016 13:01:16 UTC+2, Jens Kallup wrote:
>> Hello,
>>
>> How can I create a C++ structure of classes:
>>
>> Shape
>> |
>> PositionOfShape
>> / \
>> Rectangle Circle
>> \ /
>> Properties
>> - Color
>> - Brush...
>>
>> I think each class (Rectangle, and Circle) have
>> same standard properties.
>
> What book you read about object oriented design?
>
>> Can i specialize it in sub class?
>
> If you think that Rectangle and Circle have common properties then it
> is likely because one of such cases:
> * Rectangle is always Circle too.
> * Circle is always Rectangle too.
> * Rectangle and Circle are always DrawnThingies and the common
> properties are those of DrawnThingy.
> * Rectangle and Circle have some common to both component DrawingTools.
> There are no way out of that puzzle without brain power applied.
>
Both are Shapes. And deriving from Shape would be correct.
> On Sunday, 20 March 2016 13:01:16 UTC+2, Jens Kallup wrote:
>> Hello,
>>
>> How can I create a C++ structure of classes:
>>
>> Shape
>> |
>> PositionOfShape
>> / \
>> Rectangle Circle
>> \ /
>> Properties
>> - Color
>> - Brush...
>>
>> I think each class (Rectangle, and Circle) have
>> same standard properties.
>
> What book you read about object oriented design?
>
>> Can i specialize it in sub class?
>
> If you think that Rectangle and Circle have common properties then it
> is likely because one of such cases:
> * Rectangle is always Circle too.
> * Circle is always Rectangle too.
> * Rectangle and Circle are always DrawnThingies and the common
> properties are those of DrawnThingy.
> * Rectangle and Circle have some common to both component DrawingTools.
> There are no way out of that puzzle without brain power applied.
>
> Common sub-class does not help you. It is for complex cases when it
> happens that something is fully both Circle and Rectangle. For
> example RectangularCircle. Does RectangularCircle make sense?
>
>> Like radius of Circle, and radius of borders
>> circle (as example)?
>
> What? Try with full sentence. I attempted to combine it in various
> ways with previous sentences ... but radius does make no sense about
> Rectangle to me, sorry.
>
>>
>> Is it possible to iterate through Shape to know
>> how many objects are present?
>
> If programmer (or some defect made by programmer) makes it possible
> then it is possible. Some things are just little bit more expensive
> to implement than others. So start with basics, what objects the
> Shape consists of? Why you want to implement iterating over
> those?
>
Alf P. Steinbach
Mar 21, 2016, 3:01:42 AM3/21/16
to
On 20.03.2016 12:01, Jens Kallup wrote:
> Hello,
That's what President Obama also said at the start, in his yearly speech
to the Iranians, now two or three days ago.
> How can I create a C++ structure of classes:
>
> Shape
> |
> PositionOfShape
> / \
> Rectangle Circle
> \ /
> Properties
> - Color
> - Brush...
Nice but misleading ASCII artwork. The connecting lines denote quite
different forms of relationship, as I see it. For presumably a Rectangle
IS a Shape, for example, while a Shape HAS a Position, or HAS a Color.
This is one basic thing you need to be careful with, and keep in mind
that beginners have a tendency to incorrectly model HAS as IS.
Essentially then,
Shape
HAS a position
HAS a line color
HAS a background brush
Rectangle IS a Shape
Circle IS a Shape
Next you need to think hard about whether such objects are pure VALUES
or MUTABLE (objects whose values can be modified).
If they are pure values, like numbers, then a Circle can be a kind of
Ellipse, because it has all the properties of an Ellipse. It's just a
subset of ellipses. The other way doesn't work, because it's not the
case that every Ellipse or most Ellipses has exactly one radius.
But if they are mutable, then if a Circle were derived from Ellipse then
one could presumably use some modifier function of Ellipse to make that
Circle elongated, decidedly un-Circle like. And thus breaking the class
invariant of Circle. And so with mutable objects it's impractical to
derive Circle from Ellipse. Instead one can offer conversions between
these classes. A conversion from Circle to Ellipse will always succeed
except for e.g. memory exhaustion.
> I think each class (Rectangle, and Circle) have same standard
> properties. Can i specialize it in sub class?
A derived class is a specialization. It is also an extension.
> Like radius of Circle, and radius of borders circle (as example)?
If you're talking about radius of borders then that doesn't sound very
reasonable.
> Is it possible to iterate through Shape to know how many objects are present?
If you put these objects in a collection, yes.
Cheers & hth.,
- Alf
> Hello,
That's what President Obama also said at the start, in his yearly speech
to the Iranians, now two or three days ago.
> How can I create a C++ structure of classes:
>
> Shape
> |
> PositionOfShape
> / \
> Rectangle Circle
> \ /
> Properties
> - Color
> - Brush...
different forms of relationship, as I see it. For presumably a Rectangle
IS a Shape, for example, while a Shape HAS a Position, or HAS a Color.
This is one basic thing you need to be careful with, and keep in mind
that beginners have a tendency to incorrectly model HAS as IS.
Essentially then,
Shape
HAS a position
HAS a line color
HAS a background brush
Rectangle IS a Shape
Circle IS a Shape
Next you need to think hard about whether such objects are pure VALUES
or MUTABLE (objects whose values can be modified).
If they are pure values, like numbers, then a Circle can be a kind of
Ellipse, because it has all the properties of an Ellipse. It's just a
subset of ellipses. The other way doesn't work, because it's not the
case that every Ellipse or most Ellipses has exactly one radius.
But if they are mutable, then if a Circle were derived from Ellipse then
one could presumably use some modifier function of Ellipse to make that
Circle elongated, decidedly un-Circle like. And thus breaking the class
invariant of Circle. And so with mutable objects it's impractical to
derive Circle from Ellipse. Instead one can offer conversions between
these classes. A conversion from Circle to Ellipse will always succeed
except for e.g. memory exhaustion.
> I think each class (Rectangle, and Circle) have same standard
> properties. Can i specialize it in sub class?
> Like radius of Circle, and radius of borders circle (as example)?
reasonable.
> Is it possible to iterate through Shape to know how many objects are present?
Cheers & hth.,
- Alf
Zaphod Beeblebrox
Mar 21, 2016, 7:34:26 AM3/21/16
to
On Sunday, 20 March 2016 11:01:16 UTC, Jens Kallup wrote:
> Shape
> |
> PositionOfShape
> / \
> Rectangle Circle
> \ /
> Properties
> - Color
> - Brush...
Yes, you can, and it's not a case of multiple inheritance, as others have said.
> Shape
> |
> PositionOfShape
> / \
> Rectangle Circle
> \ /
> Properties
> - Color
> - Brush...
A design issue: a class named "Position of shape" should not be a parent of Rectangle/Circle. You may want to have Rectangle/Circle inherit from Shape, and have your properties (color, brush, positition, etc...) as members of Shape. You can have a collection of Shape that can either be Rectangle's or Circle's and invoke specific behaviours through polymorphism. A good question you should ask yourself is whether a Square should inherit from Rectangle or vice versa :)
Zaphod Beeblebrox
Mar 21, 2016, 7:36:37 AM3/21/16
to
On Monday, 21 March 2016 03:09:42 UTC, Jerry Stuckle wrote:
[..]
[..]
> I think your problem here is one of understanding. Inheritance is
> always a "type of" relationship - that is, both Rectangle and Circle are
> a "type of" shape.
To be fair, 'inheritance' and 'subclassing' are not necessarily the same concept, at least in theory (see "A Theory of Objects" by Cardelli-Abadi).
> always a "type of" relationship - that is, both Rectangle and Circle are
> a "type of" shape.
Zaphod Beeblebrox
Mar 21, 2016, 9:21:06 AM3/21/16
to
On Monday, 21 March 2016 07:01:42 UTC, Alf P. Steinbach wrote:
>a Circle can be a kind of
Ellipse, because it has all the properties of an Ellipse. It's just a
subset of ellipses. The other way doesn't work, because it's not the
case that every Ellipse or most Ellipses has exactly one radius.
Well, it's not that simple, IMO. I agree that circles can be considered subsets of eclipses, but the idea that a sub-type *restricts* the base type is not intuitive at all. It should be quite the opposite: the sub-type *extends* the base type. Therefore it is not wrong, IMO, to think of an eclipse as an *extension* of a circle, as it just extends a circle's contract.
>a Circle can be a kind of
Ellipse, because it has all the properties of an Ellipse. It's just a
subset of ellipses. The other way doesn't work, because it's not the
case that every Ellipse or most Ellipses has exactly one radius.
Jerry Stuckle
Mar 21, 2016, 9:42:16 AM3/21/16
to
Jerry Stuckle
Mar 21, 2016, 9:44:09 AM3/21/16
to
base class. For instance, Person->Employee->Manager. All Managers are
Employees and all Employees are Persons, but the other way does not work.
Zaphod Beeblebrox
Mar 21, 2016, 11:32:06 AM3/21/16
to
On Monday, 21 March 2016 13:44:09 UTC, Jerry Stuckle wrote:
[...]
[...]
> Actually, that is true. A derived class is a more specific case of the
> base class.
"More specific" does not mean that it *restricts* the contract. It's quite the opposite. An employee is a more specific case of a person but it "extends" the contract of a person by adding the "attribute" of being an employee. So does a Manager with respect to Employee. It is an extension, not a restriction.
> base class.
Zaphod Beeblebrox
Mar 21, 2016, 11:32:50 AM3/21/16
to
On Monday, 21 March 2016 13:42:16 UTC, Jerry Stuckle wrote:
[...]
[...]
> Nobody was talking about subclassing.
>Rectangle and Circle are a "type of" shape.
*YOU* are talking about subclassing.
Jerry Stuckle
Mar 21, 2016, 12:14:22 PM3/21/16
to
Jerry Stuckle
Mar 21, 2016, 12:17:20 PM3/21/16
to
to do with the attributes; the derived class may or may not have
additional attributes or it may hide attributes in the base class.
Zaphod Beeblebrox
Mar 21, 2016, 12:25:10 PM3/21/16
to
On Monday, 21 March 2016 16:14:22 UTC, Jerry Stuckle wrote:
[...]
[...]
> Nope, I'm talking about inheritance.
Okay, you need to make things clear in your mind and stop arguing just for the sake of it. If you say "Inheritance is always a 'type of' relationship", you are saying that inheritance is always sub-typing, therefore is always sub-classing.
Zaphod Beeblebrox
Mar 21, 2016, 12:33:08 PM3/21/16
to
On Monday, 21 March 2016 16:17:20 UTC, Jerry Stuckle wrote:
[...]
[...]
> More specific by definition means further restrictions.
"More specific", in the OO world, means that it has a specialized behaviour, it does NOT mean that restricts the base class' behaviour/contract. Indeed, no derived class may ever restrict a base class' behaviour because of the Liskov substitution principle. If a derived class 'is-a' base class, that means that it has to be *AT LEAST* a base class. A derived class never restricts, it always extends.
> It has nothing to do with the attributes; the derived class may or may not have
> additional attributes or it may hide attributes in the base class.
Alf P. Steinbach
Mar 21, 2016, 1:01:40 PM3/21/16
to
On 21.03.2016 14:20, Zaphod Beeblebrox wrote:
> On Monday, 21 March 2016 07:01:42 UTC, Alf P. Steinbach wrote:
>
>> a Circle can be a kind of
> Ellipse, because it has all the properties of an Ellipse. It's just a
> subset of ellipses. The other way doesn't work, because it's not the
> case that every Ellipse or most Ellipses has exactly one radius.
>
> Well, it's not that simple, IMO.
Zaphod is quoting out of context, and ignoring the context in his
> On Monday, 21 March 2016 07:01:42 UTC, Alf P. Steinbach wrote:
>
>> a Circle can be a kind of
> Ellipse, because it has all the properties of an Ellipse. It's just a
> subset of ellipses. The other way doesn't work, because it's not the
> case that every Ellipse or most Ellipses has exactly one radius.
>
> Well, it's not that simple, IMO.
simplistic argumentation.
That's typical trolling behavior and I think I recall the nick as a
well-known clc++ troll way back.
- Alf
Mr Flibble
Mar 21, 2016, 1:43:55 PM3/21/16
to
here; it follows that you are also incorrect and that I am actually correct.
/Flibble
Zaphod Beeblebrox
Mar 21, 2016, 1:50:25 PM3/21/16
to
On Monday, 21 March 2016 17:01:40 UTC, Alf P. Steinbach wrote:
[...]
> That's typical trolling behavior and I think I recall the nick as a
> well-known clc++ troll way back.
Huh?! What?!?!??
[...]
> Zaphod is quoting out of context, and ignoring the context in his
> simplistic argumentation.
Huh?! What are you talking about? I am not quoting out of context at all. Are you sure you got what I wrote?
> simplistic argumentation.
> That's typical trolling behavior and I think I recall the nick as a
> well-known clc++ troll way back.
Alf P. Steinbach
Mar 21, 2016, 1:52:19 PM3/21/16
to
On 21.03.2016 18:43, Mr Flibble wrote:
> On 21/03/2016 03:02, Jerry Stuckle wrote:
>> On 3/20/2016 1:36 PM, Mr Flibble wrote:
>>> On 20/03/2016 13:08, Victor Bazarov wrote:
>>>> On 3/20/2016 7:01 AM, Jens Kallup wrote:
>>>>> How can I create a C++ structure of classes:
>>>>>
>>>>> Shape
>>>>> |
>>>>> PositionOfShape
>>>>> / \
>>>>> Rectangle Circle
>>>>> \ /
>>>>> Properties
>>>>> - Color
>>>>> - Brush...
>>>>>
As I see it a/the reasonable interpretation of the original posting is
> On 21/03/2016 03:02, Jerry Stuckle wrote:
>> On 3/20/2016 1:36 PM, Mr Flibble wrote:
>>> On 20/03/2016 13:08, Victor Bazarov wrote:
>>>> On 3/20/2016 7:01 AM, Jens Kallup wrote:
>>>>> How can I create a C++ structure of classes:
>>>>>
>>>>> Shape
>>>>> |
>>>>> PositionOfShape
>>>>> / \
>>>>> Rectangle Circle
>>>>> \ /
>>>>> Properties
>>>>> - Color
>>>>> - Brush...
>>>>>
that there is no real diamond inheritance pattern. Victor's posting,
assuming diamond inheritance, appeared to be be made in haste, misled by
the very misleading figure. Such things happen. :/
Cheers!,
- Alf
Mr Flibble
Mar 21, 2016, 1:53:56 PM3/21/16
to
being the same; the circle class could hide some of ellipse base class
member functions (so only one radii can be set) but given it is-a
ellipse the circle class must override the radii set functions to ensure
that it remains a circle (setting one radii will set the other radii to
be the same) but it is doubtful that this behaviour satisfies the Liskov
Substitution Principle as an ellipse can have two different radii.
/Flibble
Wouter van Ooijen
Mar 21, 2016, 2:02:24 PM3/21/16
to
Op 21-Mar-16 om 6:53 PM schreef Mr Flibble:
Watch yourself Fibble, you are making sense and that worries me. Out of
sausages?
Actually modeling a circle this way as a specialized subtype of ellipse
totally violates Liskov, unless of course the ellipse makes no promises
about being able to represent all elipses.
Wouter
sausages?
Actually modeling a circle this way as a specialized subtype of ellipse
totally violates Liskov, unless of course the ellipse makes no promises
about being able to represent all elipses.
Wouter
Öö Tiib
Mar 21, 2016, 2:22:06 PM3/21/16
to
On Monday, 21 March 2016 19:50:25 UTC+2, Zaphod Beeblebrox wrote:
> On Monday, 21 March 2016 17:01:40 UTC, Alf P. Steinbach wrote:
>
> [...]
> > Zaphod is quoting out of context, and ignoring the context in his
> > simplistic argumentation.
>
> Huh?! What are you talking about? I am not quoting out of context at all. Are you sure you got what I wrote?
Yes, what you did looked indeed as contextomy. You cut his sentence.
> On Monday, 21 March 2016 17:01:40 UTC, Alf P. Steinbach wrote:
>
> [...]
> > Zaphod is quoting out of context, and ignoring the context in his
> > simplistic argumentation.
>
> Huh?! What are you talking about? I am not quoting out of context at all. Are you sure you got what I wrote?
That skewed the meaning of it. Then you replied to something that he
did not write. Do not do that since it is "informal fallacy" or when
put more strongly then it is a form of lying.
Jens Kallup
Mar 21, 2016, 2:51:28 PM3/21/16
to
Hello,
Thanks to all here in the group thread.
Please don't worry about, that i dont message you.
I found relevant documentation over virtual and
abstract classes virtual methods, ctor's and d'tors.
Also thanks to the tip with the Design.
It was not my homework :-) I am a little bit out of
date - a lazy 37 years old non-profit programmer.
More like a Hobbit.
I don't want to initial a flamewar, sorry.
When you spoke over collections - do you mean
containers? vectors?
Should I use -std-c++11 ? 14?
Is Linux gcc 4.9 to old?
Ok, I stop here - Questions over Questions :-)
TIA
Jens
Thanks to all here in the group thread.
Please don't worry about, that i dont message you.
I found relevant documentation over virtual and
abstract classes virtual methods, ctor's and d'tors.
Also thanks to the tip with the Design.
It was not my homework :-) I am a little bit out of
date - a lazy 37 years old non-profit programmer.
More like a Hobbit.
I don't want to initial a flamewar, sorry.
When you spoke over collections - do you mean
containers? vectors?
Should I use -std-c++11 ? 14?
Is Linux gcc 4.9 to old?
Ok, I stop here - Questions over Questions :-)
TIA
Jens
Jerry Stuckle
Mar 21, 2016, 3:12:41 PM3/21/16
to
talking about.
And you are the one who said there is a difference between inheritance
and subclassing. I use the term Inheritance as it is used in OOAD and
in C++.
Jerry Stuckle
Mar 21, 2016, 3:18:43 PM3/21/16
to
On 3/21/2016 12:32 PM, Zaphod Beeblebrox wrote:
> On Monday, 21 March 2016 16:17:20 UTC, Jerry Stuckle wrote:
>
> [...]
>> More specific by definition means further restrictions.
>
> "More specific", in the OO world, means that it has a specialized behaviour, it does NOT mean that restricts the base class' behaviour/contract. Indeed, no derived class may ever restrict a base class' behaviour because of the Liskov substitution principle. If a derived class 'is-a' base class, that means that it has to be *AT LEAST* a base class. A derived class never restricts, it always extends.
>
Wrong again. For instance, a Square is a type of Rectangle. However,
> On Monday, 21 March 2016 16:17:20 UTC, Jerry Stuckle wrote:
>
> [...]
>> More specific by definition means further restrictions.
>
> "More specific", in the OO world, means that it has a specialized behaviour, it does NOT mean that restricts the base class' behaviour/contract. Indeed, no derived class may ever restrict a base class' behaviour because of the Liskov substitution principle. If a derived class 'is-a' base class, that means that it has to be *AT LEAST* a base class. A derived class never restricts, it always extends.
>
it does limit the base class's behavior because drawing a Square
requires all four sides to be the same length. And a Rectangle will
have length and width, but a Square will only have size. The derived
class Square changes the behavior of the Rectangle class.
And the derived class can even overload functions such that the base
class function is no longer available nor is it invoked. For instance,
the Square class can overload Height and Width related get/set members
of the Rectangle class such that those functions are not used for a
Square class object.
>> It has nothing to do with the attributes; the derived class may or may not have
>> additional attributes or it may hide attributes in the base class.
>
> I am not talking about the class members. I used quotes around that noun. I am talking about 'the attribute of being an Employee'. You qualify a person as an "employee". This specializes a person and, at the same time, *extends* a person with the attribute of being an employee. So does a manager with regard to an employee. A person is a person. An employee is a person *AND* an employee. A manager is a person, *AND* an employee, *AND* a manager. Each sub-type extends the base type, though it gets more and more specialized.
>
Mr Flibble
Mar 21, 2016, 3:35:53 PM3/21/16
to
On 21/03/2016 19:18, Jerry Stuckle wrote:
> On 3/21/2016 12:32 PM, Zaphod Beeblebrox wrote:
>> On Monday, 21 March 2016 16:17:20 UTC, Jerry Stuckle wrote:
>>
>> [...]
>>> More specific by definition means further restrictions.
>>
>> "More specific", in the OO world, means that it has a specialized behaviour, it does NOT mean that restricts the base class' behaviour/contract. Indeed, no derived class may ever restrict a base class' behaviour because of the Liskov substitution principle. If a derived class 'is-a' base class, that means that it has to be *AT LEAST* a base class. A derived class never restricts, it always extends.
>>
>
> Wrong again. For instance, a Square is a type of Rectangle. However,
> it does limit the base class's behavior because drawing a Square
> requires all four sides to be the same length. And a Rectangle will
> have length and width, but a Square will only have size. The derived
> class Square changes the behavior of the Rectangle class.
Shall we play spot the logical fallacy?
> On 3/21/2016 12:32 PM, Zaphod Beeblebrox wrote:
>> On Monday, 21 March 2016 16:17:20 UTC, Jerry Stuckle wrote:
>>
>> [...]
>>> More specific by definition means further restrictions.
>>
>> "More specific", in the OO world, means that it has a specialized behaviour, it does NOT mean that restricts the base class' behaviour/contract. Indeed, no derived class may ever restrict a base class' behaviour because of the Liskov substitution principle. If a derived class 'is-a' base class, that means that it has to be *AT LEAST* a base class. A derived class never restricts, it always extends.
>>
>
> Wrong again. For instance, a Square is a type of Rectangle. However,
> it does limit the base class's behavior because drawing a Square
> requires all four sides to be the same length. And a Rectangle will
> have length and width, but a Square will only have size. The derived
> class Square changes the behavior of the Rectangle class.
Read a book mate.
[snip]
/Flibble
Jerry Stuckle
Mar 21, 2016, 3:47:53 PM3/21/16
to
> Read a book mate.
>
> [snip]
>
> /Flibble
And I'm not your mate.
Mr Flibble
Mar 21, 2016, 4:27:34 PM3/21/16
to
On 21/03/2016 19:47, Jerry Stuckle wrote:
> On 3/21/2016 3:35 PM, Mr Flibble wrote:
>> On 21/03/2016 19:18, Jerry Stuckle wrote:
>>> On 3/21/2016 12:32 PM, Zaphod Beeblebrox wrote:
>>>> On Monday, 21 March 2016 16:17:20 UTC, Jerry Stuckle wrote:
>>>>
>>>> [...]
>>>>> More specific by definition means further restrictions.
>>>>
>>>> "More specific", in the OO world, means that it has a specialized
>>>> behaviour, it does NOT mean that restricts the base class'
>>>> behaviour/contract. Indeed, no derived class may ever restrict a base
>>>> class' behaviour because of the Liskov substitution principle. If a
>>>> derived class 'is-a' base class, that means that it has to be *AT
>>>> LEAST* a base class. A derived class never restricts, it always extends.
>>>>
>>>
>>> Wrong again. For instance, a Square is a type of Rectangle. However,
>>> it does limit the base class's behavior because drawing a Square
>>> requires all four sides to be the same length. And a Rectangle will
>>> have length and width, but a Square will only have size. The derived
>>> class Square changes the behavior of the Rectangle class.
>>
>> Shall we play spot the logical fallacy?
>>
>
> No fallacy - excerpted from real code I've used over the years.
>
>> Read a book mate.
>>
>> [snip]
>>
>> /Flibble
>
> I would suggest you do so - but I know you can't read.
I suggest you start your learning by reading about the Liskov
> On 3/21/2016 3:35 PM, Mr Flibble wrote:
>> On 21/03/2016 19:18, Jerry Stuckle wrote:
>>> On 3/21/2016 12:32 PM, Zaphod Beeblebrox wrote:
>>>> On Monday, 21 March 2016 16:17:20 UTC, Jerry Stuckle wrote:
>>>>
>>>> [...]
>>>>> More specific by definition means further restrictions.
>>>>
>>>> "More specific", in the OO world, means that it has a specialized
>>>> behaviour, it does NOT mean that restricts the base class'
>>>> behaviour/contract. Indeed, no derived class may ever restrict a base
>>>> class' behaviour because of the Liskov substitution principle. If a
>>>> derived class 'is-a' base class, that means that it has to be *AT
>>>> LEAST* a base class. A derived class never restricts, it always extends.
>>>>
>>>
>>> Wrong again. For instance, a Square is a type of Rectangle. However,
>>> it does limit the base class's behavior because drawing a Square
>>> requires all four sides to be the same length. And a Rectangle will
>>> have length and width, but a Square will only have size. The derived
>>> class Square changes the behavior of the Rectangle class.
>>
>> Shall we play spot the logical fallacy?
>>
>
> No fallacy - excerpted from real code I've used over the years.
>
>> Read a book mate.
>>
>> [snip]
>>
>> /Flibble
>
> I would suggest you do so - but I know you can't read.
Substitution Principle.
/Flibble
Jerry Stuckle
Mar 21, 2016, 4:30:53 PM3/21/16
to
violates Liskov.
Mr Flibble
Mar 21, 2016, 4:42:33 PM3/21/16
to
Go read.
/Flibble
Jerry Stuckle
Mar 21, 2016, 9:08:52 PM3/21/16
to
people just how wrong you are - on so many different subjects.
Please feel free to continue to make a fool of yourself. You'll be
doing it without me.
Öö Tiib
Mar 22, 2016, 3:40:25 AM3/22/16
to
On Monday, 21 March 2016 20:51:28 UTC+2, Jens Kallup wrote:
> Hello,
>
> Thanks to all here in the group thread.
> Please don't worry about, that i dont message you.
> I found relevant documentation over virtual and
> abstract classes virtual methods, ctor's and d'tors.
>
> Also thanks to the tip with the Design.
> It was not my homework :-) I am a little bit out of
> date - a lazy 37 years old non-profit programmer.
> More like a Hobbit.
>
> I don't want to initial a flamewar, sorry.
You did not initiate flame war. Some typical communication patterns here.
> Hello,
>
> Thanks to all here in the group thread.
> Please don't worry about, that i dont message you.
> I found relevant documentation over virtual and
> abstract classes virtual methods, ctor's and d'tors.
>
> Also thanks to the tip with the Design.
> It was not my homework :-) I am a little bit out of
> date - a lazy 37 years old non-profit programmer.
> More like a Hobbit.
>
> I don't want to initial a flamewar, sorry.
>
> When you spoke over collections - do you mean
> containers? vectors?
viewpoint of that one. May be even raw array in C++.
>
> Should I use -std-c++11 ? 14?
> Is Linux gcc 4.9 to old?
also be worth trying but it is likely something that C++17 actually
won't never be.
Daniel
Mar 22, 2016, 12:58:59 PM3/22/16
to
On Monday, March 21, 2016 at 3:47:53 PM UTC-4, Jerry Stuckle wrote:
> On 3/21/2016 3:35 PM, Mr Flibble wrote:
> > On 21/03/2016 19:18, Jerry Stuckle wrote:
> >>
> >> ... a Square is a type of Rectangle. However,
> On 3/21/2016 3:35 PM, Mr Flibble wrote:
> > On 21/03/2016 19:18, Jerry Stuckle wrote:
> >>
> >> it does limit the base class's behavior because drawing a Square
> >> requires all four sides to be the same length. And a Rectangle will
> >> have length and width, but a Square will only have size. The derived
> >> class Square changes the behavior of the Rectangle class.
> >
> > Shall we play spot the logical fallacy?
>
> No fallacy - excerpted from real code I've used over the years.
>
The square-rectangle issue has been debated ad nauseam. Uncle Bob" agrees with Mr Flibble :-) More generally, a quick check with google suggests that so do most participants. Most participants find it unsatisfactory that sub-classing Rectangle forces Square to have two attributes when it needs one. And most participants find it unsatisfactory if Square has to violate a Rectangle contract to allow independent setting of width and height.
> >> requires all four sides to be the same length. And a Rectangle will
> >> have length and width, but a Square will only have size. The derived
> >> class Square changes the behavior of the Rectangle class.
> >
> > Shall we play spot the logical fallacy?
>
> No fallacy - excerpted from real code I've used over the years.
>
The reason it's debated rather than resolved once-for-all is that, Cardelli notwithstanding, OO is an ad hoc subject, it's not based on theory. OO has it's little principles, such as LSP, but they only go so far.
From the point of view of a class designer, nothing is actually gained from sub-classing Square from Rectangle. If there's a need for it, it's always possible to have an abstract base class for both, that defines common behaviour.
Daniel
Jerry Stuckle
Mar 22, 2016, 1:10:03 PM3/22/16
to
On 3/22/2016 12:58 PM, Daniel wrote:
> On Monday, March 21, 2016 at 3:47:53 PM UTC-4, Jerry Stuckle wrote:
>> On 3/21/2016 3:35 PM, Mr Flibble wrote:
>>> On 21/03/2016 19:18, Jerry Stuckle wrote:
>>>>
>>>> ... a Square is a type of Rectangle. However,
>>>> it does limit the base class's behavior because drawing a Square
>>>> requires all four sides to be the same length. And a Rectangle will
>>>> have length and width, but a Square will only have size. The derived
>>>> class Square changes the behavior of the Rectangle class.
>>>
>>> Shall we play spot the logical fallacy?
>>
>> No fallacy - excerpted from real code I've used over the years.
>>
> The square-rectangle issue has been debated ad nauseam. Uncle Bob" agrees with Mr Flibble :-) More generally, a quick check with google suggests that so do most participants. Most participants find it unsatisfactory that sub-classing Rectangle forces Square to have two attributes when it needs one. And most participants find it unsatisfactory if Square has to violate a Rectangle contract to allow independent setting of width and height.
>
And a lot of people disagree with Mr. Flibble. :) And Google is hardly
> On Monday, March 21, 2016 at 3:47:53 PM UTC-4, Jerry Stuckle wrote:
>> On 3/21/2016 3:35 PM, Mr Flibble wrote:
>>> On 21/03/2016 19:18, Jerry Stuckle wrote:
>>>>
>>>> ... a Square is a type of Rectangle. However,
>>>> it does limit the base class's behavior because drawing a Square
>>>> requires all four sides to be the same length. And a Rectangle will
>>>> have length and width, but a Square will only have size. The derived
>>>> class Square changes the behavior of the Rectangle class.
>>>
>>> Shall we play spot the logical fallacy?
>>
>> No fallacy - excerpted from real code I've used over the years.
>>
> The square-rectangle issue has been debated ad nauseam. Uncle Bob" agrees with Mr Flibble :-) More generally, a quick check with google suggests that so do most participants. Most participants find it unsatisfactory that sub-classing Rectangle forces Square to have two attributes when it needs one. And most participants find it unsatisfactory if Square has to violate a Rectangle contract to allow independent setting of width and height.
>
a reliable resource; many experts in the field don't bother posting in
forums and newsgroups because they rapidly get tired of the arguments
from know-it-alls.
But I'm not going to continue the argument here. There are too many
know-it-alls.
> The reason it's debated rather than resolved once-for-all is that, Cardelli notwithstanding, OO is an ad hoc subject, it's not based on theory. OO has it's little principles, such as LSP, but they only go so far.
>
either. It is based on theory and has principles such as encapsulation,
inheritance, etc. But it is not tightly standardized like programming
languages.
> From the point of view of a class designer, nothing is actually gained from sub-classing Square from Rectangle. If there's a need for it, it's always possible to have an abstract base class for both, that defines common behaviour.
>
to deal with GUIs. There can be a significant amount of code involved,
and only one small piece (the height/width) is different between the two.
> Daniel
Mr Flibble
Mar 22, 2016, 1:46:32 PM3/22/16
to
appear to be suffering from it.
/Flibble
Wouter van Ooijen
Mar 22, 2016, 1:52:22 PM3/22/16
to
Op 22-Mar-16 om 6:09 PM schreef Jerry Stuckle:
That smells of implementation sharing, which is commonly recognized as a
bad reason to use (public) inheritance.
Wouter
bad reason to use (public) inheritance.
Wouter
Richard
Mar 22, 2016, 1:58:14 PM3/22/16
to
[Please do not mail me a copy of your followup]
Jens Kallup <jka...@web.de> spake the secret code
<nclvtg$fbs$1...@gioia.aioe.org> thusly:
>How can I create a C++ structure of classes:
>
> Shape
> |
> PositionOfShape
> / \
>Rectangle Circle
> \ /
> Properties
> - Color
> - Brush...
What you want is composition, not inheritance.
You want a 'has-a' relationship, not an 'is-a' relationship.
A property is *not* a circle.
A property is *not* a rectangle.
A rectangle *has* properties.
A circle *has* properties.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Jens Kallup <jka...@web.de> spake the secret code
<nclvtg$fbs$1...@gioia.aioe.org> thusly:
>How can I create a C++ structure of classes:
>
> Shape
> |
> PositionOfShape
> / \
>Rectangle Circle
> \ /
> Properties
> - Color
> - Brush...
You want a 'has-a' relationship, not an 'is-a' relationship.
A property is *not* a circle.
A property is *not* a rectangle.
A rectangle *has* properties.
A circle *has* properties.
--
"The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline>
The Computer Graphics Museum <http://computergraphicsmuseum.org>
The Terminals Wiki <http://terminals.classiccmp.org>
Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>
Jerry Stuckle
Mar 22, 2016, 2:04:53 PM3/22/16
to
ROFLMAO!
Mr Flibble
Mar 22, 2016, 2:08:52 PM3/22/16
to
On 22/03/2016 17:58, Richard wrote:
> [Please do not mail me a copy of your followup]
>
> Jens Kallup <jka...@web.de> spake the secret code
> <nclvtg$fbs$1...@gioia.aioe.org> thusly:
>
>> How can I create a C++ structure of classes:
>>
>> Shape
>> |
>> PositionOfShape
>> / \
>> Rectangle Circle
>> \ /
>> Properties
>> - Color
>> - Brush...
>
> What you want is composition, not inheritance.
>
> You want a 'has-a' relationship, not an 'is-a' relationship.
>
> A property is *not* a circle.
> A property is *not* a rectangle.
>
> A rectangle *has* properties.
> A circle *has* properties.
It makes sense for properties such as Color and Brush to be part of the
> [Please do not mail me a copy of your followup]
>
> Jens Kallup <jka...@web.de> spake the secret code
> <nclvtg$fbs$1...@gioia.aioe.org> thusly:
>
>> How can I create a C++ structure of classes:
>>
>> Shape
>> |
>> PositionOfShape
>> / \
>> Rectangle Circle
>> \ /
>> Properties
>> - Color
>> - Brush...
>
> What you want is composition, not inheritance.
>
> You want a 'has-a' relationship, not an 'is-a' relationship.
>
> A property is *not* a circle.
> A property is *not* a rectangle.
>
> A rectangle *has* properties.
> A circle *has* properties.
Shape base class as presumably all Shapes have these properties.
There is a fundamental rule in OOA/D: prefer composition to inheritance.
/Flibble
Jerry Stuckle
Mar 22, 2016, 2:09:14 PM3/22/16
to
Jerry Stuckle
Mar 22, 2016, 2:25:15 PM3/22/16
to
applicable, and composition where applicable.
Mr Flibble
Mar 22, 2016, 2:38:39 PM3/22/16
to
problem with either inheritance or composition then prefer composition.
So we can currently conclude three things about Jerry Stuckle:
1) He is a troll;
2) He psychologically projects;
3) He is fractally wrong about most things C++ related.
/Flibble
Jerry Stuckle
Mar 22, 2016, 3:56:18 PM3/22/16
to
You use the one applicable for the situation. There is no "prefer" one
over the other.
> So we can currently conclude three things about Jerry Stuckle:
>
> 1) He is a troll;
> 2) He psychologically projects;
> 3) He is fractally wrong about most things C++ related.
>
> /Flibble
ignorant as to basic OOAD concepts.
Mr Flibble
Mar 22, 2016, 4:07:32 PM3/22/16
to
that is the nature of fractal wrongness.
/Flibble
Mr Flibble
Mar 22, 2016, 4:19:55 PM3/22/16
to
"Composition over inheritance (or Composite Reuse Principle) in
object-oriented programming is the principle that classes should achieve
polymorphic behavior and code reuse by their composition (by containing
instances of other classes that implement the desired functionality)
rather than inheritance from a base or parent class.[2] This is an
often-stated principle of OOP, such as in the influential Design
Patterns: "Favor 'object composition' over 'class inheritance'."[3]"
https://en.wikipedia.org/wiki/Composition_over_inheritance
Now do what I suggested earlier: read a book and actually learn something.
/Flibble
Jerry Stuckle
Mar 22, 2016, 4:46:11 PM3/22/16
to
idiot.
There is the truth, then there is Wikipedia. Occasionally they agree.
But most of the time Wikipedia is just someone's opinion - and you have
no idea just how knowledgeable that person is.
Composition is a "has-a" relationship. Inheritance is a "is-a"
relationship. Two entirely different concepts. But I know that's too
deep for your miniscule brain - as you've proven in this newsgroup over
and over again.
But hey - you're the expert in programming, OOAD, psychology - what
next, the Unified Field Theory?
Mr Flibble
Mar 22, 2016, 6:07:40 PM3/22/16
to
/Flibble
Öö Tiib
Mar 22, 2016, 7:13:07 PM3/22/16
to
> > And you quote wikipedia as a "trusted source"? No wonder you're such an
> > idiot.
> >
> > There is the truth, then there is Wikipedia. Occasionally they agree.
> > But most of the time Wikipedia is just someone's opinion - and you have
> > no idea just how knowledgeable that person is.
> >
> > Composition is a "has-a" relationship. Inheritance is a "is-a"
> > relationship. Two entirely different concepts. But I know that's too
> > deep for your miniscule brain - as you've proven in this newsgroup over
> > and over again.
> >
> > But hey - you're the expert in programming, OOAD, psychology - what
> > next, the Unified Field Theory?
>
> Your fractal wrongness continues unabated! I like consistency! :)
Seems that you two are exchanging too lot of ad hominems and signal to
> > idiot.
> >
> > There is the truth, then there is Wikipedia. Occasionally they agree.
> > But most of the time Wikipedia is just someone's opinion - and you have
> > no idea just how knowledgeable that person is.
> >
> > Composition is a "has-a" relationship. Inheritance is a "is-a"
> > relationship. Two entirely different concepts. But I know that's too
> > deep for your miniscule brain - as you've proven in this newsgroup over
> > and over again.
> >
> > But hey - you're the expert in programming, OOAD, psychology - what
> > next, the Unified Field Theory?
>
> Your fractal wrongness continues unabated! I like consistency! :)
noise is therefore rather low. Do you have fun?
That "composition over inheritance" is IMHO a mantra. It has a kernel
of good truth in it but that is turned into religious slogan. Religious
slogans are considered harmful.
Inheritance is fundamental to object oriented paradigm; composition is
fundamental to any software design paradigm. So inheritance is misused
lot more often than composition. We can not solve a OOP question if
square is kind of rectangle or not by uttering such religious slogans
and suggesting that rectangle is component of square. ;)
Jerry Stuckle
Mar 22, 2016, 7:38:37 PM3/22/16
to
rectangle is a more specific instance of a parallelogram. And that is a
more specific instance of a quadrilateral.
woodb...@gmail.com
Mar 22, 2016, 9:52:11 PM3/22/16
to
Brian
Ebenezer Enterprises
http://webEbenezer.net
Alf P. Steinbach
Mar 23, 2016, 12:25:02 AM3/23/16
to
On 23.03.2016 02:51, woodb...@gmail.com wrote:
>
> The national motto of the United States is "In G-d we trust."
The adoption of it as a national motto happened at the same time as
>
> The national motto of the United States is "In G-d we trust."
segregation was abolished. Which would place it around 1956, if memory
serves me right. Anyway you can google it.
I think it was a fair exchange at the time: adopt a lunatic national
motto, a motto which after all had appeared on flags and coins earlier,
but get rid of segregation − or at least a good start on that.
However, now with a black US President the time may have come to finally
get rid also of the since 1956 state-endorsed lunacy. The Founding
Fathers did not want that: they would have been shocked to know it was
adopted. Unfortunately it's been reaffirmed by voting many times in
recent years, and most Americans are in favor of it. :(
Cheers & hth.,
- Alf
Scott Lurndal
Mar 23, 2016, 9:35:29 AM3/23/16
to
woodb...@gmail.com writes:
>
>The national motto of the United states is
"Out of many, one" (act of congress, 1782).
>
>The national motto of the United states is
"Out of many, one" (act of congress, 1782).
Öö Tiib
Mar 23, 2016, 4:09:14 PM3/23/16
to
like "build a wall".
woodb...@gmail.com
Mar 23, 2016, 5:37:07 PM3/23/16
to
a posterboy for walls in terms of closed source. Without
that wall, I'd be left to the whims of "leaders" like Obama.
woodb...@gmail.com
Mar 23, 2016, 6:27:12 PM3/23/16
to
"In G-d we trust" goes back to 1956. It was on the money
long before that, though. Dennis Prager talks about the
"American Trinity" as being "Out of many, one", "In G-d we
trust," and liberty.
https://duckduckgo.com/?q=american+trinity+dennis+prager&t=h&ia=videos&iai=epXJ1SAa5ck
Öö Tiib
Mar 23, 2016, 9:14:10 PM3/23/16
to
needle pop into mind. Search engines suggest Matthew 19:24
0 new messages