Разделение интересов

Диаграмма, иллюстрирующая принцип разделения задач, согласно которому сущность действия может содержать только один тип задач.

В информатике разделение задач — это принцип разделения компьютерной программы на отдельные разделы. Каждый раздел посвящен отдельной проблеме — набору информации, которая влияет на код компьютерной программы. Проблема может быть как общей, например «детали аппаратного обеспечения приложения», так и конкретной, например «имя класса, экземпляр которого нужно создать ». Программа, которая хорошо воплощает SoC, называется модульной. [1] программа. Модульность и, следовательно, разделение задач достигается за счет инкапсуляции информации внутри раздела кода, имеющего четко определенный интерфейс. Инкапсуляция — это средство сокрытия информации . [2] Многоуровневые конструкции в информационных системах являются еще одним вариантом разделения задач (например, уровень представления, уровень бизнес-логики, уровень доступа к данным, уровень персистентности). [3]

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

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

Реализация [ править ]

Механизмы модульного или объектно-ориентированного программирования, предоставляемые языком программирования, — это механизмы, которые позволяют разработчикам предоставлять SoC. [4] Например, объектно-ориентированные языки программирования, такие как C# , C++ , Delphi и Java, могут разделять задачи на объекты архитектурного , а шаблоны проектирования, такие как MVC или MVP, могут отделять представление и обработку данных (модель) от контента . Сервис-ориентированный дизайн позволяет разделить задачи на услуги . Языки процедурного программирования, такие как C и Pascal, позволяют разделять задачи на процедуры или функции . Аспектно-ориентированные языки программирования могут разделять задачи на аспекты и объекты .

Разделение задач является важным принципом проектирования и во многих других областях, таких как городское планирование , архитектура и информационный дизайн . [5] Цель состоит в том, чтобы более эффективно понимать, проектировать и управлять сложными взаимозависимыми системами, чтобы функции можно было повторно использовать, оптимизировать независимо от других функций и изолировать от потенциальных сбоев других функций.

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

Происхождение [ править ]

Термин «разделение интересов» , вероятно, был введен Эдсгером В. Дейкстрой в его статье 1974 года «О роли научной мысли». [6]

Позвольте мне попытаться объяснить вам, что, на мой взгляд, характерно для всякого разумного мышления. Это значит, что человек готов глубоко изучить какой-то аспект своего предмета изолированно ради его собственной последовательности, все время зная, что он занимается только одним из аспектов. Мы знаем, что программа должна быть правильной, и можем изучать ее только с этой точки зрения; мы также знаем, что оно должно быть эффективным, и мы можем изучить его эффективность, так сказать, в другой день. В другом настроении мы можем спросить себя, желательна ли эта программа, и если да, то почему. Но ничего не получится – наоборот! – если одновременно заниматься этими различными аспектами. Это то, что я иногда называю «разделением интересов», которое, хотя и не вполне возможно, тем не менее является единственным известным мне доступным методом эффективного упорядочения мыслей. Это то, что я имею в виду под «сосредоточением внимания на каком-то аспекте»: это не означает игнорирования других аспектов, это просто отдает должное тому факту, что с точки зрения этого аспекта другой не имеет значения. Это одно- и многонаправленное мышление одновременно.

Пятнадцать лет спустя стало очевидно, что термин «разделение ответственности» становится общепринятой идеей. В 1989 году Крис Рид написал книгу « Элементы функционального программирования». [7] который описывает разделение задач:

Программисту приходится делать несколько вещей одновременно, а именно:

  1. описать, что необходимо вычислить;
  2. организовать последовательность вычислений на небольшие шаги;
  3. организовать управление памятью во время вычислений.

Рид продолжает говорить:

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

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

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

Примеры [ править ]

Стек интернет-протоколов [ править ]

Разделение задач имеет решающее значение для проектирования Интернета. В пакете Internet Protocol Suite были приложены большие усилия для разделения проблем на четко определенные уровни . Это позволяет разработчикам протоколов сосредоточиться на проблемах одного уровня и игнорировать другие уровни. Например, протокол SMTP прикладного уровня заботится обо всех деталях проведения сеанса электронной почты через надежный транспортный сервис (обычно TCP ), но ни в малейшей степени не заботится о том, как транспортный сервис делает этот сервис надежным. Точно так же TCP не заботится о маршрутизации пакетов данных, которая обрабатывается на уровне Интернета .

HTML, CSS, JavaScript [ править ]

Язык разметки гипертекста (HTML), каскадные таблицы стилей (CSS) и JavaScript (JS) — это взаимодополняющие языки, используемые при разработке веб-страниц и веб-сайтов. HTML в основном используется для организации содержимого веб-страницы, CSS используется для определения стиля представления контента, а JS определяет, как контент взаимодействует и ведет себя с пользователем. Исторически это было не так: до появления CSS HTML выполнял обе обязанности по определению семантики и стиля.

Предметно-ориентированное программирование [ править ]

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

Аспектно-ориентированное программирование [ править ]

Аспектно-ориентированное программирование позволяет сквозные проблемы решать как первоочередные. Например, большинству программ требуется определенная форма безопасности и журналирования . Безопасность и ведение журналов часто являются второстепенными задачами, тогда как основная задача часто связана с достижением бизнес-целей. Однако при разработке программы ее безопасность должна быть заложена в нее с самого начала, а не рассматриваться как второстепенная задача. Последующее применение безопасности часто приводит к недостаточной модели безопасности, которая оставляет слишком много брешей для будущих атак. Эту проблему можно решить с помощью аспектно-ориентированного программирования. Например, можно написать аспект, обеспечивающий, чтобы вызовы определенного API всегда регистрировались или чтобы ошибки всегда регистрировались при возникновении исключения, независимо от того, обрабатывает ли процедурный код программы исключение или распространяет его. [8]

анализа в искусственном Уровни интеллекте

В когнитивной науке и искусственном интеллекте принято ссылаться на уровни анализа Дэвида Марра . В любой момент времени исследователь может сосредоточиться на том, (1) что должен вычислить тот или иной аспект интеллекта, (2) какой алгоритм он использует или (3) как этот алгоритм реализован на аппаратном уровне. Такое разделение задач похоже на различие между интерфейсом и реализацией в разработке программного и аппаратного обеспечения.

Нормализованные системы [ править ]

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

SoC через частичные классы [ править ]

Разделение задач можно реализовать и обеспечить с помощью частичных классов . [9]

SoC через частичные классы в Ruby [ править ]

Bear_hunting.rb 
class Bear
  def hunt
    forest.select(&:food?)
  end
end
Bear_eating.rb 
class Bear
  def eat(food)
    raise "#{food} is not edible!" unless food.respond_to? :nutrition_value
    food.nutrition_value
  end
end
Bear_hunger.rb 
class Bear
  attr_accessor :hunger
  def monitor_hunger
    if hunger > 50
      food = hunt
      hunger -= eat(food)
    end
  end
end

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

Ссылки [ править ]

  1. ^ Лапланте, Филипп (2007). Что должен знать каждый инженер о программной инженерии . ЦРК Пресс. ISBN  978-0-8493-7228-5 .
  2. ^ Митчелл, Р.Дж. (1990). Управление сложностью в разработке программного обеспечения . ИЭЭ. п. 5. ISBN  0-86341-171-1 .
  3. ^ Руководство по архитектуре приложений Microsoft . Майкрософт Пресс. 2009. ISBN  978-0-7356-2710-9 .
  4. ^ Художник Роберт Ричард (2006). «Планы программного обеспечения: многомерное детальное разделение задач». CiteSeerX   10.1.1.110.9227 .
  5. ^ Гарофало, Рафаэле (2011). Создание корпоративных приложений с помощью Windows Presentation Foundation и шаблона представления модели ViewModel . Майкрософт Пресс. п. 18. ISBN  978-0-7356-5092-3 .
  6. ^ Дейкстра, Эдсгер В. (1982). «О роли научной мысли» . Избранные статьи о вычислительной технике: личный взгляд . Нью-Йорк, штат Нью-Йорк, США: Springer-Verlag. стр. 60–66 . ISBN  0-387-90652-5 .
  7. ^ Рид, Крис (1989). Элементы функционального программирования . Бостон, Массачусетс, США: Аддисон-Уэсли Лонгман. ISBN  0-201-12915-9 .
  8. ^ Джесс Нильсен (июнь 2006 г.). «Создание безопасных приложений» (PDF) . Проверено 8 февраля 2012 г.
  9. ^ Тьяго Диас (октябрь 2006 г.). «Hyper/Net: поддержка MDSoC для .NET» (PDF) . ДСОА 2006 . Проверено 25 сентября 2007 г.

Внешние ссылки [ править ]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Separation_of_concerns&oldid=1214678067"