Reputation: 3
I am currently learning OOP on my own with books and websites. I am at the point I need to practice. I started a small project that I know how to do in a procedural way. But it leaves me with questions when I try to do it in a OOP manner.
My project concept is like this. I want to organize/archive/manage interconnection on our system at work. I use 2 classes. Device and Interface.
A Device have some Interfaces.
Device class have the following methodes:
Interface class have the following methodes :
Basically, I create two device, add some interfaces to each and finally make some connection between interfaces.
A device know all its interfaces. An interface know all other interface it is connected to.
But given an interface how do I know to what device it belong?
If Interface is aware of Device, they become tightly coupled. For what I learn so far it is not really good OO. An other way would be to browse all device to know if they have the Interface I am looking for. It seems really inefficient. I am sure I missed something obvious. Can anybody sees it?
Thanks
update : This can be seen as shapes and connections in a MS Visio file. the interface is really just a connector on a shape. The device is the shape.
Upvotes: 0
Views: 148
Reputation: 3976
A small comment on your existing interfaces. IMHO the print method on the interfaces should be moved to a different interface so that the Device interface has a single responsibility of just maintaining the Interfaces it controls. Also, what does the method "Interface getInterface(Interface pInterface)" receive as Input argument and return? As for the answer, there are a few questions that the answer above raises. If I understand correctly, the device class creates an interface when addInterface() is invoked; If the use case is such that given an interface a device is to be returned, a getDevice() on Interface is okay (I wouldn't add a setDevice() method; Device can be passed into the Interface's constructor) if an Interface always belongs to a device. Edit : The setDevice() method would however be preferrable if you want to give the user of your api an impression that your use case so demands that the device associated with an interface can change at runtime.
Upvotes: 0
Reputation: 24125
If you have the requirement that you must be able to determine the Device
for a given Interface
, that means that Device
and Interface
are already tightly coupled even if you haven't coded it. If you decouple the two classes then you can no longer assume that all Interfaces
belong to a Device
.
If it is the case that all Interface
objects must belong to a Device
, then I don't see any problem having setDevice
/getDevice
methods on Interface
. Yes it creates a circular dependancy, but it looks like that is the best way to model your specific domain. Searching through every Device
just to see if it contains a specific Interface
is a much worse design decision in my opinion.
However, if it is desirable for an Interface
to exist without belonging to a Device
, or maybe belonging to a totally different class, then you'll need to rethink the architecture at a higher level. Something along the lines of: How can I restructure these classes so I don't need to get a Device
from an Interface
? The answer really depends on your specific domain, which we don't know very much about just from the information in your question.
Upvotes: 1