Re: OO and Extending (Was: Is Procedural Paradigm a basis of OO Paradigm?)

On 27 Mar, 12:44, ggro...@xxxxxxxxxxx wrote:
On Mar 27, 10:47 am, "Mark Nicholls" <Nicholls.M...@xxxxxxxxx> wrote:





On 26 Mar, 23:23, "topmind" <topm...@xxxxxxxxxxxxxxxx> wrote:
Mark Nicholls wrote:
you constantly nit picked and hopped around the issue, invoking
Oracle, relational and all sorts of other tangental
objections.....someone else talks about it and then you cite the
practicality of the OO approach, implicitly accepting the truth of the
claim.
Whats the point?
I am sorry, but I still don't know what you are talking about. I've
been in a lot of OO debates such that I mix my detractors all up. I
would suggest you label your evidence. Here is a sketchy example:
Code Example: "Lisa"
Description: asdfasdf asd asdf as df asdf...
OOP:
good.shiney(foo);
nice.good.friendly();
rab = new rainbows.and.butterflies();
etc...
Procedural/Relational:
bad(bloaty);
bloaty(bad + no_good);
if (bad) {hardToChange()};
etc...
Scenario 1:
User wants a new product with green lights that beeps every third
Friday.
OOP Changes:
foo.bar()....
P/R Changes:
asdfas().....
case(99)...
Scenario 2:
(etc.....)
To me, this is how you document superiority related to change
scenarios. At least give your evidence labels, and/or a date to search
by. (A wiki such as C2.com may be better for such.)
Your example code is nonsensical...and all of a sudden includes
relational...which is irrelevant (again).
OOP
void ProductActivate(Product product)
{
product.go();

}
procedural
void ProductActivate(Product product)
{
switch case (product.Name)
{
case "Foo1":
{
product.Beep();
}
case "Foo2":
{
product.Buzz();
}
....
....
..
}
}
etc
"User wants a new product with green lights that beeps every third
Friday."
OOP changes.....*none*!

procudural changes

switch case (product.Name)
{
case "Foo1":
{
product.Beep();
}
case "Foo2":
{
product.Buzz();
}
....
....
..
// ADDITIONAL code.
case "BeepEvery2ndFriday"
{
product.whateveritsawasteoftime();
}

There is an issue that you missed here : the Product type itself.

In a procedural programming language (C, Modula-2, old Ada etc) , the
Product
type will have to be the *union of all the data properties of all the
product
types* (variant records etc) .

Variant records are the most appalling form of stamp coupling known to
programming. Changing one data property of one product variant affects
everything that uses the Product type.

Regards,
Steven Perryman- Hide quoted text -

- Show quoted text -

I completely agree.

I was just trying to give a like for like version of topminds
example...i.e. the point being there is no change to the client
code....

.