Каковы лучшие ресурсы для изучения, как избежать побочных эффектов и заявить в ООП?
Могут быть проблемы, если перезагрузки компьютера, таким образом, Вы могли запустить приложение как сервис окон.
4 ответа
Я не думаю, что вы найдете много актуальных материалов по этой теме в мире объектно-ориентированных приложений просто потому, что OOP ( и большинство императивных программ, если на то пошло) полагается на состояние и побочные эффекты. Рассмотрим, например, ведение журнала. Это чистый побочный эффект, но в любом уважающем себя J2EE-приложении он повсюду. Первоначальный QuickSort Hoare полагается на изменяемое состояние, так как вам нужно менять значения вокруг точки поворота, и, тем не менее, это тоже повсюду.
Вот почему многим объектно-ориентированным программистам трудно понять парадигмы функционального программирования. Они пытаются переназначить значение «x», обнаруживая, что это невозможно (по крайней мере, не так, как на любом другом языке, на котором они работали), и они вскидывают руки и кричат: «Это невозможно!» В конце концов, если они терпеливы, они узнают о рекурсии и каррировании, а также о том, как функция карты заменяет потребность в циклах, и успокаиваются. Но для некоторых кривая обучения может быть очень крутой.
В наши дни объектно-ориентированные программисты, которые больше всего заботятся об избежании состояния, - это те, кто работает над параллелизмом. Причины этого очевидны - изменяемое состояние и побочные эффекты вызывают огромные головные боли, когда вы пытаетесь управлять параллелизмом между потоками. В результате лучшая дискуссия об избежании состояния, которую я видел в мире объектно-ориентированных приложений, - это Java Concurrency in Practice.
Некоторые мелочи, которые я делаю:
Предпочитаю неизменяемое состояние, оно относительно мягкое. Например, в Java я делаю переменные-члены окончательными и устанавливаю их в конструкторе, где это возможно.
Передайте значения в качестве параметров, вместо того, чтобы сохранять их в переменных-членах.
Повторно вычисляйте значения вместо их сохранения и обновления, если это возможно сделано достаточно дешево. Это помогает избежать противоречивых данных, если их забыть обновить.
Точно так же не копируйте состояние, если вы можете этого избежать. Сделайте один объект ответственным за его хранение и позвольте другим получить к нему доступ.
Один из способов изолировать побочные эффекты в объектно-ориентированном стиле - разрешить операциям возвращать только объект описания вызывающих побочных эффектов.
Разделение команд и запросов - это шаблон, который близка к этой идее.
Практикуя TDD (или, по крайней мере, написав модульные тесты), человек, как правило, будет гораздо лучше осознавать побочные эффекты и использовать их более экономно, а также отделять их от других выражений, свободных от побочных эффектов, которые являются легко написать управляемые данными (ожидаемые, фактические) модульные тесты для.
Я думаю, что правила довольно просты: методы должны выполнять только одно действие, а намерение должно быть четко указано в имени метода.
Методы должны либо запрашивать, либо изменять данные, но никогда и то и другое одновременно .