Re: Pattern Question
- From: "Russ" <russell@xxxxxxxxxxxxx>
- Date: 28 Nov 2006 06:11:05 -0800
Let me explain a little more.
Internally we are using a builder to build the actual instance of
object. The discussion of the plug-in vs registry is a step high on the
view. Meaning it contains a builder and a number of other components.
We are building a toolset that at runtime determines what type to build
based on a configuration data and returns a initialized object. At
first glance it sounds more like a plug-in then a registry.
Heres is my problem. The Plug-in model says that the plugin should not
have any compile time links. I understand the principle of programming
to interfaces but that is not what is needed 100% of the time. I
understand that a big part of what we are doing will be based on
implementing interfaces. The problem is that we will also allow
inheritance as well. So objects built may not only implement a
particular interface but may be sub-class of the requested type. This
seems to break the plug-in pattern.
Registry pattern doesn't have the same issue about compile time linking
so it seems to fit that way. In turn the registry pattern seems to more
focus on getting back long lasting types not building new instances of
types.
The real question is not how to achieve the end result the real issue
is in naming. One focus of mine as of late has been to improve our
naming. Instead of just taking what sounds good internally I want to
name based on some type of standard, in hopes of others understanding
easier what we do.
Nick Malik [Microsoft] wrote:
Let me understand:
You are creating an abstraction whereby the actual type to be used in an
implementation is decided seperately from the use of the type. OK. Sounds
like very simple abstraction. Class Factory and simple inheritance.
Plug in and Registry both assume that the implementing object is compiled
seperately from the object that uses it, and that you use a bit of
redirection to find the proper implementation. However, it sounds like you
Don't want that... you want to decide at compile time, or at best, at run
time. That sounds like the Factory Method pattern.
It's almost too easy of an answer. I must be missing something. If I
misunderstood (quite likely), please provide more details. In a nutshell,
attempt to answer this design question: what is the reason you are adding
indirection in this case?
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
<russell@xxxxxxxxxxxxx> wrote in message
news:1164645191.427647.190820@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I am having a discussion with someone in my office about two patterns.
plug-in and registry.
What we are building is a global definition of what type to use in a
particular implementation. This makes it sound like a good match to
plug-in but here is my problem. The way we are doing it allows for the
particular implementations to inherit from each other. In fact core
product types can be replaced via this definition for a particular
implmentation.
My concern with plug-in is that it in the Patterns book I am using
(Martin Fowler's Patterns of Enterprise Application Architecture) talks
about a plug-in pattern as Linking types at configuration time not
compile time. What we are doing does not support the abstraction of
no compile time linking. Is that big enough to though it out of the
pattern?
Registry somewhat imples that you are accessing existing instances of
types. If we are mainly building new instances does that violate that
pattern too.
What you would call the application component defined above?
.
- References:
- Pattern Question
- From: russell
- Re: Pattern Question
- From: Nick Malik [Microsoft]
- Pattern Question
- Prev by Date: Re: Pattern Question
- Next by Date: Re: Auto selection
- Previous by thread: Re: Pattern Question
- Index(es):
Relevant Pages
|
