Applying multiple design paterns to a single class

[Orgun]

Hi,

I sent this message to the moderated c++ group too but it is
waiting for moderator approval and I wanted to send here too.

I am new to Design Patterns. I want to write a simple
DeviceManager which is only interested in CD/DVD devices. I want to get
the list of CD/DVD devices and "be informed when a disc inserted into a
device". I am developing this on Linux. So, I used HAL API and read
some system (actually /proc) files to gather required information.
Everything is OK so far. But, at the same time, I want to visualize
this information. I have a dialog which lists the CD/DVD devices and
according to the chosen device it shows the media it contains (says
empty if it has none) To visualize this information I need to notify
the GUI part. Therefore I decided to use "Observer" design pattern.
However, my DeviceManager must be a "Facade" to hide the implementation
details (because, in fact, I used another class to read those system
files). Worse, DeviceManager itself must be an "Observer" to get the
information from the HalHandler to be informed when a new media
inserted or removed.

GUI ("Observer" for DeviceManager)
I
I
Device manager ("Subject" for GUI, "Observer" for HALHandler and must
be "Facade" too)
/ \
/ \
FileOp HALHandler ("Subject" for DeviceManager)

My questions are as follows:

a) Is applying multiple design pattern to a single class
acceptable/normal or does it indicate a wrong design? Because, if I am
not wrong, applying two or more design pattern to a single class may
necessitate multiple inheritance (which might make everything much more
complex than expected)

b) If my design is problematic or wrong what would be the correct
solution/design? Any suggestions/ideas???

Thanks everybody in advance

 

[raxitsheth2000]

Orgun
comp.object is better place (for patterns) forwarding there,

raxit

 

[raxitsheth2000]

Sorry to repeat,
this is from comp.lang.c++ forwarding to comp.object,

 

[Ed]

(e-mail address removed) skrev:

Sorry to repeat,
this is from comp.lang.c++ forwarding to comp.object,

The only thing wrong with applying multiple design patterns to one
class is that it violates the somewhat nebulous, "Single Responsibility
Principle," that states that a class should do one thing and one thing
only.

Your alarm at impending complexity, however, seems more relevant. So I
personally would split the behaviour you describe across several
classes.

Firstly, are you using namespaces?

Secondly, as you already have a facade or sorts, why not run with it?
Why not have your facade - DeviceFacade - contain, for example, the
getDeviceNotificationSource() to return the class that will handle
forwarding notifications to observers, and getDeviceManager() to return
that class that can (I suppose) be interrogated for device information.

Similarly, I'd have a separate class within this namespace be reposible
for registering with the HAL and keeping the state of the devices it's
observing.

Importantly, have as few concrete classes visible outside the namespace
as possible - preferably just one: the DeviceFacade - and have only
abstract classes available for the other behaviour visible outside the
namespace (DeviceManager, for instace, should be abstract, and of
course the Observer class that you pass to the HAL will be abstract);
thus, you can decide how to assign behavioural responsibility within
the namespace as you wish, with minimal impacts on other namespaces
that depend on this behaviour.

..ed

 

[Orgun]

Sorry. I am new to groups too. Thanks



(e-mail address removed) yazdi:

 

[mehmetaliaksoy]

First of all, thank you very much for your reply. I am trying to
grab it completely at the moment.

I haven't started using namespaces yet but, I think, it's time


Your suggestions about getDeviceNotificationSource() and
getDeviceManager(), I think, the "pull model" described in GoF. Am i
wrong?

I already have a separate HALHandler class. Maybe I need
different Facade and Manager classes for convenience. Manager can use
HALHandler and can be interrogated, Facade supply an easy-to-use
interface for the device management job. I am not sure at the moment
but I will, soon.

Thanks again.


Orgun



Ed yazdi:

 

[H. S. Lahman]

Responding to Raxitsheth2000...

While there is nothing inherently wrong with chaining design patterns
together, it is suspicious in a single object. Thus there is nothing
wrong with the same object playing different subject/observer roles in
the implementation to two separate Observer patterns. But throwing in a
Facade as well seems a bit much. Here, my suspicions are further
aroused by the name "DeviceManager". All too often XxxManager or
XxxController class names are symptoms of god objects with too many
responsibilities or of higher level nodes in a functional decomposition.

So I am suspicious that there are more objects that abstract the notion
of 'device manager'. But before speculating on what they might be, I
would need to know more about what is being managed. For example, are
your reading and displaying disc content? Or is your application
limited to just providing a directory structure view?

I am also concerned about cohesion at the subsystem level. A GUI UI
would usually be in its own subsystem. That's because the
Window/Control paradigm is so unique. I would expect that to be the
case unless the UI is trivial. If the UI is in its own subsystem then
the subsystem interface provides a Facade to decouple its semantics from
the rest of the application.

I would apply a similar argument to FileOp if you need content from the
discs. That functionality is complex and unique enough to justify its
own subsystem where the level of abstraction is device driver reads and
writes. That would provide you will a Facade for that aspect.

I know nothing about HAL, but I assume that interface is pretty simple.
In that case you can use a HALHandler object that acts as a surrogate
for talking to the OS. That object would provide the same sort of
decoupling from the OS as a Facade would.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
(e-mail address removed)
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
(e-mail address removed) for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH