Объектная оргия

Материал из wikixw
Перейти к навигации Перейти к поиску

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

Последствия[править]

Результатом объектной оргии в основном является потеря преимуществ инкапсуляции, в том числе:

  • Неограниченный доступ мешает читателю рассуждать о поведении объекта. Это происходит потому, что прямой доступ к его внутреннему состоянию означает, что любая другая часть системы может манипулировать им, увеличивая объем кода для изучения и создавая средства для будущих злоупотреблений.
  • Как следствие сложности рассуждений, проектирование по контракту фактически невозможно.
  • Если большая часть кода использует в своих интересах отсутствие инкапсуляции, результатом является едва ли ремонтопригодный лабиринт взаимодействий, обычно известный как крысиное гнездо или спагетти-код.
  • Оригинальный дизайн затемняется чрезмерно широкими интерфейсами к объектам.
  • Широкие интерфейсы затрудняют повторную реализацию класса, не нарушая остальную часть системы. Это особенно сложно, когда клиенты класса разрабатываются другой командой или организацией.

Формы[править]

Инкапсуляция может быть ослаблена несколькими способами, в том числе:

  • Объявляя внутренние члены общедоступными или предоставляя свободный доступ к данным с помощью общедоступных методов-мутаторов (setter или getter).
  • Путем предоставления непубличного доступа. Например, см.: Модификаторы доступа Java и уровни доступности в C #
  • В C ++, с помощью некоторых из вышеперечисленных средств, а также путем объявления friendклассов или функций.

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

Напротив, объекты, содержащие ссылки друг на друга, хотя иногда и описываются как форма объектной оргии, сами по себе не нарушают инкапсуляцию.

Причины[править]

Члены могут быть объявлены общедоступными, чтобы избежать усилий или синтаксических накладных расходов на предоставление им надлежащих средств доступа. Это может повысить читабельность класса, но ценой последствий, описанных выше.

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

Объектная оргия может быть симптомом кодирования незрелого анемичного дизайна, когда дизайнер недостаточно проанализировал взаимодействия между объектами. Это также может возникнуть из-за лени или спешки в реализации дизайна, особенно если программист недостаточно общается с дизайнером, или из-за нежелания пересматривать дизайн при возникновении проблем, что также поощряет многие другие анти-шаблоны.

Многие программисты рассматривают объекты как анемичные хранилища данных и манипулируют ими, нарушая принципы сокрытия информации, инкапсуляции и проектирования по контрактам.

Решения[править]

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

См.также[править]

Запах кода

Пруф[править]

/web.archive.org/web/20160310082935/http://perldesignpatterns.com/?ObjectOrgy