Словарик философствующего информатика: различия между версиями

Содержимое удалено Содержимое добавлено
Исправлена описка.
разбиение на строки небольшой ширины
Строка 345:
 
Суть вопроса - неизбежность сложности. Методы борьбы со сложностью:
 
- Модульность. Разбиение ПС на модули - наборы процедур (алгоритмов, объектов), выполняющих связанную функциональность. Если программисту нужно обратиться (проанализировать, изменить) к некой реализованной функциональности, то он откроет конкретный модуль, который реализует эту функциональность. Снижается сложность для анализа.
Модульность. Разбиение ПС на модули - наборы процедур (алгоритмов, объектов),
- Обеспечение независимости модулей системы. Если в одной части функциональности происходят изменения, а она тесно связана с другой функциональностью (явным образом использует сущности, предпосылки, связанные с изменившейся функциональностью), то по ПС прокатится "волна изменений". Необходимо будет анализировать и изменять не один модуль, а несколько связанных. Если же заранее сделать модули независимыми, то потребуются изменения только в конкретных интерфейсах модулей (местах передачи входных параметров для функциональности модуля). Снижается сложность для изменений.
выполняющих связанную функциональность. Если программисту нужно обратиться
- Повторное использование. Если алгоритм успешно реализован в одной части ПС, а затем требуется в другой части, то хорошо бы использовать уже реализованное, изменяя лишь отдельные входные параметры алгоритма. Можно заранее выделить функциональность, сделав её универсальной. Снижается сложность замены функциональности.
(проанализировать, изменить) к некой реализованной функциональности, то он откроет
- Использование иерархических структур. Если группа сущностей имеет одинаковые свойства (поведение), то общую часть можно заранее выделить в отдельную сущность, реализующую универсальные алгоритмы. Снижается сложность создания новых сущностей (адаптации системы).
конкретный модуль, который реализует эту функциональность. Снижается сложность для анализа.
 
Обеспечение независимости модулей системы. Если в одной части функциональности происходят
изменения, а она тесно связана с другой функциональностью (явным образом использует сущности,
предпосылки, связанные с изменившейся функциональностью), то по ПС прокатится "волна
изменений". Необходимо будет анализировать и изменять не один модуль, а несколько связанных.
Если же заранее сделать модули независимыми, то потребуются изменения только в конкретных
интерфейсах модулей (местах передачи входных параметров для функциональности модуля).
Снижается сложность для изменений.
 
Повторное использование. Если алгоритм успешно реализован в одной части ПС, а
затем требуется в другой части, то хорошо бы использовать уже реализованное, изменяя
лишь отдельные входные параметры алгоритма. Можно заранее выделить функциональность,
сделав её универсальной. Снижается сложность замены функциональности.
 
Использование иерархических структур. Если группа сущностей имеет одинаковые
свойства (поведение), то общую часть можно заранее выделить в отдельную сущность,
реализующую универсальные алгоритмы. Снижается сложность создания новых сущностей (адаптации системы).
<!--
=== Абстракция ===