Современное проектирование на C++: обобщённое программирование и шаблоны проектирования

Введение

Книга Андрея Александреску "Современный дизайн C++: Общее программирование и применение шаблонов проектирования" – книга Андрея Александреску, опубликованная в 2001 году издательством Addison Wesley. Скотт Майерс назвал её "одной из самых важных книг по C++". В книге рассматривается и исследуется техника программирования на C++, известная как метапрограммирование шаблонов. Хотя Александреску и не изобрел эту технику, он сделал её популярной среди программистов. Книга содержит решения практических задач, с которыми могут столкнуться разработчики на C++. Несколько выражений из книги стали общеупотребимыми терминами в C++-сообществе: современный C++ (в отличие от стиля C/C++), проектирование, основанное на политиках, и типелиста. Весь код, описанный в книге, свободно доступен в его библиотеке Loki. С 2001 года книга была переиздана и переведена на несколько языков.

Дизайн на основе политики

Дизайн, основанный на политиках, также известный как проектирование классов на основе политик или программирование на основе политик, — это термин, используемый в современном дизайне C++ для подхода к проектированию, основанного на идиоме для C++, известной как политики. Он описан как вариант шаблона «Стратегия», работающий во время компиляции, и связан с метапрограммированием шаблонов C++. Впервые он получил широкое распространение в C++ благодаря книге Андрея Александреску «Modern C++ Design» и его колонке «Generic<Programming>» в журнале C/C++ Users Journal, и в настоящее время тесно связан с C++ и D, поскольку требует компилятора с надежной поддержкой шаблонов, что было не распространено до 2003 года. Предыдущие примеры этого подхода к проектированию, основанные на параметризованном обобщенном коде, включают параметрические модули (функторы) языков ML и аллокаторы C++ для политики управления памятью. Центральной идиомой в дизайне, основанном на политиках, является шаблон класса (называемый классом-хостом), принимающий несколько параметров типа в качестве входных данных, которые инстанцируются типами, выбранными пользователем (называемыми классами политик), каждый из которых реализует конкретный неявный интерфейс (называемый политикой) и инкапсулирует некоторые ортогональные (или преимущественно ортогональные) аспекты поведения инстанцированного класса-хоста. Предоставляя класс-хост в сочетании с набором различных, готовых реализаций для каждой политики, библиотека или модуль может поддерживать экспоненциальное количество различных комбинаций поведения, разрешаемых во время компиляции и выбираемых путем комбинирования различных предоставленных классов политик при инстанцировании шаблона класса-хоста. Кроме того, написав пользовательскую реализацию данной политики, библиотеку, основанную на политиках, можно использовать в ситуациях, требующих поведения, не предусмотренного разработчиком библиотеки. Даже в тех случаях, когда используется не более одной реализации каждой политики, разложение класса на политики может помочь процессу проектирования, повышая модульность и выделяя места, где были приняты ортогональные решения по проектированию. Хотя сборка программных компонентов из взаимозаменяемых модулей — это не новая концепция, дизайн, основанный на политиках, представляет собой инновацию в том, как он применяет эту концепцию на (относительно низком) уровне определения поведения отдельного класса. Классы политик имеют некоторое сходство с функциями обратного вызова, но отличаются тем, что, вместо того чтобы состоять из одной функции, класс политики обычно содержит несколько связанных функций (методов), часто в сочетании с переменными состояния или другими возможностями, такими как вложенные типы. Класс-хост, основанный на политиках, можно рассматривать как тип метафункции, принимающей набор поведения, представленный типами, в качестве входных данных и возвращающей в качестве выходных данных тип, представляющий результат объединения этих поведений в функционирующее целое. (В отличие от метафункций MPL, однако, выход обычно представлен самим инстанцированным классом-хостом, а не вложенным типом вывода.) Ключевой особенностью идиомы политики является то, что, как правило (хотя это и не строго необходимо), класс-хост будет происходить от (становиться дочерним классом) каждого из его классов политик, используя (публичное) множественное наследование. (Альтернативой является то, что класс-хост просто содержит переменную-член каждого типа класса политики или наследует классы политик в частном порядке; однако публичное наследование классов политик имеет важное преимущество: класс политики может добавлять новые методы, унаследованные инстанцированным классом-хостом и доступные для его пользователей, о которых сам класс-хост даже не должен знать.) Примечательной особенностью этого аспекта идиомы политики является то, что по отношению к объектно-ориентированному программированию политики инвертируют взаимосвязь между базовым классом и производным классом: в то время как в ООП интерфейсы традиционно представлены (абстрактными) базовыми классами, а реализации интерфейсов — производными классами, в дизайне, основанном на политиках, производный (хост) класс представляет интерфейсы, а базовые (классы политик) — реализуют их. В случае политик публичное наследование не представляет собой отношение «является» между хостом и классами политик. Хотя это традиционно рассматривалось бы как признак дефекта проектирования в контексте ООП, это не применимо в контексте идиомы политики. Недостатком политик в их текущей реализации является то, что интерфейс политики не имеет прямого, явного представления в коде, а определяется неявно, посредством «утиной типизации», и должен быть задокументирован отдельно и вручную, в комментариях. Основная идея заключается в использовании анализа общности и изменчивости для разделения типа на фиксированную реализацию и интерфейс, класс, основанный на политиках, и различные политики. Трудность заключается в том, чтобы определить, что поместить в основной класс, а какие политики следует создать. В вышеупомянутой статье дается следующий ответ: везде, где нам потребуется принять возможное ограничивающее решение по проектированию, мы должны отложить это решение, делегировать его соответствующим образом названной политике. Классы политик могут содержать реализацию, определения типов и так далее. По сути, разработчик основного класса шаблона определит, что классы политик должны предоставлять, какие точки настройки им необходимо реализовать. Создание хорошего набора политик может быть деликатной задачей, именно столько, сколько необходимо (например, минимум). Различные точки настройки, которые связаны друг с другом, должны быть объединены в один аргумент политики, например, политику хранения, политику проверки и так далее. Графические дизайнеры могут давать имена своим политикам, которые представляют концепции, а не те, которые представляют операции или незначительные детали реализации. Дизайн, основанный на политиках, может включать другие полезные методы. Например, шаблонный метод можно переинтерпретировать для времени компиляции, чтобы основной класс имел скелетный алгоритм, который в точках настройки вызывает соответствующие функции некоторых политик. Это будет достигнуто динамически с помощью концепций в будущих версиях C++.

Policy based design, also known as policy based class design or policy based programming, is the term used in Modern C++ Design for a design approach based on an idiom for C++ known as policies. It has been described as a compile time variant of the strategy pattern, and has connections with C++ template metaprogramming. It was first popularized in C++ by Andrei Alexandrescu with Modern C++ Design and with his column Generic<Programming> in the C/C++ Users Journal, and it is currently closely associated with C++ and D as it requires a compiler with highly robust support for templates, which was not common before about 2003. Previous examples of this design approach, based on parameterized generic code, include parametric modules (functors) of the ML languages, and C++ allocators for memory management policy. The central idiom in policy based design is a class template (called the host class), taking several type parameters as input, which are instantiated with types selected by the user (called policy classes), each implementing a particular implicit interface (called a policy), and encapsulating some orthogonal (or mostly orthogonal) aspect of the behavior of the instantiated host class. By supplying a host class combined with a set of different, canned implementations for each policy, a library or module can support an exponential number of different behavior combinations, resolved at compile time, and selected by mixing and matching the different supplied policy classes in the instantiation of the host class template. Additionally, by writing a custom implementation of a given policy, a policy based library can be used in situations requiring behaviors unforeseen by the library implementor. Even in cases where no more than one implementation of each policy will ever be used, decomposing a class into policies can aid the design process, by increasing modularity and highlighting exactly where orthogonal design decisions have been made. While assembling software components out of interchangeable modules is a far from new concept, policy based design represents an innovation in the way it applies that concept at the (relatively low) level of defining the behavior of an individual class. Policy classes have some similarity to callbacks, but differ in that, rather than consisting of a single function, a policy class will typically contain several related functions (methods), often combined with state variables or other facilities such as nested types. A policy based host class can be thought of as a type of metafunction, taking a set of behaviors represented by types as input, and returning as output a type representing the result of combining those behaviors into a functioning whole. (Unlike MPL metafunctions, however, the output is usually represented by the instantiated host class itself, rather than a nested output type.) A key feature of the policy idiom is that, usually (though it is not strictly necessary), the host class will derive from (make itself a child class of) each of its policy classes using (public) multiple inheritance. (Alternatives are for the host class to merely contain a member variable of each policy class type, or else to inherit the policy classes privately; however inheriting the policy classes publicly has the major advantage that a policy class can add new methods, inherited by the instantiated host class and accessible to its users, which the host class itself need not even know about.) A notable feature of this aspect of the policy idiom is that, relative to object oriented programming, policies invert the relationship between base class and derived class whereas in OOP interfaces are traditionally represented by (abstract) base classes and implementations of interfaces by derived classes, in policy based design the derived (host) class represents the interfaces and the base (policy) classes implement them. In the case of policies, the public inheritance does not represent an is a relationship between the host and the policy classes. While this would traditionally be considered evidence of a design defect in OOP contexts, this doesn't apply in the context of the policy idiom. A disadvantage of policies in their current incarnation is that the policy interface doesn't have a direct, explicit representation in code, but rather is defined implicitly, via duck typing, and must be documented separately and manually, in comments. The main idea is to use commonality variability analysis to divide the type into the fixed implementation and interface, the policy based class, and the different policies. The trick is to know what goes into the main class, and what policies should one create. The article mentioned above gives the following answer: wherever we would need to make a possible limiting design decision, we should postpone that decision, we should delegate it to an appropriately named policy. Policy classes can contain implementation, type definitions and so forth. Basically, the designer of the main template class will define what the policy classes should provide, what customization points they need to implement. It may be a delicate task to create a good set of policies, just the right number (e. g., the minimum necessary). The different customization points, which belong together, should go into one policy argument, such as storage policy, validation policy and so forth. Graphic designers are able to give a name to their policies, which represent concepts, and not those which represent operations or minor implementation details. Policy based design may incorporate other useful techniques. For example, the template method pattern can be reinterpreted for compile time, so that a main class has a skeleton algorithm, whichat customization pointscalls the appropriate functions of some of the policies. This will be achieved dynamically by concepts in future versions of C++.

Библиотека Локи

Loki — это название библиотеки программного обеспечения на C++, написанной Андреем Александреску в рамках его книги «Современный дизайн C++». Библиотека активно использует метапрограммирование шаблонов C++ и реализует несколько часто используемых инструментов: typelist, functor, singleton, умные указатели, фабрику объектов, visitor и мультиметоды. Изначально библиотека была совместима лишь с двумя наиболее соответствующими стандарту компиляторами C++ (CodeWarrior и Comeau C/C++), но последующие усилия сделали её пригодной для использования с широким спектром компиляторов (включая устаревшие Visual C++ 6.0, Borland C++ Builder 6.0, Clang и GCC). Разработчики компиляторов использовали Loki в качестве эталона совместимости, что способствовало увеличению числа компиляторов, соответствующих стандарту. Поддержка и дальнейшая разработка Loki продолжаются благодаря сообществу разработчиков с открытым исходным кодом, возглавляемому Питером Кюммелем и Ричардом Спозато в рамках проекта SourceForge. Постоянный вклад множества участников улучшил общую надёжность и функциональность библиотеки. Loki больше не связана с книгой, поскольку содержит множество новых компонентов (например, StrongPtr, Printf и Scopeguard). Loki послужила источником вдохновения для аналогичных инструментов и функциональности, которые теперь также представлены в библиотеке Boost.