Short note about relation in UML class diagram.
Relation and Dependency
Can turn into TS code like this
class Address {}
class Food {}
class People {
// for this line People has relation with Address
address: Address
heart: Heart
// for this line People has dependency with Food
eat(food: Food) {}
}
Aggregation and Composition
Can turn into TS code like this
class Heart {}
class People {
heart: Heart
constructor () {
// for this line People has composition with Heart
this.heart = new Heart()
}
}
class PeopleGroup {
peoples: People[]
// for this line PeopleGroup has aggregation with (alot of) People
constructor (peoples: People[]) {
this.peoples = peoples
}
}
Generalization and Realization
Can turn into TS code like this
class Animal {}
interface Eatting {
eat(food: Food): void
}
class People
// for this line People is extends (generalization) from Animal
extends Animal
// for this line People is implement (realization) from Eatting
implements Eatting {
// ...
}
Top comments (2)
Nice article. Well done !
Just one remark: shared aggregation (white diamond) does not necessarily imply that there are lots of objects. In fact, UML no longer adds any meaning for shared aggregation compared to a simple association. Wouldn't multiplicity notation (e.g. * on the People end of an association) allow to unambiguously tell that there are many ?
Thank you for feedback. Agreed, we should use notation for that use case.