3

In a interview I was asked,

Suppose we are going to create a software that runs on both desktop machines and smartphones. Name a software design pattern that could be used to enable the application to create different classes for display at runtime depending on the platform.

I know there are simple solutions to implement this feature in the actual code. For example, in Java I can check the display size and create the suitable class (MobileDisplay or DesktopDisplay class) for that display.

But I don't how this is related to the software design; in my opinion, creating suitable class based on runtime platform is an implementation concern rather than a software design issue.

Improve this question
4
  • Sure he said "create different classes at runtime", not "instances of different classes"?
    – Doc Brown
    Apr 24, 2012 at 14:34
  • I honestly suspect your interviewer was just looking for an answer that he could get you to expand on, to prove that you knew what you were talking about.
    – pdr
    Apr 24, 2012 at 14:56
  • Maybe he was looking for MVC?
    – Michael K
    Apr 24, 2012 at 17:43
  • Note to self, being my usual anal self on SE does not bide well in a social environment and interviews where others warm to people easy to work with.
    – user9682
    Apr 24, 2012 at 19:09

3 Answers 3

Reset to default
5

I think the interviewer was expecting the Abstract Factory pattern. http://www.vincehuston.org/dp/abstract_factory.html And I also think that you are missing the point of software design. Ultimately software is about implementation, but a little thought and design patterns make the implementation easy to follow.

Improve this answer
4
  • 1
    Disagree. Abstract factory is an abstract object that returns other objects, which combine to make an implementation, such as my answer to this question: programmers.stackexchange.com/questions/81838/…. This is only two cases, so there is no need for multiple components like that. A Strategy was the answer, possibly combined with a Factory Method. I'm not sure why Oded deleted his answer.
    – pdr
    Apr 24, 2012 at 13:39
  • 2
    'create different classes ... at runtime' means the interviewer was looking for a factory in the answer IMO.
    – Telastyn
    Apr 24, 2012 at 13:45
  • @Telastyn: A Strategy enables "the application to create different classes for display at runtime depending on the platform". Whether that creation is done via Factory Method or constructor is largely irrelevant. That said, I would have been sure to mention Factory Method as well, just in case there was a miscommunication.
    – pdr
    Apr 24, 2012 at 14:13
  • @pdr Oded removed... because he interpreted Strategy as a pattern to do like "select algorithm at runtime" - which obviously didn't fit the bill. If you can think of compelling way to marry Strategy with runtime creation of different classes, go ahead - write your own answer
    – gnat
    Apr 24, 2012 at 14:26
4

I can just take a guess on what your interviewer meant, but the "Bridge pattern" enables you to choose between different (maybe platform specific) implementations for an abstraction at run time. The abstraction in your case could be the display.

The original example in the GOF book for the bridge pattern demonstrates this by using different Window implementations, an XWindowImp (for the X-windows windowing system) and a PMWindowImp (for IBM presentation manager windowing system), which seems to me very similar to your question.

And of course, this is a design issue. Not using the bridge pattern can also lead to a working solution, but with more code duplication and more platform dependent code - and that's what design is about - choosing the right concept which leads to better evolvable or maintainable code.

EDIT: an abstract factory can be used to instantiate and configure your bridge classes at run time, so the AF pattern may be of use here, too.

Improve this answer
4
  • 1
    Ahh, now that's a good answer.
    – pdr
    Apr 24, 2012 at 14:55
  • What you describe sounds more like a Strategy pattern as in my answer below; it uses the basic idea of the Bridge, decoupling implementation from usage, for the express purpose of being able to select from multiple implementations at runtime. There are many other reasons to use "dependency abstraction" aka the Bridge pattern, that do not involve having many implementations available for use at any given time.
    – KeithS
    Apr 24, 2012 at 15:36
  • @KeithS: In fairness, the State pattern looks exactly like the Strategy too. Patterns are broadly separated by intent, not by implementation.
    – pdr
    Apr 24, 2012 at 15:50
  • 1
    @KeithS: when all you have is a hammer, lots of things start looking like a nail ;-) But in fact, I did not describe the bridge pattern, I just cited it from the GOF book.
    – Doc Brown
    Apr 25, 2012 at 6:09
2

Patterns work well together. I can't claim to know exactly what your interviewer was looking for, but I would have suggested a combination of patterns:

MVC, MVVM, MVP are all patterns that try decouple the UI from the model/data, permitting multiple visual representations for the same model/data. I would have picked the one I was most familiar with.

From there, Factory Method and/or dependency injection (whichever flavour you want constructor/property etc.) can be used at runtime to choose/instantiate the relevant view. Consider that DI is a pattern, and that DI frameworks exist mostly to make it easier and more consistent/readable.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.