суббота, 11 февраля 2012 г.

Об иерархиях наследования

Очередная интересная мысль от Бертрана Мейера, на этот раз касается она проектирования иерархий объектов:

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

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

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

4 комментария:

  1. В точку. Аккурат к недавнему холивару на RSDN "Что не так с ООП" :) И как всегда типичный ответ: с "серебрянными пулями все в порядке", "плохо с головами, которых их ищут".

    ОтветитьУдалить
    Ответы
    1. +100 500. В ООП самым сложным все еще остается поиск абстракций. А уж когда они найдены все эти классы делаются на ура. А вот как их найти в данном конкретном случае... Тут и опыт, и интуиция нужны.

      Удалить
    2. ООП тут не причем сам по себе, имхо, конечно. Все таки иерархия это завсегда будет некая классификация. А классификация сама по себе азмь езмь функция целевая. Зачем нам нужна классификация, именно это и определяет как именно она будет делаться эта классификация (в нашем случае иерархия). В одном случае целесообразно одно, в другом другое...

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

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

      Удалить
  2. Да, очень правильно. Практически любая попытка программировать в стиле "cat and dog are animals" разбивается о тот факт, что cat does not bark, and dog does not meow.

    ОтветитьУдалить