Есть ли литература по этому типу программирования? - PullRequest
19 голосов
/ 05 августа 2010

В колледже я взял урок по современной физике, в котором мы узнали об особой теории относительности.Я был полностью потрясен тем, как разные системы отсчета могут реально наблюдать, как физические свойства объекта различны и не могут быть неверными.Со временем эта концепция постепенно меняла способ программирования, и теперь я стремлюсь разбить классы на 2 основные категории: объекты данных и объекты наблюдения (только для функций).

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

Во-первых, возьмем, к примеру, такой тип кода, который я часто писал:

class Deck
{
    private Card[] cards;

    public void Shuffle()
    {
        // shuffle algorithm
    }

    // other deck related functions like draw, cut, etc...
}

Обычно я пишу такой же сценарий, как:

class Deck
{
    // by intention, i just mean some kind of immutable collection of cards
    private ReadonlyCollection<Card> _Cards;

    public Card[] Cards { get { return this._Cards; } }
}

interface IDeckHandler
{
    Deck Shuffle(Deck deck);
    // other deck related functions like draw, cut, etc..
}

class Dealer : IDeckHandler
{
    // IDeckHandler implementation
}

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

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

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

Ответы [ 8 ]

10 голосов
/ 05 августа 2010

Мне кажется, что вы реализуете функциональное программирование ООП.Независимо от объяснения физики об «специальной теории относительности», вся идея ООП в основном заключается в инкапсуляции - вы хотите, чтобы объекты сами знали, как все должно быть сделано.По сути, вы говорите: «Нет, есть только данные и функции, которые работают с данными».Что если колода изменится?Вы получаете нового дилера?как вы узнаете, какой дилер должен быть создан для раздачи новой колоды?

Если вы подумали о выражении «switch», то вы вбиваете концепции ООП в шаблон функционального программирования.

6 голосов
/ 05 августа 2010

Некоторые аспекты этого стиля программирования описаны в Data-Oriented Programming (стиль разработки, который фокусируется на макете и преобразовании данных).

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

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

Кроме того, поскольку вызов IDeckShuffler.Shuffle (...) происходит изнутри колоды, колода имеет доступ ко всем скрытым полям и инкапсулированному состоянию.Таким образом, вы можете предоставить детали минимум реализации колоды Shuffler вместо того, чтобы по умолчанию передавать колоду.Вместо этого вы можете передать IEnumerable<Card> или что-то еще менее конкретное, в отличие от передачи всей сумки данных по умолчанию.

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

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

5 голосов
/ 06 августа 2010

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

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

Объекты Контейнера данных проявляются как сущности, объекты модели, объекты значений, объекты передачи данных и т. Д.

Хорошее начало - бригада из четырех человек, но вы, возможно, захотите взглянуть на другие трактаты классических схем проектированиядальнейшая разработка.В зависимости от ваших пристрастий к языку программирования, вы можете рассмотреть и более конкретные учебники.У Amazon есть масса списков шаблонов проектирования.

Я говорил о дихотомии классов в этой статье .

5 голосов
/ 06 августа 2010

То, что вы делаете, - это отделение данных концепции от операций, которые воздействуют на эту концепцию.Что система является из того, что система делает .Это открывает двери для многих различных сценариев, в которых вы меняете поведение системы, используя различные классы поведения.Эти классы поведения также могут быть повторно использованы для различных классов данных.Многие шаблоны решают эту проблему, например, Visitor, Command, Strategy или Observer.

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

Архитектура DCI адресаэти проблемы, и представляет роли, или черты (pdf) , в качестве основной единицы поведения и повторного использования кода.

4 голосов
/ 05 августа 2010

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

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

4 голосов
/ 05 августа 2010

Интересно. Ну, я думаю, что вы делаете Модель-> Контроллер-> Вид (Шаблон MVC), но в этом случае вы используете только части Контроллер и Модель отдельно.

Прибыль здесь очевидна, если у вас есть несколько сценариев, в которых будут использоваться объекты, это типичный способ работы POJO + Managers. В этом случае сами объекты тупы и не имеют никакой функциональности, кроме своего собственного состояния.

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

Если вы думаете об этом, если объекты ничего не делают сами с собой, вы в основном исключаете один уровень косвенности (базовый уровень), и все должно быть перенаправлено для использования. Это означает больше кода для обработки непредвиденных ситуаций, нулевых объектов и тому подобного. Возможно, больше клея, чем нужно.

Гибкое? Да. Практическая? Только ты можешь ответить.

1 голос
/ 05 августа 2010

То, о чем вы говорите, является одним из великих "ха!" моменты, с которыми сталкиваются объектно-ориентированные программисты. Это весело, когда это происходит. Я бы начал с банды из четырех книг «Шаблоны дизайна» и разошелся оттуда.

0 голосов
/ 11 декабря 2010

В мире Java у нас есть прекрасные контейнеры, содержащие сессионные компоненты без сохранения состояния, которые могут быть точно использованы для отделения поведения от данных, что формализовано архитектурой DCI.Это иногда называют сервис-ориентированным программированием.

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

В хорошем проекте у нас иногда есть поведение в классах, а иногда у нас поведение в классах более высокого порядка.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...