| View previous topic :: View next topic |
| Author |
Message |
dotNeter
Guest
|
 Posted: Mon Mar 24, 2008 2:16 pm Post subject: how to encapsulate an entire system and then fit future chan |
 |
|
I have a GUI system and I'm gotta build a new system upon it. My
requirement is,
1. The new system will have a set of new interfaces, that means the
GUI system should be invisible to users.
2. The new system shouldn't simply wrap all interfaces, since some new
non-UI features would get added.
3. The underlying GUI system may entirely get substituted someday.
I'm trying to use the bridge pattern to design the system. I'm
planning to add a middle, totally abstract, system, which defines all
required interfaces, and definitely it should reflect all original
inheritance relationship between widgets. Sth like,
NewSystem -> AbstractSystem -> RealImplementedSystem
However, the problem is that, you know, the GUI system has lots of
different interfaces on different widgets, so that the abstract system
is hard to build. It should be only composed of pure abstract classes
in one inherited tree, which reflects the relationship between
widgets. Another problem is that even if I get this middle abstract
system, it would be a tough work to implement it. I gotta repeatedly
code so much similar interfaces which may just redirect the operation
to underlying real system.
Any other way for the design? Thx in advance. |
|
| Back to top |
|
 |
| |
Ads |
Advertising
Sponsor
|
|
H. S. Lahman
Guest
|
| Posted: Mon Mar 24, 2008 8:50 pm Post subject: Re: how to encapsulate an entire system and then fit future |
|
|
Responding to dotNeter...
| Quote: |
I have a GUI system and I'm gotta build a new system upon it. My
requirement is,
1. The new system will have a set of new interfaces, that means the
GUI system should be invisible to users.
2. The new system shouldn't simply wrap all interfaces, since some new
non-UI features would get added.
3. The underlying GUI system may entirely get substituted someday.
|
A lot depends on how well the legacy GUI is encapsulated. Assuming it is
well encapsulated, you might check out the "Application Partitioning"
category on my blog. Among other things it provides a generic two-way
interface model for subsystem communications.
| Quote: |
I'm trying to use the bridge pattern to design the system. I'm
planning to add a middle, totally abstract, system, which defines all
required interfaces, and definitely it should reflect all original
inheritance relationship between widgets. Sth like,
NewSystem -> AbstractSystem -> RealImplementedSystem
|
One might use the Bridge pattern *within* a GUI subsystem to manage
things like different implementations for different display
technologies. However, subsystems outside the GUI subsystem should not
know anything at all about what display paradigm is used, much less how
it is implemented. IOW, the external subsystems communicate with a
single interface, regardless of the display paradigm so there would be
no need for the Bridge pattern. (One might employ Facade for the
subsystem interface, though.)
| Quote: |
However, the problem is that, you know, the GUI system has lots of
different interfaces on different widgets, so that the abstract system
is hard to build. It should be only composed of pure abstract classes
in one inherited tree, which reflects the relationship between
widgets. Another problem is that even if I get this middle abstract
system, it would be a tough work to implement it. I gotta repeatedly
code so much similar interfaces which may just redirect the operation
to underlying real system.
|
Large, complex inheritance trees are generally not a good idea. They are
an inherently static structure that tends to be difficult to modify.
Essentially one has the Duck Billed Platypus problem when one tries to
insert a new class somewhere in the middle of the existing tree; often
it won't quite fit anywhere and one needs to reorganize the entire tree.
When one encounters large generalizations one should look for delegation
solutions where the monolithic tree can be broken up into multiple
smaller generalizations. Note that most of the GoF patterns use
delegation this way to avoid complex or combinatorial generalizations of
the Context object.
There really shouldn't be a problem with the interfaces. The interface
that the clients see should be designed around their needs to
communicate with the interactive user. That won't change if one is using
a GUI, web browser, or smoke signals for the user communication. IOW, it
is the job of the UI subsystem to convert the external client view of
communications into the display paradigm de jour without the clients
knowing anything about it.
It sounds like your legacy GUI subsystem is poorly encapsulated and
exposes too much about the way it is implemented in its subsystem
interface. In that case you will probably need a Facade-style wrapper
around the legacy GUI subsystem that does a proper job of capturing
display invariants. Then the implementation of that Facade can deal with
the conversion from the interface the clients want to see (i.e., the
Facade interface) and the hodge podge of interfaces the existing GUI
subsystem interfaces provide.
--
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
dotNeter
Guest
|
| Posted: Tue Mar 25, 2008 7:21 pm Post subject: Re: how to encapsulate an entire system and then fit future |
|
|
On Mar 24, 11:50 pm, "H. S. Lahman" <h...@pathfindermda.com> wrote:
| Quote: |
Responding to dotNeter...
I have a GUI system and I'm gotta build a new system upon it. My
requirement is,
1. The new system will have a set of new interfaces, that means the
GUI system should be invisible to users.
2. The new system shouldn't simply wrap all interfaces, since some new
non-UI features would get added.
3. The underlying GUI system may entirely get substituted someday.
A lot depends on how well the legacy GUI is encapsulated. Assuming it is
well encapsulated, you might check out the "Application Partitioning"
category on my blog. Among other things it provides a generic two-way
interface model for subsystem communications.
I'm trying to use the bridge pattern to design the system. I'm
planning to add a middle, totally abstract, system, which defines all
required interfaces, and definitely it should reflect all original
inheritance relationship between widgets. Sth like,
NewSystem -> AbstractSystem -> RealImplementedSystem
One might use the Bridge pattern *within* a GUI subsystem to manage
things like different implementations for different display
technologies. However, subsystems outside the GUI subsystem should not
know anything at all about what display paradigm is used, much less how
it is implemented. IOW, the external subsystems communicate with a
single interface, regardless of the display paradigm so there would be
no need for the Bridge pattern. (One might employ Facade for the
subsystem interface, though.)
However, the problem is that, you know, the GUI system has lots of
different interfaces on different widgets, so that the abstract system
is hard to build. It should be only composed of pure abstract classes
in one inherited tree, which reflects the relationship between
widgets. Another problem is that even if I get this middle abstract
system, it would be a tough work to implement it. I gotta repeatedly
code so much similar interfaces which may just redirect the operation
to underlying real system.
Large, complex inheritance trees are generally not a good idea. They are
an inherently static structure that tends to be difficult to modify.
Essentially one has the Duck Billed Platypus problem when one tries to
insert a new class somewhere in the middle of the existing tree; often
it won't quite fit anywhere and one needs to reorganize the entire tree.
When one encounters large generalizations one should look for delegation
solutions where the monolithic tree can be broken up into multiple
smaller generalizations. Note that most of the GoF patterns use
delegation this way to avoid complex or combinatorial generalizations of
the Context object.
There really shouldn't be a problem with the interfaces. The interface
that the clients see should be designed around their needs to
communicate with the interactive user. That won't change if one is using
a GUI, web browser, or smoke signals for the user communication. IOW, it
is the job of the UI subsystem to convert the external client view of
communications into the display paradigm de jour without the clients
knowing anything about it.
It sounds like your legacy GUI subsystem is poorly encapsulated and
exposes too much about the way it is implemented in its subsystem
interface. In that case you will probably need a Facade-style wrapper
around the legacy GUI subsystem that does a proper job of capturing
display invariants. Then the implementation of that Facade can deal with
the conversion from the interface the clients want to see (i.e., the
Facade interface) and the hodge podge of interfaces the existing GUI
subsystem interfaces provide.
--
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindermda.com
Pathfinder Solutionshttp://www.pathfindermda.com
blog:http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
i...@pathfindermda.com for your copy.
Pathfinder is hiring:http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
|
thanks Lahman.
Bridge is really not a good idea for my case, at least, it's not for
abstracting an entire layered system.
Currently I don't think it's not quite feasible to encapsulate entire
GUI system, since the users know they're using a GUI system and
originally I just wanna hide the legacy one.
Using Facade might be a good choice when I need to generalize or
change some interfaces.
btw, thanks for your blog posts, really nice. |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
112 Attacks blocked
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
