7. Критерии качества декомпозиции проекта

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

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

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

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

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

8. Понятие класса в ооп

Класс - тип данных, определяемый программистом, в котором объединяются структуры данных и функции их обработки.(поля и методы)

Модификаторы доступа предназначены для уточнения объявления класса. С их помощью можно определить область видимости класса, возможность его наследования, готовность класса в целом и отдельных его частей к работе (public, internal, protected, private, abstract, sealed, static)

Статический член класса реализуется без создания экземпляра.

Поле класса – константы и переменные, содержащиеся в классе.

Метод класса – операция или функция для выполнения действий с полями класса.

9. Понятие объекта в ооп

(экземпляр класса) - конкретная переменная типа данных класса.

Объект используется через интерфейс – совокупность правил доступа. Программный объект – это абстракция.

Важным свойством объекта является его обособленность. Т.о. объект – инкапсулированная абстракция с чётко определённым интерфейсом.

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

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