Свойства класса java с геттером и сеттером, разве это не должно быть обычным явлением
Я занимаюсь разработкой на Java более 5 лет.
Теперь, когда я начинаю писать новый класс или код, я начинаю с определения свойств своего класса. Поэтому мне нужно будет каждый раз нажимать eclipse generate getter и setter, к моему разочарованию. И это более чистый код и гораздо более понятный в конечном итоге.
Но мне нравится мыслить абстрактно и использовать ООП и дженерики. Таким образом, существует либо конкретная причина, по которой людям нужно использовать примитивы Java, либо мы можем просто создать такой класс в Java, чтобы всегда иметь геттер и сеттер и при этом оставаться в пределах обычного использования членов класса Java:
public class Property<Type> implements Getter<Type>,Setter<Type>{
protected Type value;
public Property() {
}
@Override
public <T extends Type> void set(T value) {
this.value = value;
}
@Override
public Type get() {
return value;
}
public String toString() {
return value.toString();
}
}
Вы по-прежнему можете использовать модификаторы для ограничения доступа к определяемым вами переменным. Вы по-прежнему будете использовать то же объявление переменной, что и в:
Class test{
private Property<Number> priv_floatProperty = new Property<Float>();
protected Property<Number> prot_floatProperty = new Property<Float>();
public Property<Number> publ_floatProperty = new Property<Float>();
}
Просто хотел задать этот вопрос, чтобы узнать, что другие люди думают об этом коде и написании ваших классов таким образом. Я очень надеюсь, что смогу получить отзывы об этом коде и теории проектирования классов в Java,
Пожалуйста, взгляните на Ломбок, который частично обращается к шаблонному коду геттеров / сеттеров.
и если вы хотите установить какое-либо свойство в классе, который его использует, вам нужно написать установщик для вызова установщика этого свойства ....
Что ж, достаточно безопасно не приводить к String, например, в приведенном выше примере. Это даст эту ошибку при компиляции «Тип несоответствия». Таким образом, он только вернет метод get любому дочернему элементу Number. Я имею в виду, разве этот тип не безопасен? А сложно? Мне этот дизайн нравится больше, чем необходимость каждый раз писать геттеры и сеттеры в моем коде.
@CarlosHeuberger, извините, но вы можете использовать расширение. обозначение, если его доступное право? как anyclass.myproperty.set ()
@Pouria Jafari Что, по вашему мнению, произойдет, когда вы это сделаете: Integer t = priv_floatProperty.get();
@Pouria Jafari. Не важно. В любом случае это небезопасно. Любой параметризованный метод, который не может проверить ожидаемый тип возврата клиента, небезопасен.
Я согласен, что это вносит слишком много сложностей. Если бы это был общий шаблон, вы бы действительно видели его в общих репозиториях.
@tsolakp Редактировал класс. Он вернет объявленный тип, но вы можете установить его в противном случае для любого расширенного класса этого типа. Все еще не в порядке? Позвольте мне немного пояснить, что, если бы вам пришлось написать класс с более чем 1000 видами свойств. Какое решение вы бы выбрали?
Делая это так, как вы предлагаете, что вы делаете, когда у вас есть поле List, и вы хотите, чтобы получатель всегда возвращал копию списка и метод add (), который гарантирует, что потребители не могут иметь доступ к базовому списку?
@Pouria Jafari. Метод get выглядит нормально.
@cleberz При необходимости вы можете переопределить метод get в функции анонимного класса. Или создайте функцию добавления для конкретной переменной. Вы можете использовать его тогда при доступе к переменной, верно?
Более серьезная проблема здесь в том, что вы не должны открывать аксессоры, особенно сеттеры, для всех свойств объекта. Скажите, а не спрашивайте: если вы относитесь к своим классам только как к набору свойств, то вы занимаетесь структурированным программированием, а не объектно-ориентированным программированием.
конечно, вы можете использовать anyclass.myproperty.set, but why not use anyclass.myproperty.value = ... `-` myproperty ничего не добавляет, использование объекта только / только для хранения другого объекта для меня немного странно, почему бы не иметь другой объект удерживать объект, который удерживает объект? Это нормально, IMO, если у него есть какие-то дополнительные функции (или причина семантический), но просто чтобы они были?
Как насчет неизменности? У вас есть какой-то класс Property, который не позволяет кому-либо вызывать set ()?
@CarlosHeuberger Спасибо за ваше мнение. Одним из преимуществ его функциональности является то, что установщик и получатель больше не являются частью содержащего класса. Сначала вы обращаетесь к свойству, а затем используете set, например anyclass.property.set (). Прочтите мой следующий ответ cleberz о преимуществах.
@cleberz На самом деле моя идея заключалась в том, чтобы позволить геттеру и сеттеру реализовать интерфейс дочернего класса Property. Полная оценка, конечно, будет иметь, например, абстрактный класс свойств и подклассы, такие как immutuableproperty или NotNullProperty. Я взгляну на опциональную реализацию в Java, чтобы увидеть, как они это сделали. И я также пытаюсь создать пример, например, со свойством «время» внутри класса, например, чтобы показать преимущества. Позже сегодня опубликую пример кода.
Ответы 1
Я считаю, что дженерики следует использовать только в случае необходимости.
Во-первых, для удобочитаемости.
Во-вторых, вы можете быстро решить проблему стирания типа Java (видеть). Таким образом, вы можете столкнуться с множеством проблем при сравнении классов (и использовании соответствующих методов .equals / .hashcode). Я видел несколько сложных случаев, когда единственным решением было использование нечитаемых, сложных и затратных по производительности отражений ...
Как было предложено, вы можете использовать Ломбок для создания абстракции геттеров / сеттеров.
Излишне сложно. И ваш слепок методом
getнебезопасен.