GOF Interface Problem

[Merlin]

Hi

For any of you that own a copy of GOF book, on page 38 there is a
class diagram showing the Glyph hierarchy. Two questions

Am I right to say that Image(or Graphic) would be another class that
should inherit from Glyph in order to follow from Fig 2.2 and Fig 2.3
on the previous page.

Secondly, why does Glyph have Insert() operation in its interface if
only some of the classes that inherit from it need this operation. The
interface for Glyph should be all the operations common to the classes
that derive from it. I have come across the ISP priciple by Robert C.
Martin that says this is a bad thing and designers should segregate
the interface and use multiple inheritance. The Glyph interface has
been polluted by Insert()...

If I am right then how can we resolve the issue without
overcomplicatin g the design.

Kind Regards

Merlin

[Mitchell]

Re: GOF Interface Problem

On 19 May 2004 11:20:16 -0700, merlin2769@hotm ail.com (Merlin) wrote:
[color=blue]
>Am I right to say that Image(or Graphic) would be another class that
>should inherit from Glyph in order to follow from Fig 2.2 and Fig 2.3
>on the previous page.[/color]

Anyway, this is OT. You might wish to try comp.object for more ideas.
I have helped to cross post to comp.object.

For example, page 38 says

"We can treat text and graphics uniformly with respect to how they are
drawn, formatted, and embedded within each other."

Page Page 36 says

"we should treat text and graphics uniformly"
"lets the user embed text within graphics freely and vice versa"

So yeah, I understand Image/Graphic as derived from Glyph.
[color=blue]
>Secondly, why does Glyph have Insert() operation in its interface if
>only some of the classes that inherit from it need this operation. The
>interface for Glyph should be all the operations common to the classes
>that derive from it. I have come across the ISP priciple by Robert C.
>Martin that says this is a bad thing and designers should segregate
>the interface and use multiple inheritance. The Glyph interface has
>been polluted by Insert()...[/color]

"lets the user embed text within graphics freely and vice versa"

So I understand they were planning to let you embed graphics in text,
thus the text glyphs (character, etc) will need the Insert method.

Also, since it is a hierarchy of classes, with only the classes at the
bottom of the hierachy being non-decomposable/not made up of other
glyphs, it makes sense to let classes all inherit from a base class
Glyph. Otherwise, different classes in the hierachy will need to
inherit from multiple different classes (so as to include and exclude
certain interfaces like Insert), creating a rather messy hierachy.

Cheers

[Daniel T.]

Re: GOF Interface Problem

In article <j8vfb0pdr7p0fs 2a9uonchug70tf1 48dm6@4ax.com>,
Mitchell <cheeliang_@_in ame_._com> wrote:
[color=blue]
>On 19 May 2004 11:20:16 -0700, merlin2769@hotm ail.com (Merlin) wrote:
>[color=green]
>>Am I right to say that Image(or Graphic) would be another class that
>>should inherit from Glyph in order to follow from Fig 2.2 and Fig 2.3
>>on the previous page.[/color]
>
>Anyway, this is OT. You might wish to try comp.object for more ideas.
>I have helped to cross post to comp.object.
>
>For example, page 38 says
>
>"We can treat text and graphics uniformly with respect to how they are
>drawn, formatted, and embedded within each other."
>
>Page Page 36 says
>
>"we should treat text and graphics uniformly"
>"lets the user embed text within graphics freely and vice versa"
>
>So yeah, I understand Image/Graphic as derived from Glyph.
>[color=green]
>>Secondly, why does Glyph have Insert() operation in its interface if
>>only some of the classes that inherit from it need this operation. The
>>interface for Glyph should be all the operations common to the classes
>>that derive from it. I have come across the ISP priciple by Robert C.
>>Martin that says this is a bad thing and designers should segregate
>>the interface and use multiple inheritance. The Glyph interface has
>>been polluted by Insert()...[/color]
>
>"lets the user embed text within graphics freely and vice versa"
>
>So I understand they were planning to let you embed graphics in text,
>thus the text glyphs (character, etc) will need the Insert method.
>
>Also, since it is a hierarchy of classes, with only the classes at the
>bottom of the hierachy being non-decomposable/not made up of other
>glyphs, it makes sense to let classes all inherit from a base class
>Glyph. Otherwise, different classes in the hierachy will need to
>inherit from multiple different classes (so as to include and exclude
>certain interfaces like Insert), creating a rather messy hierachy.[/color]

I don't think this is a good idea. What does it mean to insert a glyph
into, say, a Rectangle, or a Character? Glyph should only have methods
that *all* sub-types can implement (even if it is a null
implementation. ) 'Insert' is not such a method.

[Phlip]

Re: GOF Interface Problem

Daniel T. wrote:
[color=blue]
> Mitchell wrote:[/color]
[color=blue][color=green]
> >"lets the user embed text within graphics freely and vice versa"
> >
> >So I understand they were planning to let you embed graphics in text,
> >thus the text glyphs (character, etc) will need the Insert method.
> >
> >Also, since it is a hierarchy of classes, with only the classes at the
> >bottom of the hierachy being non-decomposable/not made up of other
> >glyphs, it makes sense to let classes all inherit from a base class
> >Glyph. Otherwise, different classes in the hierachy will need to
> >inherit from multiple different classes (so as to include and exclude
> >certain interfaces like Insert), creating a rather messy hierachy.[/color]
>
> I don't think this is a good idea. What does it mean to insert a glyph
> into, say, a Rectangle, or a Character? Glyph should only have methods
> that *all* sub-types can implement (even if it is a null
> implementation. ) 'Insert' is not such a method.[/color]

Guys, take the GOF book, and take out the "word processor" sample
application. Now put in an application which you thought of. That
application must show every pattern, and use only familiar and accessible
concepts.

The OP has detected a point where the "word processor" sample application
may fall down. There may be more. However, the ultimate arbiter would be the
actual implementation of this hypothetical application.

--
Phlip

http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces

[Mark Nicholls]

Re: GOF Interface Problem

> Hi[color=blue]
>
> For any of you that own a copy of GOF book, on page 38 there is a
> class diagram showing the Glyph hierarchy. Two questions
>
> Am I right to say that Image(or Graphic) would be another class that
> should inherit from Glyph in order to follow from Fig 2.2 and Fig 2.3
> on the previous page.
>
> Secondly, why does Glyph have Insert() operation in its interface if
> only some of the classes that inherit from it need this operation. The
> interface for Glyph should be all the operations common to the classes
> that derive from it. I have come across the ISP priciple by Robert C.
> Martin that says this is a bad thing and designers should segregate
> the interface and use multiple inheritance. The Glyph interface has
> been polluted by Insert()...
>
> If I am right then how can we resolve the issue without
> overcomplicatin g the design.
>
> Kind Regards
>
> Merlin[/color]

If I've got the right end of the stick, if you refer to page 166 of
the implementation section for composite it discusses the tradeoffs,
safety v transparency, of declaring Insert in the base component class
or not, GoF "emphasize transparency over safety" in the examples.