macOS How would you have answered this interview question

[w00tmaster]

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.

drivers
/ \ \
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.

 

[superbovine]

I wouldn't
http://jusb.sourceforge.net/

 

[mrichmon]

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.

drivers
/ \ \
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.

Here are a couple of suggestions:

• if the USB code is specific to each class of drivers then introduce a "legacy" and a "usb" class under cdroms and under digital cameras. This makes sense if there are usb operations that are specific to cdroms only and other operations that are specific to digital cameras.
• if the intention of the question was that the usb operations are truely generic then you need to introduce a "legacy" (or parallel port, etc) class that inherits from driver. You then also create a "usb" class under driver and reshuffle the rest of the classes. Ideally the reshuffle would introduce cdrom, printer and digital camera interfaces.

                                  drivers
                         /                       \
                    legacy                        usb
                  /        \                  /         \
    legacyPrinter     legacyCdrom       usbPrinter        usbCdrom
       /        \                \           /                  \
     HP      Sony                IBM       HP                  Sony

With legacyPrinter and usbPrinter both implementing the Printer interface. Similarly, legacyCdrom and usbCdrom should implement a Cdrom interface. I assume that "HP", "Sony", etc are refering to specific models of devices so "HP" is shorthand for "HP Laserjet 1234j" or whatever.

 

[notjustjay]

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.

 

[wiseguy27]

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-Design-Patterns/dp/0596007124/) is a good book!