ук 03.001.02 2011

УК 03.001.01-2011 Учебный курс. Обучение. ООП.

Базовые понятия

Объектно-ориентированное программирование (ООП) – это методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определенного класса, а классы образуют иерархию наследования.

(КН 02.002-1995, стр. 52)

• Основным элементом абстракции являются объекты

• Каждый объект является экземпляром определенного класса

• Классы образуют иерархию наследования

Ключевые характеристики ООП

Абстракция выделяет существенные характеристики некоторого объекта, отличающие его от всех других видов объектов и, таким образом, четко определяет его концептуальные границы с точки зрения наблюдателя.

(КН 02.002-1995, стр. 55)

• Внешнее поведение

• Барьер абстракции

• Неоднозначность выделения абстракции

• Абстракция и объект реального мира – не одно и тоже (пример: вещественные числа и числа с плавающей точкой)

• Задача: является ли квадрат прямоугольником?

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

(КН 02.002-1995, стр. 63)

• Сокрытие данных лишь частный случай инкапсуляции

• Поведение представляется только с помощью методов

• Задача о множествах объектов

Модульность – это свойство системы, которая может была разложена на внутренне связные, но слабо связанные между собой модули.

(КН 02.002-1995, стр. 69)

• Что первично класс или модуль?

Иерархия – это упорядочивание абстракций, расположение их по уровням.

(КН 02.002-1995, стр. 71)

• “is a” (наследование)

• “part of” (агрегация, композиция)

Принципы ООП

Открыто-замкнутый принцип

• Инкрементная разработка;

• Количество строк кода, которые пишет программист, в единицу времени ограничено;

• Если изменяется существующий код, то, скорее всего, прироста функционала не происходит;

• Повторное использование.

Программная сущность (класс, модуль, функция и т.д.) должна быть открыта для расширения, но закрыта для модификаций.

(СТ 02.003-1995, стр. 1)

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

Поведение – это то, как объект действует и реагирует; поведение выражается в терминах состояния объекта и передачи сообщений.

(КН 02.002-1995, стр. 96) Необходимо избегать конструкций, которые создают закрытое

множество поведений: • switch (ПР 02.001) • Цепочка if/else (ПР 02.002) • Информация о типе во время выполнения (ПР 02.003) • Перечислимые типы (ПР 02.004) • Дублирование кода (ПР 01.001) • Все поля должны быть private (ПР 02.005) • Избегать использование глобальных переменных (ПР 01.002)

Пример 1: Геометрические фигуры

class Shape

{

private ShapeType itsType;

private void DrawSquare();

private void DrawCircle();

public static void DrawAllShapes(Shape[] list)

{

for(Shape s : list)

{

switch (s.itsType)

{

case square:

DrawSquare();

break;

case circle:

DrawCircle();

break;

}

}

}

}

interface Shape

{

void Draw();

}

class ShapeUtils

{

public static void DrawAllShapes(Shape[] list)

{

for(Shape s: list)

{

s.Draw();

}

}

}

class Square implements Shape

{

public void Draw()

{

}

}

Пример 2: Рубрикатор

switch (article.Rubric) { case Auto: case Realty: filterPanels.Add(ucSearchOptions); break; case Job: switch (article.TypeID) { case Resume: filterPanels.Add(ucSeniorityPanel); filterPanels.Add(ucPricePanel); filterPanels.Add(ucWorkSchedulePanel); break; case Vacancy: filterPanels.Add(ucSeniorityPanel); filterPanels.Add(ucPricePanel); filterPanels.Add(ucWorkSchedulePanel); break; case Education: filterPanels.Add(ucPricePanel); break; } break; }

siteRubricHelper.SetFilterOptions(panel);

public interface IRubricHelper

{

void SetFilterOptions(FilterPanel panel);

}

public class DefaultRubricHelper implements IRubricHelper

{

private FilterOptions ucSearchOptions;

public void SetFilterOptions(FilterPanel panel)

{

panel.Add(ucSearchOptions); }

}

Стратегическая замкнутость

• Замкнутость не может быть 100%

• Замкнутость должна быть стратегической

• Проектирование ради стратегической замкнутости

• Паттерны проектирования – типовые примеры, обеспечивающие определенные виды замкнутости

Принцип подстановки Б. Лисков

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

(СТ 02.004-1995, стр. 2)

Пример 3: RTTI

void Draw(Shape s)

{

if (s instanceof Point)

{

DrawPoint(s as Point);

}

else if (s instanceof Circle)

{

DrawCircle(s as Circle);

}

else if(s instanceof Square)

{

DrawSquare(s as Square);

}

}

Пример 4: Rectangle и Square class Rectangle

{

private double height;

private double width;

public double getHeight() { return height; }

public void setHeight(int value) { height = value; }

public double getWidth() { return width; }

public void setWidth(int value) { width = value; }

}

….

void f(Rectangle r)

{

r.setHeight (5);

r.setWidth (4);

Debug.Assert(r.getHeight() * r.getWidth() == 20);

}

class Square extends Rectangle

{

public void setHeight(int value)

{

super.setHeight(value);

super.setWidth(value);

}

public void setWidth(int value)

{

super.setHeight(value);

super.setWidth(value);

}

}

• Построенные абстракции нельзя проверить на корректность сами по себе. Такую проверку можно выполнить лишь в контексте клиентов, использующих данные абстракции.

• Заранее построить очень гибкую модель “про запас” нельзя!

• Лучше использовать прототипирование

Прототип – самый простой вариант чего-либо, но содержащий самый сложный компонент.

Принцип обращения зависимостей

Программа Copy void Copy()

{

int ch;

while ((ch = Keyboard()) != EOF)

{

WritePrinter(c);

}

}

enum OutputDevice

{

printer,

disk

};

void Copy(OutputDevice dev)

{

int c;

while ((c = ReadKeyboard()) != EOF)

{

if (dev == printer)

WritePrinter(c);

else

WriteDisk(c);

}

}

interface IReader

{

int Read();

}

interface IWriter

{

void Write(char) = 0;

}

…

void Copy(IReader r, IWriter w)

{

int c;

while((c=r.Read()) != EOF)

w.Write(c);

}

…

Схема зависимостей

• Высокоуровневые модули не должны зависеть от низкоуровневых модулей. И те, и те должны зависеть от абстракций.

• Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

(СТ 02.005-1995, 6)

СЛОИ

Пример 5: Лампочка

class Lamp

{

public void TurnOn() {…}

public void TurnOff() {…}

}

class Button

{

private Lamp lamp;

public Button(Lamp lamp) {this.lamp = lamp;}

public void Detect()

{

if(GetPhisicalState())

{

lamp.TurnOn();

}

else

{

lamp.TurnOff();

}

}

}

interface IButtonClient

{

void TurnOn();

void TurnOff();

}

class Button

{

private IButtonClient client;

public Button(IButtonClient client)

{

this.client = client;

}

public void Detect()

{

if (GetPhisicalState())

{

client.TurnOn();

}

else

{

client.TurnOff();

}

}

}

class Lamp

{

public void SwitchOn() {…}

public void SwitchOff() {…}

}

class LampAdapter implements IButtonClient

{

private Lamp lamp;

public LampAdapter(Lamp lamp)

{

this.lamp = lamp;

}

public void TurnOn()

{

lamp.SwitchOn();

}

public void TurnOff()

{

lamp.SwitchOff();

}

}

• Сторонний код должен быть скрыт за обертками, реализующими собственные интерфейсы (ПР 04.001)

• Обертки можно строить к старому наследуемому коду

• Переписывание не всегда самый лучший путь

Принцип соответствия интерфейсов

interface IButtonClient

{

void TurnOn();

void TurnOff();

}

Interface ITimerClient

{

void OnTimeout();

}

class Lamp implements IButtonCLient, ITimerClient

{

public void TurnOn() {…}

public void TurnOff() {…}

public void OnTimeout() {…}

}

class Button

{

private IButtonClient;

public Button(IButtonClient client) {…}

public void Detect() {…}

}

class Timer

{

private ITimerClient client;

public void Timeout()

{

…

client.OnTimeout();

…

}

}

class EmergencyLamp extends Lamp

{

public override void OnTimeout()

{

// нельзя включать и отключать по таймеру,

// поэтому пустая реализация

}

}

class Lamp implements IButtonClient

{

…

}

class ButtonToTimerClientAdapter implements ITimerClient

{

// см. пример адаптера для IButtonClient

}

Interface IEmergencyClient

{

void OnAlert();

}

class ButtonToEmergencyClientAdapter implements IEmergencyClient

{

// см. пример адаптера для IButtonClient

}

• ITimerClient, IEmergencyClient, IButtonCLient – это разные множества объектов, но которые частично пересекаются

• Жирные интерфейсы сигнализируют об ошибках в проектировании

• Жирных интерфейсов следует избегать (ПР 02.006) Исключение: применение паттерна Compositor

Клиенты не должны зависеть от тех интерфейсов, которые они не используют

(СТ 02.006-1996, стр. 5)

• Абстракции нельзя проверить сами по себе, вне контекста использования!!!

• Часто программисты делают предложения по функционалу, основываясь на текущих возможностях реализации

• Подход к программированию: программный код как результат решения конкретной задачи

• Подход к программированию: писать программный код как набор инструментов для решения задач

DI контейнеры как расширяемые фабрики

package examples.di;

public interface Greeting

{

String greet();

}

package examples.di.impl;

import examples.di.Greeting;

public class GreetingImpl implements Greeting

{

public String greet()

{

return "Hello World!";

}

}

package examples.di;

public interface GreetingClient

{

void execute();

}

package examples.di.impl;

import examples.di.Greeting;

import examples.di.GreetingClient;

public class GreetingClientImpl implements GreetingClient

{

private Greeting greeting;

public GreetingClientImpl(Greeting greeting) { this.greeting = greeting; }

public void execute() { System.out.println(greeting.greet()); }

}

package examples.di.main;

import examples.di.Greeting;

import examples.di.impl.GreetingClientImpl;

import examples.di.impl.GreetingImpl;

public class GreetingMain

{

public static void main(String[] args)

{

Greeting greeting = new GreetingImpl();

GreetingClientImpl greetingClient = new GreetingClientImpl(greeting);

greetingClient.execute();

}

}

package examples.di.main;

import org.seasar.framework.container.S2Container;

import org.seasar.framework.container.factory.S2ContainerFactory;

import examples.di.GreetingClient;

public class GreetingMain3

{

private static final String PATH = "examples/di/dicon/GreetingMain3.dicon";

public static void main(String[] args)

{

S2Container container = S2ContainerFactory.create(PATH);

GreetingClient greetingClient = new GreetingClientImpl( container.getComponent("greeting”)

);

greetingClient.execute();

}

}

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE components PUBLIC"-//SEASAR//DTD S2Container 2.3//EN" "http://www.seasar.org/dtd/components23.dtd"> <components> <include path="aop.dicon"/> <component name="greeting” class="examples.di.impl.GreetingImpl"> <aspect>aop.traceInterceptor</aspect> </component> </components>

package examples.di.impl;

import examples.di.Greeting;

import examples.di.GreetingClient;

public class GreetingClientImpl implements GreetingClient

{

private Greeting greeting;

public GreetingClientImpl()

{

S2Container container = S2ContainerFactory.create(PATH);

this.greeting = container.getComponent("greeting”);

}

public void execute() { System.out.println(greeting.greet()); }

}

Принцип единой ответственности

Должна быть ровно одна причина для изменения класса

• Классы должны быть компактными (ПР 02.007)

• Следует избегать глубоких иерархий классов (ПР 02.008)

Компоновка программы

• Разделяй и властвуй

• Структурирование

• Разная структура для разных объемов

• План выполнения запросов

• Объявления

Модули

Каков критерий разбиения программы на модули?

Взаимосвязи между модулями? Принцип организации взаимосвязей?

Что первично: классы или модули?

Каким программным конструкциям соответствуют модули?

Какие цели преследуют модули?

Принципы сцепления модулей

Принцип эквивалентности единиц повторного использования и релиза

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

(СТ 02.007-1996, стр. 4)

Обобщенный принцип повторного использования

Классы, входящие в состав модуля повторно используются все вместе. Если Вы повторно используете один, то Вам доступны все остальные.

(СТ 02.007-1996, стр. 5)

Обобщенный принцип замкнутости

Классы, входящие в состав пакета, должны быть закрыты по отношению к одним и тем же изменениям. Изменение, влияющее на пакет, оказывает воздействие на все классы, входящие в этот пакет (на затрагивая другие пакеты)

(СТ 02.007-1996, стр. 6)

• В .Net модулем является сборка

• Разнесение классов по модулям нетривиальная задача

• Методы разнесения классов по модулям носит динамический характер

• Сначала создаются классы, затем выделяются модули

• Движущая сила: смещения акцента от возможности разработки до возможности повторного использования

• Один класс в одном файле (ПР 05.001)

Принципы связывания пакетов

Принцип ациклических зависимостей.

Граф зависимостей между модулями должен быть ациклическим

(СТ 02.007-1996, стр. 6)

Пример 5: Ациклический граф

Пример 6: Циклический граф

Интеграционная штурмовщина

• Еженедельный билд

• Не успеваем вовремя его собрать, протестировать

• Большие накладные расходы на сборку билда

• Увеличиваются сроки между билдами

• Модули можно разрабатывать независимо друг от друга

• Релиз системы состоит из набора модулей, каждый из которых имеет свою версию

• Product Manager

Стабильность

• Какие цели преследуют модули?

• Пример: программа копирования

• “Хорошая” зависимость – это зависимость от чего-то, что не слишком часто меняется

• Как измерить насколько зависимость хорошая?

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

(Wikipedia.org)

Принцип стабильных зависимостей

Модули должны зависеть только от более стабильных модулей.

(СТ 02.008-1996, стр. 8)

• Дизайн системы не может быть полностью стабильным

• Принцип обобщенной замкнутости

• Принцип единственной ответственности

Метрики стабильности

• Центростремительная связность (Ca) – количество классов за пределами модуля, которые зависят от классов внутри модуля

• Центробежная связность (Ce) – количество классов внутри модуля, которые зависят от классов за пределами модуля

• Коэффициент нестабильности (I): I = Ce/(Ce+Ca) – I = 0 – максимально стабильный пакет

– I = 1 – максимально нестабильный пакет

Принцип стабильных абстракций

Модули, которые максимально стабильны должны быть максимально абстрактны. Нестабильные модули должны быть конкретны. Абстрактность модуля должна быть обратно пропорциональна нестабильности.

(СТ 02.008-1996, стр. 11)

Абстрактность модуля = Абстрактные классы и интерфейсы/Общее число классов и интерфейсов

Итоги

• Изменения через написание нового без переписывания старого

• Полностью от переписывания отказаться нельзя, поэтому важно проектировать систему

• Цель проектирования – управлять замкнутостью

• Проектирование предшествует программированию

• Сначала классы, а потом модули

• Нет интеграционной штурмовщине

• Важно правильно разбивать систему на модули

• Интерфейсы рулят

• Проектирование – Design Patterns

– Прототипирование как средство уменьшения рисков

• Существующий код – Рефакторинг

– Фасады

– Автоматическое тестирование

Что дальше

• Контрактная модель программирования

• Design Patterns

• Рефакторинг

• Автоматическое тестирование

Вопросы?