Есть ли литература по этому типу программирования?
В колледже я взял урок по современной физике, в котором мы узнали о специальной теории относительности. Я был полностью потрясен тем, как разные системы отсчета могут реально наблюдать, как физические свойства объекта различны и не могут быть неверными. Со временем эта концепция постепенно меняла способ программирования, и теперь я стремлюсь разбить классы на 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
}
Палуба больше не отвечает за реализацию функций, которые могут на нее воздействовать. Или, чтобы соответствовать терминологии, колода - это просто набор значений, а то, как она соблюдается, является обязанностью наблюдателя. Естественно, может быть много наблюдателей, которые выполняют действия по-разному.
Во втором примере я буду использовать то, с чем людям, которые я пытался объяснить это, было легче справиться. Возьмем ситуацию, когда у нас есть цветные буквы на цветной бумаге, которые пишут слово. У нас есть агент, который обязан прочитать слово на бумаге. Теперь предположим, что агент - это какой-то тип дальтоников. Изображение, испускаемое из бумаги, то же самое, но восприятие может быть другим. Наблюдатель не имеет глубоких знаний об объекте и не может изменить его, ответьте только толкованием этого.
Как я уже говорил, эта концепция определяет многие из моих решений по разработке. Итак, вернемся к вопросу, является ли это опубликованным типом программирования, и если да, то можете ли вы указать мне некоторую литературу по этому вопросу ? Я сталкивался с некоторыми распространенными и необычными сценариями, по которым трудно принимать решения, и, конечно, с некоторыми вещами, о которых я только не думал и не сталкивался, которые, я надеюсь, были бы рассмотрены в литературе.
7 ответов
Вы отделяете данные концепции от операций, воздействующих на эту концепцию. Что система есть из того, что делает система . Это открывает дверь для множества различных сценариев, в которых вы меняете поведение системы, используя разные классы поведения. Эти классы поведения также можно повторно использовать для разных классов данных. Многие шаблоны решают эту проблему, например «Посетитель», «Команда», «Стратегия» или «Наблюдатель».
Но здесь есть кое-что более глубокое. Может быть, нам нужна другая концепция в наших (основных) языках программирования (или, может быть, просто в нашем сознании), которая позволит нам разделять и повторно использовать эти действия.
Архитектура DCI решает эти проблемы и представляет роли или черты (pdf) как фундаментальную единицу поведения и повторного использования кода.
Некоторые аспекты этого стиля программирования рассматриваются в Data-Oriented Programming (стиль разработки, который фокусируется на компоновке и преобразовании данных).
Моя основная проблема с этим стилем заключается в том, что если есть неявные предположения / ограничения для данного типа (например, скажем, в колоде карт никогда не должно быть двух джокеров подряд после тасования), вы должны продублировать эти ограничения / проверки повсюду. все типы менеджеров, поскольку тип данных, с которым вы работаете, совершенно тупой - он не может позаботиться о себе, это просто мешок данных. Вы можете выделить повторяющуюся логику в отдельный метод, но, как правило, с помощью этого метода немного сложнее написать хороший чистый код.
Сравните это с реализацией метода Deck.Shuffle , который использует стратегию IDeckShuffle . В этом сценарии вы можете выполнить перемешивание, а затем добавить инвариантные проверки в качестве пост-шага, чтобы гарантировать, что независимо от того, какая стратегия перемешивания использовалась, колода никогда не перейдет в недопустимое состояние; код, обеспечивающий целостность, находится в одном месте, и его легко проверить и обновить.
Кроме того, поскольку вызов IDeckShuffler.Shuffle (...) происходит изнутри колоды, колода имеет доступ ко всем скрытым полям и инкапсулированному состоянию. Таким образом, вы можете предоставить минимум деталей реализации тасования колоды вместо передачи по умолчанию колоды. Вместо этого вы можете передать IEnumerable или что-то еще менее конкретное, в отличие от передачи всего пакета данных по умолчанию.
В любом случае, форма разработки, о которой вы спрашиваете, - это в основном процедурное программирование.Таким образом, сложнее скрыть информацию и инкапсулировать вещи. В системах, критичных к производительности, это может быть приемлемым компромиссом (сгруппируйте все данные по типу, затем переберите их, используя функции «процесса» менеджера = хорошая согласованность кеша).
В целом, я избегаю этого стиля программирования, поскольку он серьезно ограничивает мою способность управлять сложностью. Некоторое время назад у Айенде был хороший пост об этом . Хотя он говорит об объекте хранения данных и операциях, которые на него воздействуют, принцип тот же самый - разделение данных и функций, которые воздействуют на эти данные, и проблем в них.
Интересно. Что ж, я думаю, вы делаете Model-> Controller-> View (MVC Pattern), но в этом случае вы используете только части «Контроллер» и «Модель» по отдельности.
Выигрыш здесь очевиден, если у вас есть несколько сценариев, в которых будут использоваться объекты, это типичный способ действий менеджеров POJO +. В этом случае сами объекты глупы и не имеют никакой функциональности, кроме своего собственного состояния.
Преимущества очевидны в способах разделения ответственности, хотя недостатки - это немного больше внимания со стороны менеджера.
Если вы думаете об этом, если объекты ничего не делают сами с собой, вы в основном вырезаете один уровень косвенности (базовый уровень), и все должно быть косвенно направлено для использования. Это означает больше кода для обработки непредвиденных ситуаций, нулевых объектов и т. Д. Возможно, больше кода клея, чем нужно.
Гибкий? да. Практичный? Только ты можешь ответить.
Этот шаблон проектирования может работать хорошо, особенно если операции не изменяют исходные объекты данных. В .NET, например, LINQ и связанные с ним методы расширения можно рассматривать как общие операции для работы с перечислениями, так что сами перечисления не должны знать, как их можно использовать. Однако эти методы не изменяют перечисляемые коллекции, а просто предоставляют новый способ интерпретации, фильтрации и группировки перечисления.
Однако, если функциональность изменяет исходные объекты, я предпочитаю инкапсулировать эту функциональность в виде методов объекта. Таким образом, объект отвечает за поддержание своих собственных инвариантов, и вы изолируете больше деталей реализации от клиентов объекта. Чем больше деталей реализации вы должны утекать, чтобы работать с объектом, тем больше возможностей для его неправильного использования и возникновения ошибок.
То, о чем вы говорите, является одним из великих моментов "ага!", с которыми сталкиваются объектно-ориентированные программисты. Это весело, когда это происходит. Я бы начал с книги "Design Patterns" ("Паттерны проектирования") банды из четырех человек и развил бы ее дальше.
Мне кажется, что вы реализуете функциональное программирование способом ООП. Независимо от объяснения физики о "специальной относительности", вся идея ООП в основном заключается в инкапсуляции - вы хотите, чтобы объекты сами знали, как все должно быть сделано. По сути, вы говорите: "Нет, есть только данные и функции, которые работают с данными". Что если колода изменится? Вы получите нового дилера? Как вы узнаете, какой дилер должен быть создан для работы с новой колодой?
Если вы подумали об операторе "switch", то вы вбиваете концепции ООП в шаблон функционального программирования.
Это типичный способ размещения большинства приложений. Я считаю классы образующими дихотомию - объекты контейнера данных и объекты стратегии. Объекты контейнеров данных являются носителями информации, в то время как стратегии представляют собой инкапсуляцию различных типов алгоритмов, которые могут применяться к контейнерам данных.
Командный паттерн очень близок к паттерну стратегии. Стратегии также имеют тенденцию проявляться в виде контроллеров, фасадов и т.п.
Объекты контейнера данных проявляются как сущности, объекты модели, объекты значений, объекты передачи данных и т. Д.
Группа из четырех - хорошее начало, но вы можете захотеть изучить другие трактаты классических шаблонов проектирования для дальнейшей разработки. В зависимости от вашего пристрастия к языку программирования вы можете также рассмотреть более конкретные книги шаблонов. У Amazon есть масса списков шаблонов дизайна.
Я говорил о классовой дихотомии в этой статье .