Ветвления. Что с ними можно сделать

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

тем кто переходит с процедурных языков такое решение не очень очевидно, но по моему для обучения этому есть ВУЗы…

Вы серьёзно думаете, что все, кто прочитал этот пост тут же пошлют резюме в Яндекс?

Во-первых, я не гарантирую, что мои ответы правильные :-) Я так же не гарантирую, что мои ответы, — это то, что хотят услышать в Яндексе. Ведь, как вы правильно заметили, «моё решение — далеко не единственное, имеющее свои плюсы и минусы». Во-вторых, думаю, что «совсем некомпетентных людей» на хабре нет.

Просто я бы мог написать «мне по работе попалась вот такая задача и я её решил так». Но «вот такую задачу» долго рассказывать, а тут есть уже готовые вопросы на которые можно просто дать ссылку.

Я бы сказал, что в конкретном варианте даже полезен compile time полиморфизм, для этого есть совсем неплохая либа boost::mpl, есть попроще Loki, да и самому здесь тоже писать очень мало, зато все отсеится на этапе компиляции и не будет лишнего кода. Когда-то клепал примерчик:

#include <iostream>

class Foo
{
public:
int GetValue()const{return 1;}
};

class Bar
{
public:
int GetValue()const{return 2;}
};

template<int v>
struct Int2Type
{
enum {value = v};
};

template<typename T>
struct TypeTrait
{
enum {IsValid = 0};
};

template<>
struct TypeTrait<Foo>
{
enum {IsValid = 1};
};

template<typename T>
inline void _DoWork(const T& t, Int2Type<1>)
{
std::cout << "value: " << t.GetValue() << std::endl;
}

// ошибка, тип не поодерживается
// либо вообще убрать данную функцию, в этом случае будет ошибка компиляции на DoWork(bar);
template<typename T>
inline void _DoWork(const T& t, Int2Type<0>)
{
// в идеале здесь требуется статическая проверка этапа компиляции
std::cout << "error" << std::endl;
}

template<typename T>
inline void DoWork(const T& t)
{
_DoWork(t, Int2Type<TypeTrait<T>::IsValid>());
}

int main(int argc, char *argv[])
{
Foo foo;
Bar bar;
DoWork(foo);
DoWork(bar);
}

К сожалению почему-то подсветка синтаксиса в комментариях не заводится или её нет в предпросмотре.

Раздваиваются? Что Вы имеете в виду, если можно со скриншотом. По ходу только у Вас.

И конечно, такой коммент не заслуживает плюсов. Слишком простое и ясное решение.

а я плюсанул…

Парсер лох(((

CodeGenerator<Java> cg;
//или же
CodeGenerator cg;
gc.generate<Java>();

* This source code was highlighted with Source Code Highlighter.

Вообще тут 4 основных варианта в итоге, по нарастанию сложности подсистемы:
1) Простая иерархия наследования с базовым классом, когда вызывающий код создаёт класс конкретной реализации (как в топике)
2) Подход с дженериками, который по сути является мостом
3) Подход с адаптерами
4) Подход с фабрикой (из топика cd-riper на ЖЖ)

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

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

Берем фабрику и накладываем условие связи каждого запрошенного действия с конкретным классом, получаем адаптер, теперь запрашивающий код уже знает конкретный тип адаптера и создаёт его.
Накладываем ещё одно ограничение, теперь код всех наших адаптеров перестаёт зависить от адаптируемой реализации: выносим весь этот код в 1 класс и получаем мост
Если накладываем ещё одно ограничение, когда классы интерфейса моста становятся тривиальными и просто перебрасывают вызовы — мы выкидываем этот класс и получаем простую иерархию наследования.

Если в заданном примере требуется создать генератор кода исходя из конфигурационного объекта, в котором содержится описание типа: «требователен к производительности, архитектура x86_64, операционная система: xxx», тогда получаем фабрику в чистом виде.

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

Если упростить всё до одинакового интерфейса кодогенерирующих классов (как в примере — генерируются только заранее известные куски кода) — получаем реализацию с мостом.

Если ещё пряглядеться к задаче, то можно увидеть, что запрашиваемая вызывающим кодом задача четко соответствует интерфейсу классов — генераторов, так что и мост нам не нужен.

Ну и не стоит забывать, что создание объектов, в зависимости от ситуации, можно упаковать в IoC контейнер.

Поэтому первым вопросом, который надо задать при написании подобного кода будет вопрос о перспективах развития подсистемы, исходя из этого уже и выбираем паттерн реализации.
В описанном примере я лично считаю подход из топика достаточно уместным, а подход из ЖЖ cd-riper'a соответственно неоправданным монструозным усложнением системы.