|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|
|How would you have fixed the iPhonapocalypse||Dsr1205||iPhone||14||Jun 20, 2010 04:53 AM|
|How would you have taken this photo?||Hello.there||Digital Photography||12||Jun 14, 2008 01:25 PM|
|Would You have Bought This PowerBook?||macpastor||PowerPC Macs||10||May 1, 2006 09:49 AM|
|Have you heard of/would you trust - this site?||floyde||Web Design and Development||6||Dec 10, 2005 10:18 PM|
|how would you guys rate this app||dorqiekat||Mac Applications and Mac App Store||7||Apr 21, 2005 05:33 PM|
All times are GMT -5. The time now is 04:32 PM.