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

Mark Nicholls wrote:
On 27 Mar, 16:26, "topmind" <topm...@xxxxxxxxxxxxxxxx> wrote:
On Mar 27, 5:10 am, "Mark Nicholls" <Nicholls.M...@xxxxxxxxx> wrote:





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....- Hide quoted text -

- Show quoted text -

In the real world you don't model products as sub-types (is-a). It
does not scale.

what if it doesn't need to scale?

If it will stay small and *not* change, then the difference between OO
and procedural will not matter much: no new conditions nor new method/
classes. OO'ers brags about handling new requirements and "large
applications". If you are changing what OO allegedly helps, then
please state so.


You model them as having a SET of features.

so you implement this in OO....you still *don't* need to change the
source code, you just iterate through the features (that implement a
common supertype) and invoke the behaviour on that.

I would like to see a fuller example which assumes that product info
is stored in a RDBMS, because even if you use OOP for the app-side,
most of the product info will be stored in a RDBMS in the real world.
Thus, you have to translate feature tablized lists into instantiated
objects. Showing the just post-instantiated objects is not showing a
lot of RDB-to-OO translation issues.



This is just another cop out, you don't like the example so move the
goal posts.

I don't know what you are talking about. What moved? Your example was
not realistic, so I made it more realistic. If being more real is a
"copout", then I am indeed guilty. OO is better for toy examples?
woopee doo. I won't even dispute that. (The "green light gizmo"
example was not meant to be an exactual scenario of mine, but to
illustrate a PRESENTATION of evidence. If that is what you are fussing
about.)


You assume
the features can be independent of one another such that you can add
new ones or remove old ones without affecting other features
(validation is used to flag non-permitted feature combo's). OO's
techniques tend to overcouple features. The actual tracking of which
product has which features is done in tables. This allows one to
decouple the code from domain classifications/taxonomies. Entity
taxonomies in code is BAD DESIGN.

depends on context....

It another example of 'nay saying'.

As a general rule, I find it to be true. Code is complex enough
without sticking noun taxonomies into code. And databases handle
managing those better because you can search, sort, edit, and report
on them easier. Code is too stiff and hard-to-read for such.



Then the code tends to resemble:

doSomething(p) {
if (p.hasFeatureX) {.....}
if (p.hasFeatureY) {
....
if (p.hasFeatureZ Or p.hasFeatureR) {
....
}
}
....

}

how about

foreach feature in a.features
{
feature.Foo();
}


How are these related to products? You didn't show that. If there was
a nice clean pattern, I would use a Control Table something like:

table: featureProcesses
---------
featureRef // foreign key to Feature table
taskRef // foreign key to Task table
function // function name or actual code snippet to execute

However, this usually doesn't work well in practice because there is
usually not enough regularity for this to work nicely, and it is hard
to factor commonailities together. Thus, the pattern I showed works
better in practice.



!

look still no client changes!

If there is the regularly you falsely assume, then the above table
would be an even nicer solution than your objects. Plus, you didn't
show the mapping of DB info into your objects. You seem to be assuming
Bubble Memory or the like (an OODBMS of sorts).



This is an oversimplification, but my code does tend to look this way.

mines a simplification too...but much of my code looks like that.


I will agree that all the interweaving feature conditionals can be
messy. But, I've never ever seen an OO'er successfully make it cleaner
without making unrealistic assumptions. Issues to consider:

see above, OO is not inconsistent with 'set' based approaches, being
able to have 2 ways to skin the cat is better than 1.

OO does not do sets better than relational. It just makes you have to
reinvent a lot of wheels because OO does not do it natively. And there
are off-the-shelf tools to query, report, edit, etc. tables. There is
more standardization between RDBMS than OOP languages.



1. Each routine/task tends to use different features because different
features tend to affect them. In other words, the pattern of which
task uses which feature tends to be somewhat random.

2. Feature selection may involve features of multiple entities. For
example, discounts may not only be affected by the product category,
but also by the nature (attributes of) the purchaser. Thus, we cannot
focus on just one entity when formulating a solution.

If you have the magic OO pattern to solve this, here is your chance to
be a herOO...

it can only be so simple, and no simpler.....there is no magic
anywhere.

I still don't change the client code on extension, which is the only
'magic' I claimed, you disputed, I gave up, you accepted, I come back,
you move the goal posts again.


See above about "moving goal posts". Note that in the real world they
*do* move. It is called "handling changes in requirements gracefully".
That is a key issue here.

-T-

.

Quantcast