 |
Одиночка. Загрузка по требованию.
|
|
|
|
Одиночка – экземпляр класса в коде в единичном кол-ве.
Гарантирует, что у класса есть только один экземпляр, и предоставляет к нему глобальную точку доступа. Существенно то, что можно пользоваться именно экземпляром класса, так как при этом во многих случаях становится доступной более широкая функциональность. Например, к описанным компонентам класса можно обращаться через интерфейс, если такая возможность поддерживается языком.
Плюсы:
-контролируемый доступ к единственному экземпляру;
-уменьшение числа имён;
-допускает уточнение операций и представления;
-допускает переменное число экземпляров;
-бо́льшая гибкость, чем у операций класса.
Загрузка по треб. – внешние объекты не будут знать, загружен ли файл и не будут проверять.
Public a
{
Get{
If b == null
Команда. Шаблонный метод.
Команда — шаблон проектирования, используемый при объектно-ориентированном программировании, представляющий действие. Объект команды заключает в себе само действие и его параметры.
Создание структуры, в которой класс-отправитель и класс-получатель не зависят друг от друга напрямую. Организация обратного вызова к классу, который включает в себя класс-отправитель.
Паттерн поведения объектов,известен так же под именем Action(действие).
Обеспечивает обработку команды в виде объекта, что позволяет сохранять её, передавать в качестве параметра методам, а также возвращать её в виде результата, как и любой другой объект.
Например, библиотека печати может иметь класс PrintJob. Для его использования можно создать объект PrintJob, установить необходимые параметры, и вызвать метод, непосредственно отсылающий задание на печать.
|
|
|
Шаблонный метод — паттерн поведения классов, шаблон проектирования, определяющий основу алгоритма и позволяющий наследникам переопределять некоторые шаги алгоритма, не изменяя его структуру в целом.
-Однократное использование инвариантной части алгоритма, с оставлением изменяющейся части на усмотрение наследникам.
-Локализация и вычленение общего для нескольких классов кода для избегания дублирования.
-Разрешение расширения кода наследниками только в определенных местах.
Фасад. Компоновщик.
Фасад - шаблон проектирования, позволяющий скрыть сложность системы путем сведения всех возможных внешних вызовов к одному объекту, делегирующему их соответствующим объектам системы. Применяется для установки некоторого рода политики по отношению к другой группе объектов. Если политика должна быть яркой и заметной, следует воспользоваться услугами шаблона Фасад. Если же необходимо обеспечить скрытность и аккуратность (прозрачность), более подходящим выбором является шаблон Заместитель (Proxy).
Компоновщик — шаблон проектирования, относится к структурным паттернам, объединяет объекты в древовидную структуру для представления иерархии от частного к целому. Компоновщик позволяет клиентам обращаться к отдельным объектам и к группам объектов одинаково.
Цель: Паттерн определяет иерархию классов, которые одновременно могут состоять из примитивных и сложных объектов, упрощает архитектуру клиента, делает процесс добавления новых видов объекта более простым.
Рефакторинг. Основные идеи.
Рефакторинг — процесс изменения внутренней структуры программы, не затрагивающий её внешнего поведения и имеющий целью облегчить понимание её работы[1]. В основе рефакторинга лежит последовательность небольших эквивалентных (то есть сохраняющих поведение) преобразований. Поскольку каждое преобразование маленькое, программисту легче проследить за его правильностью, и в то же время вся последовательность может привести к существенной перестройке программы и улучшению её согласованности и четкости.
|
|
|
Цель рефакторинга — сделать код программы легче для понимания; без этого рефакторинг нельзя считать успешным.
Рефакторинг следует отличать от оптимизации производительности. Как и рефакторинг, оптимизация обычно не изменяет поведение программы, а только ускоряет её работу. Но оптимизация часто затрудняет понимание кода, что противоположно рефакторингу.
Рефакторинг нужно применять постоянно при разработке кода. Основными стимулами его проведения являются следующие задачи:
-необходимо добавить новую функцию, которая недостаточно укладывается в принятое архитектурное решение;
-необходимо исправить ошибку, причины возникновения которой сразу не ясны;
-преодоление трудностей в командной разработке, которые обусловлены сложной логикой программы.
Во многом при рефакторинге лучше полагаться на интуицию, основанную на опыте. Но можно выделить наиболее очевидные причины, когда код нужно подвергнуть рефакторингу:
-дублирование кода;
-длинный метод;
-большой класс;
-длинный список параметров;
-«завистливые» функции — это метод, который чрезмерно обращается к данным другого объекта;
-избыточные временные переменные;
-классы данных;
-несгруппированные данные.
Модульное тестирование.
Виды тестирования:
-отладка
-функциональное тестирование
-модульное тестирование
Модульное тестирование
Т.к. система большая и сложная => можно автоматически протестировать каждый модуль и, если все работает правильно => и вся система работает правильно.
-для модульного тестирования обычно создается отдельный проект.
-классы с тестами должны быть открыты (public).
-[TextFixture] – пометка, что это модульный тест.
-[Test]-пометка, что это тест.
TDD – метод, при котором пишутся тесты, а потом сам код.
Модульные тесты хорошо работают с БД.
MVC. Наблюдатель.
MVC - схема использования нескольких шаблонов проектирования, с помощью которых модель данных приложения, пользовательский интерфейс и взаимодействие с пользователем разделены на три отдельных компонента так, что модификация одного из компонентов оказывает минимальное воздействие на остальные. Данная схема проектирования часто используется для построения архитектурного каркаса, когда переходят от теории к реализации в конкретной предметной области.
|
|
|
Основная цель применения этой концепции состоит в разделении бизнес-логики (модели) от её визуализации (представления, вида). За счет такого разделения повышается возможность повторного использования. Наиболее полезно применение данной концепции в тех случаях, когда пользователь должен видеть те же самые данные одновременно в различных контекстах и/или с различных точек зрения. В частности, выполняются следующие задачи:
-К одной модели можно присоединить несколько видов, при этом не затрагивая реализацию модели. Например, некоторые данные могут быть одновременно представлены в виде электронной таблицы, гистограммы и круговой диаграммы.
-Не затрагивая реализацию видов, можно изменить реакции на действия пользователя (нажатие мышью на кнопке, ввод данных), для этого достаточно использовать другой контроллер.
-Ряд разработчиков специализируются только в одной из областей: или разрабатывают графический интерфейс или разрабатывают бизнес-логику. Поэтому возможно добиться, что программисты, занимающиеся разработкой бизнес-логики (модели), вообще не будут осведомлены о том, какое представление будет использоваться.
Наблюдатель — поведенческий шаблон проектирования. Также известен как «подчинённые» (Dependents), «издатель-подписчик» (Publisher-Subscriber).
Определяет зависимость типа «один ко многим» между объектами таким образом, что при изменении состояния одного объекта все зависящие от него оповещаются об этом событии.
Шаблон «наблюдатель» применяется в тех случаях, когда система обладает следующими свойствами:
существует, как минимум, один объект, рассылающий сообщения
имеется не менее одного получателя сообщений, причём их количество и состав могут изменяться во время работы приложения.
нет надобности очень сильно связывать взаимодействующие объекты, что полезно для повторного использования.
Данный шаблон часто применяют в ситуациях, в которых отправителя сообщений не интересует, что делают получатели с предоставленной им информацией.
|
|
|
