Подтвердить что ты не робот

Есть ли литература по этому типу программирования?

В колледже я взял класс по современной физике, в котором мы узнали об особой теории относительности. Я был полностью потрясен тем, как различные системы отсчета могут фактически наблюдать физические свойства объекта, которые будут разными, и не будут ошибочными. Со временем эта концепция медленно меняла способ программирования, до такой степени, что теперь я склонен разбивать классы на 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 больше не отвечает за реализацию функций, которые могут воздействовать на него. Или, чтобы он соответствовал терминологии, колода - это всего лишь набор ценностей, и способ, которым она соблюдается, несет ответственность наблюдателя. Естественно, может быть много наблюдателей, которые выполняют действия по-разному.

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

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

4b9b3361

Ответ 1

То, что вы делаете, - это разделение данных концепции от операций, действующих на эту концепцию. Что система от того, что делает система. Это открывает двери для многих разных сценариев, в которых вы меняете поведение системы, используя разные классы поведения. Эти классы поведения также могут быть повторно использованы для разных классов данных. Многие шаблоны решают эту проблему, например, "Посетитель", "Команда", "Стратегия" или "Наблюдатель".

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

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

Ответ 2

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

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

Ответ 3

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

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

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

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

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

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

Ответ 4

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

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

Объекты Data Container отображаются как объекты, объекты модели, объекты значений, объекты передачи данных и т.д.

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

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

Ответ 5

Интересно. Ну, я думаю, вы делаете Model- > Controller- > View (MVC Pattern), но в этом случае вы используете только части Controller и Model отдельно.

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

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

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

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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

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

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