Политика на бази дизајна

Из Википедије, слободне енциклопедије
Иди на навигацију Иди на претрагу

Политика на бази дизајна, такође позната као политика заснована на класи дизајна или политика на бази програмирања, је компјутерска парадигма програмирања на основу идиома за C++ познат као политика.[1] Она је описана као саставни део стратегије обрасца, а има везе и са C++ шаблоном метапрограмирања. То је први популарисао Андреј Алекандреску са својом 2001 књигом Модеран C++ дизајн и својом колумном генеричко <Програмирање> у C/C++ корисничком Journal-у.

Иако техника може теоретски да се примени на друге језике, тренутно је уско повезана са C++, и зависи од појединих сет функција тог језика. Осим тога, чак и у C++ се захтева преводилац са веома робусном подршком за шаблоне, што није било уобичајено пре око 2003 година.

Преглед[уреди]

Централни идиом у креирању полиса заснованих на дизајну је класа шаблон (назива се домаћин класа), узимајући неколико типова параметра као улаз, који су инстацирани са типовима одабраних од стране корисника (тзв класе полиса), свако спровођење одређеног имплицитног интерфејса (зове се полиса), и инкапсулирајући неки ортогоналан (или углавном ортогоналну) аспект понашања инстанцираног домаћина класе. По снабдевању класе домаћина у комбинацији са низом различитих, конзервираних имплементација за сваку политику, библиотеку или модул може да подржи експоненцијалан број различитих комбинација понашања, решених у право време, и изабраних мешањем и одговарањем на различите класе, издате политичком примерном за домаћина класе шаблона. Осим тога, пишући прилагођену имплементацију дате политике, библиотека засноване на политици може да се користи у ситуацијама које захтевају понашања непредвиђених од библиотеке реализатора. Чак и у случајевима када се не користи више од једног спровођења сваке политике, распад класе у политику може да помогне процесу дизајнирања, повећањем модуларности и наглашавањем управо тамо где су направљене ортогоналне одлуке дизајна.

Док се склапају софтверске компоненте од измењивих модула и даље је далек од новог концепта, политика заснована на дизајну представља новину у начину на који се односи тај концепт у (релативно ниском нивоу) дефинисању понашање појединачне класе. Класе политике имају неку сличност са callbacks-ом, али се разликују у томе, што се састоје од једне функције, класе политике обично садрже неколико повезаних функција (методе), често у комбинацији са стањем варијабли или другим објектима, као што су угњеждене врсте. Политика заснована на класи домаћина се може посматрати као тип метафункције, узимајући скуп понашања који представљају типове као улаз и враћају излаз као тип представљања резултата комбиновања тих понашања у функционалну целину. (Разлика MPL метафункције, међутим, је излаз који обично представља инстанцирање само класе домаћина, а не уметнуте излаз типове.)

Кључна карактеристика полисе идиома је да, обично (мада није строго неопходно), домаћин класа проистиче из (прави своју класу дете) сваке од његових класа политике коришћења (јавно) вишеструког наследства. (Алтернативе за домаћин класу само садрже чланови променљиве сваке врсте политике класе, друго да наследи класе политике приватности, али наслеђивања класе политике јавно има велику предност јер класа политике може додати нове методе, које је наслиједила инстанцирана домаћин класа и доступне су корисницима, за које класа домаћин сама не мора да зна). Значајна карактеристика овог аспекта политике идиома је да, у односу на објектно-оријентисано програмирање, политика ће обрнути однос између основне класе и изведене класе - док се у ООП интерфејсу традиционално заступа (апстрактно) основна класа и имплементација интерфејса за изведене класе, и креирање политика заснованих (домаћин) класа представља интерфејс и базе (политика) наставе која их спроводи. Такође треба напоменути да у случају политике, јавно наследство не представља is-a однос између домаћина и класа политика. Иако би се традиционално сматрало доказом дизајн дефекта у ООП контекстима, ово не важи у контексту политике идиома.

Недостатак политике у њиховој садашњој инкарнацији је да интерфејс политика нема директну, експлицитну заступљеност у коду, већ је имплицитно дефинисана, преко патка куцања, и мора бити документовано одвојена и ручна, у коментарима. Основна идеја је да се користи истовременост-варијабилност анализе поделе типа у фиксној реализацији интерфејса, политика на бази дизајна, као и различите политике. Трик је да зна шта је у главној класи, а шта политика треба да створи. У тексту горе наведен је следећи одговор: где год да би требало да направимо могућа ограничавања дизајн одлука, требало би да одложимо ту одлуку, требало би да га пренесемо у одговарајућем имену политике.

Класе политике могу да садрже примену, дефиниције типа и тако даље. У основи, дизајнер главне класе шаблона ће дефинисати шта класе политика треба да обезбеди, што прилагођење тачке мора да спроведе.

То може бити деликатан задатак да створи добар сет политике, само прави број (нпр минимум потребан). Различито прилагођавање поена, који припадају заједно, треба да иду у један аргумент политике, као што су политика складиштења, политика провере и тако даље. Добро правило приликом пројектовања је да ћете бити у могућности да наведете име ваше политке, која представља концепт, а не оне која представља операције или неке заиста мале имплементације детаља. Упорност политика чини се да је добар избор, док се чува политика.

Политика на бази дизајна може садржати и друге технике које ће бити корисне, чак и ако се промени. Један од примера је да се метод шаблон образац може тумачити за састављање времена; тако ваша главна класа има костур алгоритам, који - прилагођава тачке - позива одговарајуће функције неке од политика. Такође ће се наћи у коришћењу своје класе политика јер се користе особине, тражења типа информација, делегирање задатака типа везаних за њу, политика складиштења је један пример где може то да се деси.

Једноставан пример[уреди]

У наставку је једноставан (неприродан) пример C++ hello world program, где се штампа текст и начин штампања да би се разградио користи политику. У овом примеру, HelloWorld је домаћин класа, где је потребно две политике, једна за одређивање како треба приказати поруку, а друга за штампање стварне поруке. Имајте на уму да је генеричка имплементација у бекству () и зато код није у стању да буде састављен, осим ако су обе политике (штампаних и порука) обезбеђене.

#include <iostream>
#include <string>
 
template <typename OutputPolicy, typename LanguagePolicy>
class HelloWorld : private OutputPolicy, private LanguagePolicy
{
    using OutputPolicy::print;
    using LanguagePolicy::message;
 
public:
    // Понашање метода
    void run() const
    {
        // Две методе политике
        print(message());
    }
};
 
class OutputPolicyWriteToCout
{
protected:
    template<typename MessageType>
    void print(MessageType const &message) const
    {
        std::cout << message << std::endl;
    }
};
 
class LanguagePolicyEnglish
{
protected:
    std::string message() const
    {
        return "Здраво свете!";
    }
};
 
class LanguagePolicyGerman
{
protected:
    std::string message() const
    {
        return "Здраво свете!";
    }
};
 
int main()
{
    /* Пример 1 */
    typedef HelloWorld<OutputPolicyWriteToCout, LanguagePolicyEnglish> HelloWorldEnglish;
 
    HelloWorldEnglish hello_world;
    hello_world.run(); // штампање "Здраво свете!"
 
    /* Пример 2 
     * Да ли је исто, али користи другу политику језика */
    typedef HelloWorld<OutputPolicyWriteToCout, LanguagePolicyGerman> HelloWorldGerman;
 
    HelloWorldGerman hello_world2;
    hello_world2.run(); // штампање "Здраво свете!"
}

Можете лако да напише још једну Output политику додавањем нове класе са функцијом члана принт() и то узети као нову Output политику.

Види још[уреди]

Референце[уреди]

Спољашње везе[уреди]