|Sep 20, 2006, 04:15 AM||#1|
How would you have answered this interview question
This is the question I got in an interview and I froze, so I'm 99.9% sure I didn't get the job, but curiosity has gotten the best of me.
I have copied down(roughly, it was spoken to me, not written) a class diagram for drivers. Some of them are USB, some not, so how would you create a USB class such that you didn't have to re-write the USB code? Keep in mind this would have to be in Java without using multiple inheritance.
/ \ \
printers cdroms digital cameras
/ \ \ / \ \ / \ \
hp can ep. sony acer pioneer sony nikon fujifilm
\ \ / \
usb usb usb usb
The answer hit me after I hung up(well, what I think is the answer anyway) would be to add a USB to the 2nd level of the hiearchy, and include an instance of that class in the USBs, and then use that to do your USB specific calls. Though there probably is a more elegant solution.
|Sep 23, 2006, 12:15 PM||#3|
drivers / \ legacy usb / \ / \ legacyPrinter legacyCdrom usbPrinter usbCdrom / \ \ / \ HP Sony IBM HP Sony
|Sep 23, 2006, 03:11 PM||#4|
I'm not really certain I understand all that's being asked, particularly since your class diagrams don't show up too well with the variable-spaced fonts, but I get the gist.
Couple of ways to keep USB code encapsulated and reusable.
One would be multiple inheritance, but as you say, Java doesn't support that.
As the guy in the response above me said, you could subclass Driver and create a UsbDriver class. Subclass that for particular devices as you see fit. However, this completely changes any existing class hierarchy, which may not always be a good thing.
Alternately, you could create something like a USBCommunicator object, which classes could instantiate, though this method is not nearly as elegant. However, it would allow you to keep all your USB comms code in one place, and add USB functionality to whatever other classes you want, without changing their existing hierarchy.
|Sep 28, 2006, 04:35 AM||#5|
Why not create a USB class that's outside this class hierarchy and use composition instead of inheritance??? Instantiate the USB class in each of the drivers and use its services as required. You could also look at the decorator pattern if you'd like to extend the functionality of the USB class without modifying it.
Composition provides more flexibility compared to inheritance when you want to change the behavior of objects at runtime instead of deciding at compile time.
"Head First Design Patterns" (http://www.amazon.com/Head-First-Des...dp/0596007124/) is a good book!
|Thread Tools||Search this Thread|
|thread||Thread Starter||Forum||Replies||Last Post|
|question answered:What part is this? stupid question from a stupid...||mikentosh2003||MacBook Pro||3||Sep 9, 2013 08:25 AM|
|Really want this answered...||BrokeTechLover||Mac Applications and Mac App Store||14||Oct 9, 2012 12:33 AM|
|Interview question||kazpod||Community Discussion||6||Sep 19, 2012 11:31 AM|
|ok sorry but i have not seen this answered anywhere....||weeble8604||iPhone||10||Sep 13, 2012 08:51 AM|
|How soft is the aluminum? [My question got answered, thanks you all]||Nevzorus||iPad||17||Aug 1, 2012 12:53 PM|
All times are GMT -5. The time now is 03:34 PM.