Структура как объекты в Java

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

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

Это - вопрос на Объектно-ориентированном проектировании, не Java язык. Это - вообще хорошая практика, чтобы скрыть типы данных в классе и представить только методы, которые являются частью API класса. Если Вы представляете внутренние типы данных, Вы никогда не можете изменять их в будущем. При сокрытии их единственное обязательство перед пользователем является возвратом метода и типами аргумента.

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

Проблемой с использованием общедоступного доступа к полю является та же проблема как использование нового вместо метода фабрики - если Вы передумали позже, все существующие вызывающие стороны повреждаются. Так, с точки зрения эволюции API это обычно - хорошая идея стиснуть зубы и использовать методов get/методы set.

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

Между прочим, на электронном-bartek's утверждении, это - очень маловероятный IMO, что поддержка свойства будет добавлена в Java 7.

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

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

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

, Вы также не можете использовать в своих интересах поддержку JavaBean, называющего совместимые классы, которые причинят боль, если Вы решите, скажем, использовать класс на Странице JavaServer, которая записана с помощью Языка Выражения.

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

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

Ре: aku, izb, John Topley...

Не упускают проблемы переменчивости...

может казаться разумным опустить методов get/методы set. Это на самом деле может быть в порядке в некоторых случаях. Настоящей проблемой с предложенным шаблоном, показанным здесь, является переменчивость.

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

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

, Если у Вас есть общедоступные поля, считайте создание класса только для чтения. Добавьте поля как параметры конструктору и отметьте полевой финал. Иначе удостоверьтесь, что Вы не представляете внутреннего состояния, и если необходимо создать новые экземпляры для возвращаемого значения, удостоверьтесь, что это не назовут чрезмерно.

См.: " Эффективный Java" Joshua Bloch - Объект № 13: Неизменность Пользы.

пз: Также имейте в виду, весь JVMs в эти дни оптимизирует далеко getMethod, если это возможно, приводя только к единственной считанной из поля инструкции.

Я попробовал это в нескольких проектах на теории, что методы get и методы set загромождают код с семантически бессмысленным хламом, и что другие языки, кажется, делают очень хорошо с основанным на соглашении сокрытием данных или разделением обязанностей (например, Python).

, Поскольку другие отметили выше, существует 2 проблемы, с которыми Вы сталкиваетесь, и они не являются действительно закрепляемыми:

• Примерно любой автоматизированный инструмент в мире Java полагается на соглашение метода get/метода set. Так же для, как отмечено другими, jsp теги, пружинная конфигурация, инструменты затмения, и т.д. и т.д... Борьба против того, что Ваши инструменты ожидают видеть, является рецептом для долгих сессий, посылающих сообщение-розыгрыш через Google, пытающийся найти что нестандартный способ бобов пружины инициирования. Действительно не стоящий проблемы.
• , Как только у Вас есть свое изящно кодированное приложение с сотнями общедоступных переменных, Вы, вероятно, найдете по крайней мере одну ситуацию, где они недостаточны - где Вам абсолютно нужна неизменность, или необходимо инициировать некоторое событие, когда переменная установлена, или Вы хотите выдать исключение на переменном изменении, потому что это устанавливает объектное состояние на что-то неприятное. Вы тогда застреваете с незавидным выбором между загромождением Вашего кода с некоторым специальным методом везде, на переменную непосредственно ссылаются, имея некоторую специальную форму доступа для 3 из этих 1 000 переменных в Вашем приложении.

И это находится в лучшем варианте развития событий работы полностью в автономном частном проекте. Как только Вы экспортируете все это в публично доступную библиотеку, эти проблемы станут еще больше.

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

Между прочим, структура, которую Вы даете как пример уже, существует в библиотеке базовых классов Java как java.awt.Point. Это имеет X и Y, поскольку общедоступные поля, проверяют его для себя .

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

Для обращения к проблемам переменчивости, можно объявить X и Y как финал. Например:

class Data {
  public final int x;
  public final int y;
  public Data( int x, int y){
    this.x = x;
    this.y = y;
  }
}

Код вызова, который пытается записать в эти поля, доберется, ошибка времени компиляции "поля x объявляется финалом; не может быть присвоен".

клиентский код может тогда иметь удобство 'стенографии', которое Вы описали в своем сообщении

public class DataTest {
    public DataTest() {
        Data data1 = new Data(1, 5);
        Data data2 = new Data(2, 4);
        System.out.println(f(data1));
        System.out.println(f(data2));
    }

    public int f(Data d) {
        return (3 * d.x) / d.y;
    }

    public static void main(String[] args) {
        DataTest dataTest = new DataTest();
    }
}

Используйте здравый смысл действительно. Если у Вас есть что-то как:

public class ScreenCoord2D{
    public int x;
    public int y;
}

Тогда существует мало точки в оборачивании их в методах get и методах set. Вы никогда не собираетесь хранить x, y координата в целых пикселях любой другой путь. Методы get и методы set только замедлят Вас.

, С другой стороны, с:

public class BankAccount{
    public int balance;
}

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

всегда предпочтительно знать , почему Вы применяете хорошую практику, так, чтобы Вы знали, когда нормально изгибать правила.

В этом типе кода нет ничего плохого, при условии, что автор знает , что они являются структурами (или шаттлами данных), а не объектами. Многие разработчики Java не могут отличить хорошо сформированный объект (не только подкласс java.lang.Object, но и объект true в определенном домене) и ананас. Следовательно, они в конечном итоге пишут структуры, когда им нужны объекты, и наоборот.

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