Вы пишете объекты, заслуживающие доверия?
Вы доверяете создаваемым объектам?
Вы пишете объекты и вызываете для них методы, не беспокоясь?
Эта проблема
Раньше я видел (и мне приходится заниматься администрированием, что иногда я пишу) код, который не доверяет поведению или ответам других объектов. Обычно это происходит в форме проверки того, что ответ метода не равен нулю, или перехвата исключения «на случай, если произошло что-то неожиданное, что вызываемый класс не обрабатывает».
Если вы занимаетесь объектно-ориентированным программированием (ООП) и хотите делать это хорошо, доверяйте своим объектам и их ответам. Вы должны писать надежные объекты, если хотите правильно выполнять ООП.
Зачем писать целый класс, если вы на всякий случай будете проверять, что он ведет себя правильно?
Что делать?
Перестаньте беспокоиться об этом и доверяйте своим объектам. Если вы пишете хороший объектно-ориентированный код и проверяете, что он ведет себя должным образом, вам следует просто использовать написанный вами код, не беспокоясь.
Я не говорю, что вы должны быть уверены, что ваши классы никогда не выйдут из строя, но если вы собираетесь проверять случаи или спасать исключения в вызывающем методе класса, почему бы не сделать это в самом классе? Не должно быть причин делать связанные с классом вещи за пределами данного класса.
В следующий раз, когда вы напишете класс или метод, подумайте об их ответственности, потому что в большинстве случаев это должен быть только один класс. Когда у класса есть только одна обязанность, его легко протестировать и полагаться на то, что он будет вести себя так, как ожидалось.
Когда вы создаете объект, у вас должен быть четко определенный интерфейс, который определяет, что он делает и как взаимодействует с вашей системой. В области видимости объекта или метода должно быть как можно меньше обязанностей, потому что чем больше ответственности имеет объект, тем более сложным и подверженным ошибкам он будет.
Подумайте об этом так: если вы проверяете ответ, который дают вам ваши методы, то вы больше доверяете коду, который просто использует метод, а не метод, который был разработан для выполнения данной задачи. В этом нет смысла, правда?
В худшем случае, если вы собираетесь перехватывать все возможные исключения, по крайней мере, поместите эту логику в методы вашего объекта, чтобы вы могли хотя бы верить, что они делают то, что должны.
Например, если вы считаете, что HTTP-вызов может дать сбой по нескольким причинам (сетевая ошибка, ошибка тайм-аута и т. Д.), И хотите перехватить эти исключения, сделайте это в классе, который за это отвечает. Это имеет больше смысла, чем делать это на улице, потому что у вас будет единое место для обработки этих дел и будущих обновлений к нему.
Я считаю очень полезным использовать объекты ответа для поддержания хорошей связи между слоями кода (в том числе я пишу драгоценный камень, чтобы упростить их использование).
Это просто вопрос привыкания писать надежные объекты, но по прошествии небольшого времени вы будете писать объекты, которые без проблем взаимодействуют между собой, так что их будет намного проще читать и работать с ними.
Последние слова
Просто попробуйте. В следующий раз, когда вы напишете класс, подумайте, какова его цель, придерживайтесь его и создайте для него ограниченный интерфейс, чтобы другие объекты могли без проблем использовать ваши методы. Вы заметите, как улучшается ваш код и ваша уверенность в нем.
