2

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?

enter image description here

Improve this question
5
  • 1
    You cannot access private fields from another class. You should prefer goal-oriented operations over getters and setters. We change the password for a user, not for a user setting. Thus, in my view, the user setting class is unjustified.
    – Jim L.
    Commented Mar 12, 2023 at 15:03
  • Address and lat / long are different ways to index one location. They are not intrinsic to a location. your_addresses belongs at the pointy end of the association.
    – Jim L.
    Commented Mar 12, 2023 at 15:08
  • @JimL. You mean I should turn the arrow the other way?Did I understand you correctly?
    – Smth_Unknown
    Commented Mar 12, 2023 at 15:12
  • @JimL. I'm sorry if I misunderstood you, English is not my native language, so I may have some difficulties interpreting what I read
    – Smth_Unknown
    Commented Mar 12, 2023 at 17:23
  • No, delete the duplicate attribute and fill out the property at the pointy end.
    – Jim L.
    Commented Mar 12, 2023 at 19:30

1 Answer 1

Reset to default
2

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.

Improve this answer
2
  • The composition may be technically correct, but 1:1 classes are dubious, especially since they often involve at least getters.
    – Jim L.
    Commented Mar 12, 2023 at 19:34
  • @JimL. 1:1 classes can also result of SRP and sound separation of concerns, e.g like Strategy pattern. And with "tell don't ask" getters can be avoided while at the same time strengthening polymorphism. This being said, in this particular case, I agree that the different concerns are not obvious -- at least the boundaries need to be clarified: e.g. why is the address related to the settings and not to the user? Nevertheless, OP could simply add a changePassword() to User and let UserSettings forward/delegate the call.
    – Christophe
    Commented Mar 12, 2023 at 21:14

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