Что ж, есть некоторые вещи, которые следует учитывать в этом сценарии.Даже если это имеет смысл, если вы считаете себя сущностями реального мира, обычно ОО-практикой не рекомендуется позволять объекту изменять состояние другого объекта.
При этом, если вам не нужны другиекласс, чтобы изменить свойство одного класса, вы должны сделать это поле закрытым и вообще не указывать установщик.
Что касается обозначения, вы не можете помешать объекту изменять его свойства, если только он не окончательный, но тогдаменеджер также не может его изменить.
Полагаю, у вас может быть класс Обозначения, и вы можете сделать его так, чтобы его мог создать только менеджер.Но даже в этом случае сотрудник может установить для него значение NULL.
Или вы можете сделать так, чтобы класс Designation содержал ссылку на одного или нескольких сотрудников, тогда только менеджер мог получить доступ к объектам назначения.
КакЯ сказал, я думаю, что это один из тех случаев, когда ОО-моделирование не совсем соответствует реальному миру.Классы должны нести ответственность за свое собственное состояние и иметь собственный набор правил для любых изменений состояния.Любой другой класс должен иметь возможность только запросить или запросить изменение.
Надеюсь, это поможет!