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
overcomplicating the design.

Kind Regards

Merlin

 

[Mitchell]

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.

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.

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()...

"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.]

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.


"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.

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]

Mitchell wrote:

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.

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.

 

[Mark Nicholls]

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
overcomplicating the design.

Kind Regards

Merlin

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.