Закон Деметры на Яве

Закон Деметры стремится уменьшить связь между объектами, следуя принципу сокрытия информации. В вашем примере метод m, который содержит оператор:

int numberOfFrigates = model.getSelectedPlanet().getFleet().getNumberOfFrigates();

интересует число Frigatesonly. Но цепочка вызовов методов связывает метод m и, следовательно, тип T, владеющий m, с типами, возвращаемыми getSelectedPlanet() и getFleet().

Чтобы избежать этой введенной зависимости, было бы добавить метод к вашему model, который напрямую возвращает количество фрегатов выбранного в данный момент самолета, например:

int numberOfFrigates = model.getNumberOfFrigates();

Но чаще всего нарушение принципа является показателем плохого дизайна или неуместного распределения обязанностей. Реальное решение этой проблемы, скорее всего, заключается не в предоставлении информации, полученной цепочкой методов, непосредственно потребителю, как в примере, показанном выше, а в перемещении частей или всей ответственности за обработку ближе к объекту, который содержит требуемую информацию.

Чтобы быть как можно более конкретным в вашем примере, спросите себя:

Зачем мне количество фрегатов в моем методе m?

Могу ли я переместить части обработки, выполненной в m, ближе к типам Planet или Fleet?

Таким образом, вы также избежите цепочки методов.

То, что вы делаете здесь, это раскрытие внутреннего состояния везде, в ООП вам не нужно получать внутреннее состояние объекта, чтобы получить информацию о нем. Так что, вероятно, это должно быть model.getSelectedPlanetNumberOfFrigates(), и в объекте вы можете обработать вызов selectedPlanet.getFleetNumberOfFrigates() и т.д...