Каковы лучшие ресурсы для изучения того, как избежать побочных эффектов и состояний в ООП?

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

Хорошим примером этого является книга Веб-службы RESTful, в которой описаны стратегии минимизации состояния в веб-приложении. Какие другие существуют?

Помните, что я не ищу еще одну книгу по аналитике ООП/паттернам проектирования (хотя хорошая инкапсуляция и слабая связанность помогают избежать побочных эффектов), а скорее ресурс, где сама тема посвящена состоянию/побочным эффектам.

Некоторые собранные ответы

  • Программисты ООП, которые в основном заботятся о состоянии, делают это из-за параллелизма, поэтому прочитайте Java Concurrency на практике. [именно то, что я искал]
  • Используйте TDD, чтобы сделать побочные эффекты более заметными [Мне нравится, например: чем больше ваши настройки, тем больше состояний вам нужно для запуска тестов = хорошее предупреждение]
  • Разделение команд и запросов [Хорошая вещь, предотвращает побочный эффект изменения аргумента функции, что обычно сбивает с толку]
  • Методы делают только одну вещь, возможно, используют описательные имена, если они изменяют состояние своего объекта, чтобы оно было простым и понятным.
  • Сделать объекты неизменяемыми [Мне это очень нравится]
  • Передавайте значения в качестве параметров, а не сохраняйте их в переменных-членах. [Я не связываю это; он загромождает прототип функции и активно не рекомендуется в «Чистом коде» и других книгах, хотя я признаю, что это помогает решить проблему с состоянием]
  • Пересчитывайте значения вместо их сохранения и обновления [Мне это тоже очень нравится; в приложениях, над которыми я работаю, производительность не вызывает особого беспокойства]
  • Точно так же не копируйте состояние, если можете этого избежать. Сделайте один объект ответственным за его хранение и разрешите другим получить к нему доступ. [Основной принцип ООП, хороший совет]

state side-effects
person Robert Campbell    schedule 27.07.2009    source источник
comment
Я не совсем понимаю, какие побочные эффекты вы имеете в виду и что вы имеете в виду под состоянием (в REST состояние принадлежит протоколу, а не парадигме программирования) в этом контексте.   -  person Daff    schedule 27.07.2009
comment
Я думаю, что вы имеете в виду не то, что вы имеете в виду, избегая побочных эффектов и состояний.   -  person Benjol    schedule 27.07.2009
comment
Что именно вы подразумеваете под состоянием? Значения членов экземпляра объекта в любой заданной точке плюс значения любых статических членов класса объекта? Потому что это очень важная часть ООП, если только вы не собираетесь хранить все свои данные в глобальных переменных.   -  person JAB    schedule 27.07.2009
comment
@Cat: для состояния я почти уверен, что OP означает изменяемое состояние.   -  person rtperson    schedule 27.07.2009
comment
@Benjol - не уверен, что ты имеешь в виду. Вы можете, например, написать полностью функциональное приложение на языке ООП без каких-либо состояний или побочных эффектов (см. Clojure). На практике некоторые побочные эффекты необходимы, или у вас просто есть черный ящик, который просто нагревается, поэтому вместо этого вы пытаетесь четко пометить их при использовании. Каковы стратегии их четкой маркировки/содержания/минимизации в OOD, вот мой вопрос.   -  person Robert Campbell    schedule 27.07.2009
comment
@Daff - именно так, состояние было свернуто, но не удалено. Это нормально. Таким образом, вместо переноса состояния сеанса через несколько запросов состояние сводится к отдельным запросам. В результате меньше ошибок, так как меньше комбинаций состояния сохраняется за меньшее время, легче тестировать, поскольку каждый запрос независим, и мне не нужен какой-то сложный setUp() состояния для запуска теста, и его легче поддерживать, поскольку каждый запрос является более слабо связанным. REST — отличный пример стратегии, которую я ищу.   -  person Robert Campbell    schedule 27.07.2009

Ответы (4)


arrow_upward
7
arrow_downward

Я не думаю, что вы найдете много актуального материала в мире объектно-ориентированного программирования по этой теме, просто потому, что ООП (и наиболее императивное программирование, если уж на то пошло) полагается на состояние и побочные эффекты. Рассмотрим, например, ведение журнала. Это чистый побочный эффект, но в любом уважающем себя J2EE-приложении он есть везде. Первоначальная QuickSort Хоара опирается на изменяемое состояние, поскольку вам приходится менять местами значения вокруг опорной точки, и тем не менее она тоже везде.

Вот почему многим объектно-ориентированным программистам трудно понять парадигмы функционального программирования. Они пытаются переназначить значение «x», обнаруживают, что это невозможно сделать (по крайней мере, не так, как это возможно на любом другом языке, с которым они работали), и вскидывают руки, и кричат: «Это невозможно!" В конце концов, если они будут терпеливы, они изучат рекурсию и каррирование, а также то, как функция карты заменяет потребность в циклах, и успокоятся. Но кривая обучения может быть очень крутой для некоторых.

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

person rtperson    schedule 27.07.2009

arrow_upward
5
arrow_downward

Я думаю, что правила довольно просты: методы должны выполнять только одно действие, а цель должна быть четко выражена в имени метода.

Методы должны либо запрашивать данные, либо изменять их, но не то и другое одновременно.

person jkp    schedule 27.07.2009
comment
Хех, я не читал это, но я читал это в другом месте. Разочаровывает, когда вы видите, что люди не следуют правилу, поскольку вещи становятся настолько трудными для понимания, а затем они удивляются, почему их код ведет себя не так, как должен. - person jkp; 27.07.2009

arrow_upward
4
arrow_downward

Некоторые мелкие вещи, которые я делаю:

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

  • Передавайте значения как параметры, а не сохраняйте их в переменных-членах.

  • Пересчитывайте значения вместо их сохранения и обновления, если это можно сделать достаточно дешево. Это помогает избежать противоречивых данных, забыв обновить их.

  • Точно так же не копируйте состояние, если можете этого избежать. Сделайте один объект ответственным за его хранение и разрешите другим получить к нему доступ.

person starblue    schedule 27.07.2009
comment
Мне нравится предложение сделать объекты неизменяемыми. Я нашел эту ссылку: javapractices.com/topic/TopicAction.do?Id=29 - person Robert Campbell; 27.07.2009

arrow_upward
3
arrow_downward

Один из способов изолировать побочные эффекты в объектно-ориентированном подходе — разрешить операциям возвращать только объект описания вызываемых побочных эффектов.

разделение команд и запросов — это шаблон, близкий к этой идее.

Практикуя TDD (или, по крайней мере, написание модульных тестов), вы, как правило, гораздо лучше осведомлены о побочных эффектах и ​​используете их более экономно, а также отделяете их от других свободных от побочных эффектов выражений, которые легко писать на основе данных (ожидаемых, фактических). ) юнит-тесты для.

person Christian    schedule 27.07.2009