在这种情况下如何应用oo设计模式？

Question

Situation: Suppose we're designing the UI of Windows 9 using Java API. We need to build up 3 classes main , BuildInWindow and ApplicationWindow .

main - the window for rendering the system UI (ie the start botton & wallpaper page)

BuildInWindow - windows for rendering buildt-in apps (eg IE)

ApplicationWindow - windows for rendering apps from third party (eg eclipse)

all of them have to implement 3 Java API interfaces, WindowFocusListener , WindowListener and WindowStateListener and have the methods onExit() and onCrushing() .

onExit() performs when the system/built-in app/ third-party app is shut down normally

onCrushing() captures any system/application crush and send system state back to server

This is the original design:

http://i.stack.imgur.com/JAJiY.png

I have some ideas of how to design it in a OO manner, but I am not sure if that's the right way. Here's my thoughts:

1. Create an abstract class with method onExit() and onCrushing() . Since the code of onExit() would vary from 3 classes, it should be an abstract method & onCrushing() would be same fo all classes, so it would be an concrete method
2. tHE MAIN WINdow should use singleton design to ensure user only create one instance of main .
3. Use the facade design to save the trouble of implementing 3 interfaces to three classes

My question is I don't really understand facade design, so I am not sure if it can be applied in this case. Also I am not really sure if onExit() would be different for 3 classes and onCrushing() would perform the same function.

I tried my best to explain the question clearly...if you don't understand free free to comment. Thank you very much!

Answer 1

I've left some questions in a comment linked to your question but here's some guidance for you:

1. You shouldn't create an abstract class on the basis of both BuildInwindow and ApplicationWindow both having to have methods #onExit and #onCrushing if they are not to share any implementation. Abstract classes are most useful where there is a common implementation. An interface containing these methods would be sufficient. That said, your two windows may share other functionality and, if so, it could be shared through a common superclass (abstract if it relies on subclass implementation detail). You may find the Template Method pattern useful for managing the overall window mechanism with specific tailoring for different window types. You may also find the Factory Method means of instance creation (for your window classes) will help separate the object creation and set-up from the creation mechanism.

2. A single shared instance would seem sensible and a singleton would serve this purpose (so long as you're able to handle termination, etc). Alternatively, your application may just launch a single Main instance - you may even just hide the constructor through package access to ensure no others are created.

3. The facade pattern just serves to simplify a complex interface. It mainly does this by rolling calls to collaborating instances together under a single (coarser) interface. This wouldn't normally be a done to hide which interfaces a class supports. Indeed, publishing which interfaces a class extends is important to API users. You could roll the three interfaces into a single interface for "convenience" but I think this is unnecessary. If you do settle on a common superclass then that would "extend" the three interfaces (if all subclasses were expected to support them). It may also implement some default implementation of these interfaces (again, watch access modifiers to ensure those you intend to be can be overridden while others may be final).

Edit: Guidance

You just have to identify the classes and relationships: I suggest you just grab some paper and draw. You already have your nouns and verbs (you can otherwise go noun and verb spotting to identify classes and methods on them).

So, why not draw a simple diagram containing all the info ( A , B , C , Main , etc) and draw the relationships between them. This is your start point. You may have some confusion when working out how Main links to the window classes (given there are two kinds). Just write a note on it and move on to clarify the rest of the picture.

Next, refine your diagram to start moving common features into a single place (abstraction). You know this exists with regards to your interfaces and the methods you suggest but you may need to decide which (if any) have any common functionality. Then decide if interfaces satisfies your needs (methods are common but implementations are different) or if the implementation itself is the same and so a parent superclass may be useful (this addresses abstraction [who is responsible for what], encapsulation [individual implementations at the appropriate level] and polymorphism [which classes support common methods]). Note that, even if you settle on an superclass, you'd be wise to back it with an interface (it makes introduction of sibling or replacement classes easier in time - think maintenance).

Next, work on the issues you found. Has your draft design clarified any of them? For instance, your Main needs to know about its windows but - what type are they? So, has any of your refinement made this clearer?

Do any patterns present themselves? for this you need to already have a feel for design patterns I'm afraid so buy and absorb the GoF Design Patterns book . It'll put you in good stead for spotting patterns as you go. I'd also recommend reading this specific book before taking on any others as it's technology agnostic (and some other books arebloated with tech-specific workarounds). Perhaps study the two patterns I pointed out and see if they fit your requirement.

On the whole though, your ideas seem to be going in the right direction.