From: CTips on
Jeff Brooks wrote:
> CTips wrote:
>> topmind wrote:
>> <snip>
>> > OO is good for .... shapes.
>> Not really. Anytime someone comes up with the shapes example, ask them
>> how they would add the method:
>> class shape {
>> // true if object has any points in common with <B>
>> boolean intersects(shape B);
>> }
>> See how quickly mind-lock sets in....
> Model shapes as a series of lines/curves then test for intersections on
> the lines/curves that make up the shapes.
> This was really easy to solve?! Why do you think it's a problem?
> Jeff Brooks

Leaving aside the fact that you've ignored the problem of one shape
being "inside another", you've just moved the problem.

The problem is now: how would you add the method:
class curve {
// true if this curve intersects with <B>
boolean intersects(curve B);
to the class hierarchy of curves?
From: Jeff Brooks on
topmind wrote:

> Anyhow, you were the one bragging about how great polymorphism is, thus
> the burden is on YOU to "show". You are struggling to turn this all
> back on me when you are the problem here. Big Claims and Small Proof.

You make claims all the time and have no proof. You have never been able
to back up anything you have said.

Jeff Brooks
From: Isaac Gouy on
CTips wrote:
> Spent some time with the manual. From a _quick_ reading, it looks like
> the way its been written may still provide too much information. Try

//--- separate file
package test.hoop;
import test.shape;
void testIntersect(Shape s1, Shape s2){ s1.intersect(s2); }

//--- separate file
import test.shape;
import test.rectangle;
import test.intersect;
import test.hoop;

void main(String[] args){
let r = new Rectangle();
let c = new Circle();


We get the same compiler error message as before (if we comment out the
intersect definition in test.rectangle).

From: Robert C. Martin on
On Tue, 14 Jun 2005 17:19:49 GMT, "Phlip" <phlip_cpp(a)> wrote:

>Robert C. Martin wrote:
>> However, with OO, adding new functions to existing data structures is
>> hard. You have to find every subclass and add a new method.
>But you can do that incrementally, which a switch can't so easily do. You
>can add the new method as a default in the base class, test, deploy one
>specialization to one subclass, test, and keep going until nobody uses the
>default. Then you make it pure virtual and retire its stub implementation.

Yes, and you can add new data structures to switch statement
incrementally too. You just add one case at a time, and allow the
others to default. Same difference.

Robert C. Martin (Uncle Bob) | email: unclebob(a)
Object Mentor Inc. | blog:
The Agile Transition Experts | web:

"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
From: Thomas Gagne on
Robert C. Martin wrote:
> <snip>
> How do we represent these intersections as shapes? Topmind suggested
> that intersections be represented *as* intersections. i.e. we simply
> represent the resultant shape by storing the two intersecting shapes
> in a new derivative of Shape, perhaps called ShapeIntersection. (What
> remains, thereafter, is figuring out how to draw, calculate perimeter,
> calculate area, rotate, etc, etc, a ShapeIntersection.)

I hate to agree with him, but I love that idea. Additionally, I see no
problem figuring out how to calculate area, rotation, etc. Rotate both
shapes together -- maintaining their relationship together. If the
shapes overlap (instead of intersect) then each shape exists on its own
"layer". As many shapes as you want can "overlap" and it's then easy to
operate on the overlap -- its the area with the three shapes ANDed
together. There's no mystery shape needed to describe the intersection
'cause an intersection can describe itself with the help of the
intersecting (overlapping) shapes.
First  |  Prev  |  Next  |  Last
Pages: 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49
Next: Use Case Point Estimation