Кроме исходных (в данном случае банки и ипотечные компании) основных объектов, вы можете также определить (сформулировать) вспомогательные объекты, взаимодействующие с исходными объектами. Эти вспомогательные объекты составят свой класс. Пусть таким классом будет институт ссуд, а его объектами - объекты-ссуды, которые будут представлять конкретные ссуды конкретных физических кредиторов. Институт ссуд может иметь любые свойства и методы. Он, например, может иметь свойства Amount (Величина), Rate (Процент) и Lender (Кредитор ). Когда возможность давать ссуду продана другой организации (например, ипотечная компания – банку), значение свойства Lender объекта-ссуды, представляющего конкретную ссуду, должно быть изменено (вместо ипотечной компании кредитором будет банк), но вся другая информация должна быть сохранена внутри этого объекта-ссуды. Ясно, что этот класс позволяет выделить и обобщить ряд важных характеристик в одно целое – институт ссуды. Теперь другие программные единицы могут иметь дело не с кодами разных физических организаций-кредиторов, а со специальным институтом ссуды и его объектами. Отдельные объекты-ссуды далее могут быть привязаны к другим физическим объектам, например клиентам, так как каждая ссуда предполагает такого клиента.
Добавляйте только необходимое. Возможно, что рассматриваемые организации и институты обладают многими другими активностями, которые не представляют интереса для вашего случая. Поэтому на этапе проектирования нужно определить, какие операции и данные объект должен включать в соответствии с проблемой.
Управление данными. Объект инкапсулирует (содержит внутри себя) модель (дается определениями-формулировками класса, подкласса и объекта), которая задает управление данными, находящимися в распоряжении объекта. Если объект является, например, кредитной организацией, всё поведение такой организации, которое требуется для вашего приложения при работе с данными, должно отображаться этим объектом. При необходимости объекты могут изменить свое поведение модификацией объектных методов. Последнее упрощает управление данными, которые использованы в конкретном приложении.
ObjectsManageInternalState (Объекты управляют внутренним состоянием)
В тривиальном смысле объекты являются структурами данных, которые инкапсулируют (прячут) внутреннее объектное состояние, к которому вы обращаетесь посредством операций-методов. Когда вы привлекаете метод, он точно определяет (диктует), что делать с данными. При этом два объекта одного класса могут выполнять разные варианты кодов для вызванного ими общего метода, поскольку состояния этих объектов могут быть различны. Внутренний механизм любого объекта обычно автономен и не определяется какой-либо частью внешней программы, которая при работе с ним просто использует интерфейс, представляемый ей объектом.
Сокрытие внутреннего состояния объектов от посторонних программ дает более устойчивый код. Если, например, значение свойства Lender объекта-ссуды может изменяться только объектным методом newLender (новый кредитор), случайный доступ извне менее вероятен по сравнению с тем, когда информационные данные по ссуде хранятся в ячейках обычного массива, и любое внешнее индексное выражение может извлечь или изменить их (обычные типы данных доступны любым программам).
Объекты обеспечивают некоторое число полезных возможностей, которые не достижимы обычными MATLAB-структурами и ячейками массивов. Например, объекты позволяют:
w тестировать величины при любом назначении данных тому или иному свойству посредством выполнения соответствующей функции;
w рассчитывать величину свойства только тогда, когда она запрашивается; при этом не требуется хранение таких величин, поскольку они постоянно зависимы от других данных;
w передавать сообщения, когда запрашивается или изменяется любая величина какого-либо свойства, на которые любое количество приемников сообщений (слушателей) могут реагировать выполнением некоторых функций (callback-функций);
w ограничить доступ к любым свойствам и методам.
Reducing Redundancy (Ограничение избыточности)
Когда сложность вашей программы возрастает, преимущество объектно-ориентированной разработки становится более очевидным. Предположим, вам необходимо выполнить следующую процедуру:
1. Контроль входов;
2. Расчет по первому входному аргументу;
3. Преобразование результата шага 2, базируясь на втором входном аргументе;
4. Контроль правильности выходов и возвращаемых величин.
Эта простая процедура может быть выполнена как обычная функция. Теперь предположим, что нужно использовать эту процедуру вновь в вашем приложении, но шаг 2 должен быть иным. Вы можете просто скопировать шаги исполнения и затем переписать шаг 2. Или создать функцию, которая принимает опцию, указывающую, какой расчет сделать, и т.д. Однако этот путь приводит к все более сложному коду.
Объектно-ориентированная разработка может упростить решение задачи путем факторизации (задание конкретных элементов) кода базового класса при частном обращении к нему с учетом конкретной ситуации. Базовый класс должен определять только общие инструкции, рекомендуемые всем производным формам, которые используют этот код. Шаг 2 в последнем примере может быть определен при этом синтаксически (общими указаниями) - не как исполняемый, позволяя это делать тем формам, на которые возлагается непосредственная реализация шага, определяемая на момент обращения к общему алгоритму. Например:
Шаг 1:
functioncheckInputs() % Начало функции checkInputs (в
% скобках должны быть входные аргументы).
… % actual implementation (действительное исполнение). Здесь
% расположены строки рабочего кода функции
% checkInputs, так как при каждом обращении к коду
% этого шага не предполагается его изменять.
end
Шаг 2:
function results = computeOnFirstArg() % results –
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.