UML classes diagram the question of relations and visibility of fields

Question

I have a few questions regarding my design after having reviewed a number of information sources.

I decided to link the User and UserSettings classes with a composition relation (since user settings don't make sense without a specific user). I have defined a method in the UserSettings class that allows changing the password, but I would like to know if I can access a private field in the User class? Or should I make it public? Maybe protected?

I also read that aggregation and composition are redundant relations, and they are mainly used with an indication of multiplicity. But I can use multiplicity in association. So what kind of relationship would it be correct to specify for the relationship of the AddressPoints and UserSettings classes? Since I can't decide which would be more appropriate here, aggregation or association.

I would also like to know if it is necessary to specify constructors, setters and getters in classes? Or can it be omitted?

Answer 1

I decided to link the User and UserSettings classes with a composition relation ( since user settings don't make sense without a specific user).

This is a correct use of composition.

---

if I can access a private field in the User class? Or should I make it public? Maybe protected?

No, you cannot access private fields from another class. You cannot either access protected fields from another class, unless it's inheriting from User. Anyway, it's not a safe practice in view of Liskov Substititution Principle (and more precisely it's "history constraint"), so better avoid protected if possible.

No, you shouldn't make it public. This creates coupling between classes and make the software more difficult to evolve. Every time you need to access a field from another class, you should challenge yourself in view of the Tell, don't ask principle (i.e. tell a method to do something and let the class manage itself, and do not ask the class and do something with it somewhere else).

---

I also read that aggregation and composition are redundant relations, and they are mainly used with an indication of multiplicity. But I can use multiplicity in association.

They are not redundant. In fact, you already spotted a justified use of composition (composite aggregation in UML-speak).

But you are completely right: aggregation (more precisely shared aggregation, in UML-speak) does not add any semantic in UML. So, better not use it. A simple association with correct multiplicity should be more than enough and the association for AddressPoint is what you need.

---

if it is necessary to specify constructors, setters and getters in classes? Or can it be omitted?

Diagrams do not need to be exhaustive. You decide what you want to show and where the focus is. Not showing constructors, setters and getters, doesn't exclude that they exist. Putting all getters and setters might make diagrams look more complex than needed without adding a lot of value.