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

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

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

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

Некоторые скомпилированные ответы

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

ОТВЕТЫ

Ответ 1

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

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

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