РЕДАКТИРОВАТЬ: Я ответил на этот вопрос, потому что есть множество людей, изучающих программирование, которые задают этот вопрос, и большинство ответов очень технически компетентны, но их не так легко понять, если вы новичок. Мы все были новичками, поэтому я подумал, что попробую найти более дружелюбный для новичков ответ.
Двумя основными из них являются полиморфизм и проверка. Даже если это просто дурацкая структура данных.
Допустим, у нас есть этот простой класс:
public class Bottle {
public int amountOfWaterMl;
public int capacityMl;
}
Очень простой класс, показывающий, сколько жидкости в нем и какова его емкость (в миллилитрах).
Что происходит, когда я делаю:
Bottle bot = new Bottle();
bot.amountOfWaterMl = 1500;
bot.capacityMl = 1000;
Ну, вы же не ожидали, что это сработает, верно? Вы хотите, чтобы была какая-то проверка на вменяемость. И что еще хуже, что, если я никогда не указывал максимальную мощность? О боже, у нас проблема.
Но есть еще одна проблема. Что, если бы бутылки были всего лишь одним типом тары? Что, если бы у нас было несколько контейнеров, все с емкостью и количеством заполненной жидкости? Если бы мы могли просто создать интерфейс, мы могли бы позволить остальной части нашей программы принять этот интерфейс, и бутылки, канистры и все такое прочее работали бы взаимозаменяемо. Разве это не было бы лучше? Поскольку интерфейсы требуют методов, это тоже хорошо.
В итоге мы получим что-то вроде:
public interface LiquidContainer {
public int getAmountMl();
public void setAmountMl(int amountMl);
public int getCapacityMl();
}
Большой! А теперь просто меняем Bottle на это:
public class Bottle extends LiquidContainer {
private int capacityMl;
private int amountFilledMl;
public Bottle(int capacityMl, int amountFilledMl) {
this.capacityMl = capacityMl;
this.amountFilledMl = amountFilledMl;
checkNotOverFlow();
}
public int getAmountMl() {
return amountFilledMl;
}
public void setAmountMl(int amountMl) {
this.amountFilled = amountMl;
checkNotOverFlow();
}
public int getCapacityMl() {
return capacityMl;
}
private void checkNotOverFlow() {
if(amountOfWaterMl > capacityMl) {
throw new BottleOverflowException();
}
}
Я оставлю определение исключения BottleOverflowException в качестве упражнения для читателя.
Теперь обратите внимание, насколько это надежнее. Теперь мы можем работать с любым типом контейнера в нашем коде, приняв LiquidContainer вместо Bottle. И то, как эти бутылки справляются с подобными вещами, может быть разным. У вас могут быть бутылки, которые записывают свое состояние на диск при его изменении, или бутылки, которые сохраняются в базах данных SQL или GNU знает что еще.
И все они могут иметь разные способы справиться с различными криками. Бутылка просто проверяет и, если она переполняется, выдает исключение RuntimeException. Но это может быть неправильным поступком. (Есть полезное обсуждение обработки ошибок, но я намеренно сохраняю его очень простым. Люди в комментариях, вероятно, укажут на недостатки этого упрощенного подхода.;))
И да, похоже, что мы переходим от очень простой идеи к быстрому получению более качественных ответов.
Учтите также, что вы не можете изменить вместимость бутылки. Теперь он высечен в камне. Вы можете сделать это с помощью int, объявив его final. Но если бы это был список, вы могли бы очистить его, добавить в него новые элементы и так далее. Нельзя ограничивать доступ прикосновением к внутренностям.
Есть еще третья вещь, о которой не все учли: геттеры и сеттеры используют вызовы методов. Это означает, что везде они выглядят как обычные методы. Вместо того, чтобы иметь странный специфический синтаксис для DTO и прочего, у вас везде одно и то же.
person
Haakon Løtveit
schedule
29.11.2015
String s = employee.name()иemployee.name("oscar")вместо getName () setName () - person OscarRyz schedule 28.10.2009public String foo;его небезопасный поток! Вместо этого вы можете определитьgettersetters с методами синхронизации, чтобы избежать неверности данных [я имею в виду, что другой поток испортил foo]. Я чувствовал, что об этом стоит упомянуть. - person Prasanth schedule 23.08.2012