Разрушает ли архитектура уровня ОО концепцию инкапсуляции - PullRequest
2 голосов
/ 27 февраля 2009

У меня есть многоуровневое приложение с уровнем представления, бизнес-уровнем, DAL и уровнем бизнес-объектов. Разделение объектов и операции над объектами нарушают объектно-ориентированную концепцию инкапсуляции.

Ответы [ 4 ]

2 голосов
/ 27 февраля 2009

Нет. Подумайте, что означает «инкапсуляция»: детали реализации класса скрыты за интерфейсом (сообщениями или методами) класса.

Фактически, вы можете вывести n-уровневую архитектуру непосредственно из ОО-принципов и закона Парнаса: модуль должен заключать в себе то, что может измениться. Уровень представления инкапсулирует детали создания «видимого» интерфейса; средний уровень - модель самого бизнеса; и серверная часть - детали доступа к постоянному хранилищу данных.

1 голос
/ 27 февраля 2009

Возьмите этот пример, взятый из этой статьи :

public class Position
{
  public double distance( Position position )
  {
    // calculate and return distance...
  }

  public double heading( Position position )
  {
    // calculate and return heading...
  }

  public double latitude;
  public double longitude;
}

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

Напротив, Стив Макконнелл в Code Complete (2-е изд., Раздел 6.2, Хорошая инкапсуляция) будет утверждать, что инкапсуляция нарушена, потому что данные о членах открыты.

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

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

Или, как говорит Википедия :

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

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

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

0 голосов
/ 27 февраля 2009

Это действительно замечательная точка AP!

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

С другой стороны, некоторые вещи полезны для разложения, такие как объект для отправки запросов в базу данных и т. Д.

Я думаю, что во многих случаях должен быть аргумент, чтобы лучше "инкапсулировать" веб-страницу, чтобы большая часть функциональности содержалась в одном объекте или в меньшем количестве объектов. Таким образом, более «ориентированный на страницы» подход, а не рассеяние логики среди огромного множества классов.

Я думаю, что это жизненно важный вопрос, который мы всегда должны задавать себе в каждой системе, которую мы проектируем, - сколько нужно абстрагироваться? Сколько стоит конкретизировать? Как эффективно разложить систему на классы.

0 голосов
/ 27 февраля 2009

Два не совпадают. Архитектура больше относится к модулям (группам классов). Инкапсуляция относится к сокрытию внутренней работы класса. Вы можете иметь и то и другое, если спроектируете свою систему достаточно хорошо.

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

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

Что касается вашего комментария ниже, логика определенно должна быть в самом классе сотрудников. Я бы подверг сомнению логику наличия отдельного слоя для бизнес-объектов. Часто возникает искушение определять классы типа «Сотрудник», потому что они моделируют объекты или концепции реального мира. Однако вашей мотивацией для определения класса не должно быть «моделирование объекта реального мира».

Вы должны определить назначение вашего модуля (почему у вас есть слой бизнес-логики? Чтобы содержать всю бизнес-логику.) И затем поместить туда то, что вам нужно. Если класс «Сотрудник» - это класс, который должен вычислять бизнес-логику, то он должен перейти в класс бизнес-логики. Если нет, то он должен перейти в ваш класс бизнес-объектов (что бы это ни было). Если ему нужно сделать две разные вещи, и, следовательно, он может поместиться в два слоя, рассмотрите возможность разделения его на два класса - помните, что вашим объектам не нужно моделировать вещи реального мира. Роберт С. Мартин предлагает определить ваши классы так, чтобы границы классов были границами цели.

...