Skip to Content.
Sympa Menu

patterns-discussion - Re: [patterns-discussion] Combining Command, Composite, and Visitor

patterns-discussion AT lists.cs.illinois.edu

Subject: General talk about software patterns

List archive

Re: [patterns-discussion] Combining Command, Composite, and Visitor


Chronological Thread 
  • From: "Steven Newton" <cratermoon AT gmail.com>
  • To: patterns-discussion AT cs.uiuc.edu
  • Subject: Re: [patterns-discussion] Combining Command, Composite, and Visitor
  • Date: Sun, 5 Aug 2007 09:00:11 -0700
  • List-archive: <http://lists.cs.uiuc.edu/pipermail/patterns-discussion>
  • List-id: General talk about software patterns <patterns-discussion.cs.uiuc.edu>

On 8/3/07, James Siddle
<james.siddle AT uk.ibm.com>
wrote:
>
>
> What I'm struggling to know is how to introduce a "Visitable" interface onto
> the Command classes, without tying the Command interface to the Visitor
> interface. I've narrowed my choices to three options, so any guidance on
> which one to go for would be appreciated :-)
>
Do the concrete Command classes and the CompositeCommand classes
descend from a common base class? It sounds like not, so you're in a
bit of pickle. If they did, you could create the Visitable interface
and have the abstract base class implement a default 'accept' method,
and all the rest of the command classes would have it. I think some
might consider it a design smell if the base class behavior is empty,
but I don't see many other options. If the concrete command classes
have no common ancestor, but all directly implement the Command
interface, I think option 2 is probably the solution I'd go with, but
I'd put in place a means whereby the whole thing could migrate towards
a refactored design, perhaps though judicious use of deprecation.

s

--
It's actually a pretty big world,
it's just folded over on itself a lot.




Archive powered by MHonArc 2.6.16.

Top of Page