Framework Design Guidelines

Конструкторы

Должны быть “ленивыми”. (Я видел код где классы состоит из одного конструктора, в котором делается всё)
Только заниматься инициализацией параметров.

Свойства

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

Свойство или метод

Используйте свойство если это атрибут типа.
Используйте метод если
- Это операция преобразования (типа ToString).
- Если есть побочный эффект (например вызов метода два раза подряд возвращает разные результаты).
- Если порядок выполнения важен.
- Если возвращается массив.
- Если операция требует достаточно времени для выполнения, и результат не возвращается сразу.

Расширения (Extensions)

Используйте расширения для добавления методов в интерфейс.
Используйте расширения для управления зависимостями.
Не используйте расширения для типов, которые являются не Вашими.
Помните что не все языки поддерживают расширения.
Избегайте добавление расширений в System.Object.

Абстрактные и базовые классы

Предпочитайте широкую и неглубокую иерархию типов.
Обязательства и ответственность тяжелее поддерживать в глубоких сложных иерархиях.
Делайте базовые классы не-конструируемыми, то есть используйте абстрактные классы.
- Чётко обозначьте для чего предназначен класс.
- Сделайте защищенный конструктор для под-классов.

Виртуальные методы

Недостаток – Владелец базового класса не контролирует что делают подклассы.
Преимущество – Не надо менять базовые классы по мере создания подклассов.
При переопределении методов следуйте обязательствам базового класса, не меняйте семантику
Каждый виртуальный метод должен иметь обязательства
Не требуйте от подклассов знания того что перекрывается

Виртуальные методы или не-виртуальные

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

Вызовы должны быть в том же порядке и такой же частоты
Не увеличивать/уменьшать количество входных/выходных параметров

Интерфейсы

1-2 метода вполне достаточно
интерфейс может быть определен в терминах других простейших интерфейсов

Уровни (Layers)

Избегайте нисходящих и горизонтальных зависимостей
Помещайте библиотечные классы (классы которые не передаются между компонентами) наверх иерархий (Debug, EventLog)
Вначале тесты – потом дизайн
Избегайте тяжелых зависимостей
Используйте инверсию зависимостей

Framework Design Guidelines For Brussels Users Group

Опубликовано Октябрь 22, 2009 в 12:11 пп · Автор Михаил · Ссылка
Рубрики: Программирование · Теги: design, framework, presentation