Можно ли раскрывать состояние неизменяемого объекта?

Это полностью зависит от того, как вы собираетесь использовать объект. Публичные поля не являются злом по своей сути, просто плохо по умолчанию делать все общедоступными. Например, класс java.awt.Point делает свои поля x и y общедоступными, и они даже не являются окончательными. Ваш пример кажется прекрасным использованием общедоступных полей, но, опять же, вы можете не захотеть раскрывать все внутренние поля другого неизменяемого объекта. Универсального правила не существует.

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

Это напомнило мне о том, что я недавно прочитал в «Чистом коде» Роберта К. Мартина. В главе 6 он дает несколько иную точку зрения. Например, на странице 95 он утверждает

«Объекты скрывают свои данные за абстракциями и предоставляют функции, которые работают с этими данными. Структуры данных раскрывают свои данные и не имеют значимых функций».

И на странице 100:

Квази-инкапсуляция bean-компонентов, по-видимому, заставляет некоторых сторонников объектно-ориентированного программирования чувствовать себя лучше, но обычно не дает никаких других преимуществ.

Судя по примеру кода, класс Foo может представлять собой структуру данных. Итак, основываясь на том, что я понял из обсуждения в «Чистом коде» (это больше, чем просто две цитаты, которые я дал), цель класса — предоставить данные, а не функциональность, и наличие геттеров и сеттеров, вероятно, не приносит много пользы.

Опять же, по моему опыту, я обычно шел дальше и использовал подход "bean" к частным данным с геттерами и сеттерами. Но опять же, никто никогда не просил меня написать книгу о том, как писать лучший код, так что, возможно, Мартину есть что сказать.

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

Преимущество использования геттеров связано с одним дополнительным уровнем косвенности, который может пригодиться, если вы разрабатываете объект, который будет широко использоваться и чья полезность будет распространяться в непредвиденном будущем.

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

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

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

Основной причиной прямого предоставления переменных состояния является возможность использования примитивных операторов непосредственно в этих полях. Если все сделано правильно, это может улучшить читаемость и удобство: например, добавление комплексных чисел с + или доступ к коллекции с ключом с помощью []. Преимущества этого могут быть неожиданными, при условии, что вы используете синтаксис в соответствии с традиционными соглашениями.

Загвоздка в том, что операторы не являются универсальным интерфейсом. Их может использовать только очень специфический набор встроенных типов, их можно использовать только так, как ожидает язык, и вы не можете определить какие-либо новые. Итак, как только вы определили свой общедоступный интерфейс с помощью примитивов, вы заперли себя в использовании этого примитива и только этого примитива (и других вещей, которые можно легко привести к нему). Чтобы использовать что-то еще, вы должны танцевать вокруг этого примитива каждый раз, когда взаимодействуете с ним, и это убивает вас с СУХОЙ точки зрения: вещи могут очень быстро стать очень хрупкими.

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

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

Короче говоря, проблема не в раскрытии вашей реализации как таковой. Проблема заключается в том, чтобы запереть себя в этой реализации.

Фактически, он нарушает инкапсуляцию, чтобы каким-либо образом раскрыть любое свойство объекта — каждое свойство является деталью реализации. То, что все так делают, не делает это правильным. Использование средств доступа и мутаторов (геттеров и сеттеров) не делает его лучше. Вместо этого для поддержания инкапсуляции следует использовать шаблоны CQRS.

Класс, который вы разработали, должен быть прекрасен в его нынешнем воплощении. Проблемы обычно возникают, когда кто-то пытается изменить этот класс или наследовать от него.

Например, увидев приведенный выше код, кто-то думает о добавлении еще одного экземпляра переменной-члена класса Bar.

public class Foo {
    public final int x;
    public final int y;
    public final Bar z;

    public Foo( int x, int y, Bar z) {
        this.x = x;
        this.y = y;
    }
}

public class Bar {
    public int age; //Oops this is not final, may be a mistake but still
    public Bar(int age) {
        this.age = age;
    }
}

В приведенном выше коде экземпляр Bar нельзя изменить, но внешне любой может обновить значение Bar.age.

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

Невосприимчивость необходима для параллельного программирования.

Я знаю только одну опору, в которой есть геттеры для конечных свойств. Это тот случай, когда вы хотите иметь доступ к свойствам через интерфейс.

    public interface Point {
       int getX();
       int getY();
    }

    public class Foo implements Point {...}
    public class Foo2 implements Point {...}

В противном случае общедоступные окончательные поля в порядке.

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

Рассмотрим вопрос о том, что вы хотели бы, чтобы произошло, если какой-то метод Foo хочет дать вызывающему объекту Point3d, который инкапсулирует «X=5, Y=23, Z=57», и у него есть ссылка на Point3d, где X =5, Y=23 и Z=57. Если то, что есть у Foo, известно как простой неизменяемый держатель данных, то Foo должен просто дать вызывающей стороне ссылку на него. Однако если это может быть что-то другое (например, может содержать дополнительную информацию помимо X, Y и Z), то Foo должен создать новый простой держатель данных, содержащий "X=5, Y=23 , Z=57" и дайте вызывающей стороне ссылку на это.

Запечатывание Point3d и раскрытие его содержимого в качестве общедоступных конечных полей будет означать, что такие методы, как Foo, могут предполагать, что это простой неизменяемый держатель данных, и могут безопасно делиться ссылками на его экземпляры. Если существует код, который делает такие предположения, может быть трудно или невозможно изменить Point3d, чтобы он был чем-то другим, кроме простого неизменяемого держателя данных, не нарушая такой код. С другой стороны, код, который предполагает, что Point3d является простым неизменяемым держателем данных, может быть намного проще и эффективнее, чем код, который имеет дело с возможностью того, что это что-то другое.

Этот стиль часто встречается в Scala, но между этими языками есть принципиальное различие: Scala следует принципу единого доступа., а Java — нет. Это означает, что ваш дизайн в порядке, пока ваш класс не меняется, но он может сломаться несколькими способами, когда вам нужно адаптировать свою функциональность:

• вам нужно извлечь интерфейс или суперкласс (например, ваш класс представляет комплексные числа, и вы также хотите иметь родственный класс с представлением в полярных координатах)
• вам нужно наследовать от своего класса, и информация становится избыточной (например, x можно вычислить из дополнительных данных подкласса)
• вам нужно проверить ограничения (например, x по какой-то причине должно быть неотрицательным)

Также обратите внимание, что вы не можете использовать этот стиль для изменяемых элементов (например, печально известного java.util.Date). Только с геттерами у вас есть возможность сделать защитную копию или изменить представление (например, сохранить информацию Date как long)

Я использую много конструкций, очень похожих на ту, которую вы задали в вопросе, иногда есть вещи, которые лучше моделировать с помощью (иногда неизменной) структуры данных, чем с классом.

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

Например, у Роберта Мартина есть одна глава об этом в замечательной книге «Чистый код», которую, на мой взгляд, необходимо прочитать.

В тех случаях, когда единственная цель состоит в том, чтобы соединить два значения друг с другом под осмысленным именем, вы можете даже пропустить определение каких-либо конструкторов и оставить элементы изменяемыми:

public class Sculpture {
    public int weight = 0;
    public int price = 0;
}

Это имеет то преимущество, что сводит к минимуму риск перепутать порядок параметров при создании экземпляра класса. Ограниченная изменчивость, при необходимости, может быть достигнута путем взятия всего контейнера под private контроль.

Просто хочу отразить отражение:

Foo foo = new Foo(0, 1);  // x=0, y=1
Field fieldX = Foo.class.getField("x");
fieldX.setAccessible(true);
fieldX.set(foo, 5);
System.out.println(foo.x);   // 5!

Итак, Foo по-прежнему остается неизменным? :)