1

Let's say you have a wireless network that acts as a bridge/wireless repeater. How would both factor into a class diagram? In my mind it makes senses to have a parent object that can exist on its own. Then the child object that is both dependent on the parent, but also creates an instance of the parent. The child can access all the inherited attributes, while being able to overload methods that take use of the methods and attributes of the parent instance.

Does this make any sense at all on what i'm trying to do? I'm trying to combine composition with inheritance and not sure if that's the "right way" to do it or since accessing the parent would be a method, only inheritance needs to be shown.

In my mind, a wireless repeater has a parent wireless network (aggregate), but also has the completely separate one that inherits the wirelessnetwork attributes. I want it that direction because the bridge network is a private extension of the main wireless network and need to be able to show this in a sequence diagram.

Improve this question
5
  • 2
    We model with purpose. Models are abstractions, since we cannot model everything. If the model meets your requirements (here, as stated, sequence diagramming), then very good. If there are other requirements, you may need to adjust. But don't model with features you aren't using -- just model enough for your cases.
    – Erik Eidt
    Feb 16, 2020 at 22:56
  • One thing lacking here is any mention at all of the behaviour that you're trying to model. The main reason for having relationships between classes is to be able to model behaviour that involves those classes interacting with each other somehow. Without knowing what the behaviour or interactions are, it's impossible to tell whether your proposed design is useful or not; however, as Erik mentions, if the design meets your requirements/use cases, then that's all that really matters.
    – Ben Cottrell
    Feb 16, 2020 at 23:05
  • @BenCottrell I guess my main question is if it's acceptable/valid UML to have an inheritance and a composition between the same entities.
    – Nels
    Feb 17, 2020 at 0:04
  • Yes, this is valid UML. it can be confusing, I suggest to put roles on the composition. Are you sure you don't mean to use aggregation or association? I guess, what I'm saying is that I do not understand why you want composition with inheritance... However, yes, it is valid UML.
    – Theraot
    Feb 17, 2020 at 0:42
  • Actually I think, this is nonsense. A Repeater is not a network. It's part of a network. A single repeater is just a useless piece of plastic. It makes sense only as part of a network.
    – user188153
    Feb 17, 2020 at 10:18

2 Answers 2

Reset to default
3

In your design, a WirelessNetwork can have one or more WirelessRepeater, and the WirelessRepeater is itself a WirelessNetwork. There is no UML issue here, except that your diagram would be easier to read if you would keep the inheritance and the composition graphically distinct (e.g. 2 parallel lines).

The consequence of your design is that the WirelessRepeater has all the attributes of the WirelessNetwork. But with its own values, that do not necessarily correspond to the values of the owning network. Furthermore the repeater would offer all the network services, including some which might not be relevant for the repeater (e.g.the configuration options for a real repeater are very limited compared to those of a router).

Your model is therefore not accurate:

  • First, according to the UML semantics, when the parent network gets destroyed, the repeater should get destroyed as well. So better replace the composition with an aggregation, or even a simple association.
  • Second, a repeater is not the network. A repeater is connected to a network and extends its range. But for example, it does not define its own addressing scheme.

A better appraoch would IMHO be to use the proxy pattern: the repeater would be a proxy for the network, and both the network and the proxy would inherit from a class that would define the network methods that are available for both (e.g. connect()), but that would not contain methods that are only relevant for the network (e.g. setIPAdressingScheme())

Improve this answer
1
  • 1
    @qwerty_so I think it is necessary to draw attention that there could be several which is a different situation for the inheritance. But you are right: there could be zero as well, so I've edited to "can have one or more" to clarify that this is not mandatory. Thanks!
    – Christophe
    Feb 17, 2020 at 8:12
0

This is redundant. When you inherit you construct your parent anyway. If you also compose yourself of that parent you just end up with a second instance of your parent.

Inheritance gives you an instance of your parent, their interface, and the wiring between them for free.

Composition (and delegation) gives you all the same stuff but costs you extra keystrokes because you have to wire everything up. But here is where you find lots of power and flexibility.

Doing both at the same time without any particular reason doesn’t really give you much besides confused maintenance developers.

Improve this answer
0

Your Answer

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

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