Is this an instance of the Observer pattern ?
Hi,
I am very new the Design Patterns way of thinking about architectures.
This is for a school project, for my Designing with Design Patterns class
and we use the Gang Of Four book as the text.
The posting is a bit lengthy, please bear with me.
I am given the design (a Rational rose mdl) for an electronic library system.
I am to find a design issue and fix it using desing patterns.
Currently there are 2 kinds of repositories in the picture.
1. DB of Digital Documents
2. DB of Non-Digital Documents.
I'm concentrating on just the search part of the system.
There is mention in the requirements about being able to use the
electronic library.
Also I envision "search" needing to span repositories of audio/video content,
databases of recorded lectures and such .. in short - I expect
need to include databases other than the two mentioned above.
Currently, there is tight coupling between an application
and the databases. The Search Class directly calls 2 classes that implement the
application's interactions with the databases.
I want to uncouple this such that the system will be minimally impacted
when there is a need to add another repository into the mix.
So I want to restructure things so that repositories can sort of
plug onto the system and once plugged in, a search operation will
search the new repository also.
For this objective, this is what I'm thinking ..
[Refering to Observer pattern in the GOF book pg 293 - 303]
RepositoryServiceProvider - abstract class (Subject -- in the Observer pattern)
SearchServiceProvider subclass of RepositoryServiceProvider (Concrete Subject)
SearchAgent - abstract class (Observer)
NonDigDocSearchAgent(ConcreteObserver) and
DigDocSearchAgent(ConcreteObserver),
register their classes with the SearchServiceProvider.
Then , every new search query from the user, will result in the
a) creation of a SearchServiceProvider instance (serviceProvider),
b) followed by creation of instances of agents (searchAgents), for all registered search agent classes
c) ServiceProvider instance calls a notify() on each of the search agent instances
d) The search agents get the search query from the serviceProvider in their getState() method
d) The agents do the search in the respective repositories and return results to the SearchServiceProvider instance.
e) The SearchServiceProvider instance aggregates the results from each of the search agents
and returns the result set to the client object.
Can I call this an instance of the Observer pattern ?
Considering that part of it being used are :
i) Subject and observers are loosely coupled.
ii) Subject will be able to notify and recieve search results
from any new repository that may be added.
But,
The ConcreteSubject and the ConcreteObservers are created with every new search query and destroyed at the end of it
and not single instances of each, as the Pattern description in the book seems to indicate.
Thanks for reading.
Your time & help is greatly appreciated :).
Thanks,
Suma
[3318 byte] By [
sumabhata] at [2007-10-3 1:38:50]
> Hi,
>
> I am very new the Design Patterns way of thinking
> about architectures.
>
> This is for a school project, for my Designing with
> Design Patterns class
> and we use the Gang Of Four book as the text.
Oh, my.
I'm not sure I'd call GoF patterns "architecture". They talk about MVC, which is as close as they get to overall application architecture.The others are recommended approaches to solving more localized problems in an application.
> The posting is a bit lengthy, please bear with me.
> I am given the design (a Rational rose mdl) for an
> electronic library system.
> I am to find a design issue and fix it using desing
> patterns.
Rational Rose? You go to a well-funded school.
> Currently there are 2 kinds of repositories in the
> picture.
> 1. DB of Digital Documents
> 2. DB of Non-Digital Documents.
Seems strange that there have to be separate databases. I can see a single schema with different tables for the two types, with foreign keys into a DOCUMENTS table. But I'm betting that's not your issue.
> I'm concentrating on just the search part of the system.
>
> There is mention in the requirements about being able
> to use the electronic library.
> Also I envision "search" needing to span repositories
> of audio/video content,
> databases of recorded lectures and such .. in short -
> I expect
> need to include databases other than the two
> mentioned above.
>
> Currently, there is tight coupling between an
> application
> and the databases. The Search Class directly calls 2
> classes that implement the
> application's interactions with the databases.
What's "tight" about that? You've got to access the database sometime. If you reduce the coupling to zero, you can't query the database. This sounds like good layering to me. At least the database code is isolated in a well-defined persistence layer.
> I want to uncouple this such that the system will be
> minimally impacted
> when there is a need to add another repository into
> the mix.
You can't uncouple it without eliminating the database altogether.
> So I want to restructure things so that repositories
> can sort of
> plug onto the system and once plugged in, a search
> operation will
> search the new repository also.
That's not uncoupling them. I'm not sure what pattern we're talking about, but you're not reducing the coupling.
> For this objective, this is what I'm thinking ..
> [Refering to Observer pattern in the GOF book pg 293
> - 303]
> RepositoryServiceProvider - abstract class (Subject
> -- in the Observer pattern)
> SearchServiceProvider subclass of
> RepositoryServiceProvider (Concrete Subject)
>
> SearchAgent - abstract class (Observer)
> NonDigDocSearchAgent(ConcreteObserver) and
> DigDocSearchAgent(ConcreteObserver),
> register their classes with the
> SearchServiceProvider.
>
> Then , every new search query from the user, will
> result in the
> a) creation of a SearchServiceProvider instance
> (serviceProvider),
> b) followed by creation of instances of agents
> (searchAgents), for all registered search agent
> classes
> c) ServiceProvider instance calls a notify() on each
> of the search agent instances
> d) The search agents get the search query from the
> serviceProvider in their getState() method
> d) The agents do the search in the respective
> repositories and return results to the
> SearchServiceProvider instance.
> e) The SearchServiceProvider instance aggregates the
> results from each of the search agents
>and returns the result set to the client object.
> an I call this an instance of the Observer pattern ?
No, I don't think this is Observer.
I do think it's classic "small boy with a pattern" syndrome. You're trying to force Observer into a situation where it's not appropriate.
> Considering that part of it being used are :
> i) Subject and observers are loosely coupled.
> ii) Subject will be able to notify and recieve search
> results from any new repository that may be added.
>
>But,
> The ConcreteSubject and the ConcreteObservers are
> created with every new search query and destroyed at
> the end of it
> and not single instances of each, as the Pattern
> description in the book seems to indicate.
>
> Thanks for reading.
> Your time & help is greatly appreciated :).
>
> Thanks,
> Suma
The Observer pattern would be worthwhile if you were in an eager loading situation: a new repository comes on-line, and every agent wants to be notified about that fact so they can update their information. Sounds elegant, right? Until you realize that loading all that data into memory will kill your system for no good reason.
It's more likely that your users will want lazy loading - only bring back the information that I need right now. And if they issue a query that could bring back millions of hits, a la a Google search, only bring back summaries 25 at a time. Let the user navigate though the result set from front to back, because the algorithm makes it likely that that they really want is on the first few results
I might not be understanding your problem completely, and if that's true I'll apologize and try again. But I don't think Observer is only the solution to this problem. I'm not even sure that you've identified the problem correctly.
Do some research into the Data Access Object pattern.
Also, give a look at Martin Fowler's "Patterns of Enterprise Application Architecture". It takes a broader view of enterprise architecture than GoF.
GoF is a landmark book, the first word on patterns, but it's not the last word.
%
Thanks for replying :) I truly appreciate your taking the time.
My project requires me to find a problem with given system architecture,
with respect to an '*ility' and propose a solution to it, that incorporates
a creational, structural and a behavioral pattern.
So although it maybe an extreme case of overengineering and
showing of the symptom you mentioned, I just have to use "aleast one"
instance of each kind of design patterm in my solution as an *academic*
excercise.
Also, I am probably showing symptoms of the "small boy with a pattern" since
the ideas in the text book have gotten me thinking about problem solutions in
a new way, albeit not a very refined one yet.
Also in my previous post I meant *loosely couple*, when i said "uncouple"
- my bad.
Anyway .. continuing with the problem... i am saying that with respect to
maintainability if we can have a structure with some semblance of plug and play,
it would be really easy to create search agents for other repositories that may
come along in the future(this is a hypothetical future requirement, which imho
is not too far fetched which is the basis of my problem statement).
They could be incorporated in the system, atleast for
just the search, all one would need is a search agent that can search the new
database or repository of any kind (maybe another library system).
I didnt mention .. there are classes all over the place that use the the
DigDocDBAdapter and NonDigDocDBAdapter. So if there were to be XYZDocDBAdapter
there are more than 7 unrelated classes that need to change overall.
So my proposed solution has me using
a bridge pattern to separate the RepositoryService abstraction from the
RepositoryServiceProvider Implementor,
a ProviderFactory that gets the RepositoryService the instance of the Search
service provider (concrete implementor),
with the search service provider also being a subject for the various search
agents(observers) that conceptually wait to be notified of a new search query
which they all execute and get back to their subject with the search results.
Also, proposing the possibility that other existing services such as Locate,
Order etc, hang off of this structure(but is beyond the scope of my project)
So does a loose interpetation of a solution provided by a Design Pattern ..
qualify to be called an "instance of the design pattern" or .. an "adaptation
of a design pattern" or .. "design pattern allotrope?" (I read that someplace on the blogworld) ?
Thanks,
Suma
I'd like your thoughts on my previous post pls.Also will take a look at th Data Access Object pattern and the "Patterns of Enterprise Application Architecture" book.Thanks in advance,-Suma
> Thanks for replying :) I truly appreciate your taking the time.
And I appreciate your well-mannered response.
>
> My project requires me to find a problem with given
> system architecture,
> with respect to an '*ility' and propose a solution to
> it, that incorporates
> a creational, structural and a behavioral pattern.
>
> So although it maybe an extreme case of
> overengineering and
> showing of the symptom you mentioned, I just have to
> use "aleast one"
> instance of each kind of design patterm in my
> solution as an *academic*
> excercise.
We were all students once. (I still consider myself one.)
> Also, I am probably showing symptoms of the "small
> boy with a pattern" since
> the ideas in the text book have gotten me thinking
> about problem solutions in
> a new way, albeit not a very refined one yet.
I don't mean it as perjorative. Everyone who has read the GoF book for the first time has fallen prey to it. I have myself.
> Also in my previous post I meant *loosely couple*,
> when i said "uncouple"
> - my bad.
OK, now we agree.
> Anyway .. continuing with the problem... i am saying
> that with respect to
> maintainability if we can have a structure with some
> semblance of plug and play,
> it would be really easy to create search agents for
> other repositories that may
> come along in the future(this is a hypothetical
> future requirement, which imho
> is not too far fetched which is the basis of my
> problem statement).
> They could be incorporated in the system, atleast for
>
> just the search, all one would need is a search agent
> that can search the new
> database or repository of any kind (maybe another
> library system).
>
> I didnt mention .. there are classes all over the
> place that use the the
> DigDocDBAdapter and NonDigDocDBAdapter.
What exactly are these doing? What do their interfaces look like? That would be a good clue. Do they have a common interface or abstract superclass?
> So if there
> were to be XYZDocDBAdapter
> there are more than 7 unrelated classes that need to
> change overall.
Oh, my.Sounds like a redesign is necessary.
> So my proposed solution has me using
> a bridge pattern to separate the RepositoryService
> abstraction from the
> RepositoryServiceProvider Implementor,
> a ProviderFactory that gets the RepositoryService the
> instance of the Search
> service provider (concrete implementor),
> with the search service provider also being a subject
> for the various search
> agents(observers) that conceptually wait to be
> notified of a new search query
> which they all execute and get back to their subject
> with the search results.
I'd start by thinking about the problem in terms of abstract types or interfaces. Don't worry about the DB type or digital versus non-digital. Think about what needs to be done and let polymorphism take care of the rest.
It sounds like you'd like to decouple the search methodology from how the search is performed. Digital versus non-digital sounded like two different schemas. You'd like to be able to let clients describe what they want to an agent in somewhat general terms, using some Criteria, and then let the agent figure out how to get it. Is that a fair description? It's hard to comment, because I have neither the word description nor the UML in front of me.
I'm wondering if Visitor might be a more appropriate pattern. (You can also Google for it under the pseudonym "double dispatch" or "multiple dispatch".) Agents and DataSources might be involved, with Agent as the Visitor and DataSource being the Visitable.
> Also, proposing the possibility that other existing
> services such as Locate,
> Order etc, hang off of this structure(but is beyond
> the scope of my project)
>
> So does a loose interpetation of a solution provided
> by a Design Pattern ..
> qualify to be called an "instance of the design
> pattern" or .. an "adaptation
> of a design pattern" or .. "design pattern
> allotrope?" (I read that someplace on the blogworld)
Patterns are just someone else's distilled experience: "This kind of solution has worked well to help solve this kind of problem in the past." If you can adapt it to your particular situation, I'd say that's perfectly correct.
"allotrope" - I like it. Nice term.
If you don't think this is helpful, please provide more detail and I'll try to comment more. Perhaps someone else more knowledgable than me can jump in, too.
%
Thanks a ton for giving me the direction, I'm using teh visitor pattern. It does fit more nicely.Regards,Suma
