Как можно быть DRY с языком программирования, который не имеет Отражения? [закрытый]

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

Например, я написал JSON-Parser, который выводит объекты, типичный вызов выглядит так:

struct SomeStruct
{
        int a;
        int b;
        double c;

        typedef int serializable;
        template<class SerializerT> void serialize(SerializerT& s)
        {
                s("a",a)("b",b)("c",c);
        }
};

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

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

Каждый раз, когда вы обобщаете функцию из конкретного случая, вы используете принцип СУХОЙ. Тот факт, что некоторые языки не дают вам того, чего вы достигли с помощью рефлексии, не означает, что нет СУХИХ способов программирования с их помощью. Они могут быть не такими СУХИМИ, но это не значит, что у них нет собственных уникальных преимуществ, которые в совокупности могут перевесить преимущества использования языка, имеющего рефлексию. (Например, последствия для скорости из-за интенсивного использования отражения могут быть рассмотрены.)

Кроме того, один из способов получить что-то вроде DRY-преимуществ отражения с языком, который его не поддерживает, - это использование хорошей генерации кода орудие труда. В этом случае вы изменяете код для разных случаев один раз в шаблоне генерации кода, и шаблон отправляет его в разные экземпляры в коде. (Я не говорю, хорошо ли использование генерации кода, но с хорошим «активным» генератором это, безусловно, один из способов получить нечто вроде DRY-преимущества отражения на языке, который не имеет отражения. И Преимущества генерации кода выходят за рамки этого простого преимущества. Я думаю о чем-то вроде CodeSmith, хотя есть и много других: http://www.codesmithtools.com/ )

1. Абстрактно, делайте больше во время выполнения, без преимуществ таких вещей, как проверка типов во время компиляции (вам придется писать свои собственные процедуры проверки типов) и красивый код. Например, использовать таблицу вместо класса. (Но если вы так делаете, почему бы вместо этого не использовать динамически типизированный язык?) Это часто плохо. Я не рекомендую этого делать.

2. В C++ методы общего программирования позволяют программно включать члены класса (это то, что вы хотите сделать?) через наследование.

Хорошим примером модульного тестирования C ++ является cxxtest: http://cxxtest.tigris.org/ . Он использует соглашение и скрипт python для создания вашего набора тестов C ++ путем последующей обработки вашего C ++ с помощью python.

Хороший способ обойти ограничения в языках - это понятие Майкла Фезерса о «швах». Шов - это место, где ваша программа может быть изменена без изменения кода. Например, в C препроцессор и компоновщик обеспечивают стыки. В C ++ полиморфизм - другое место. В более динамичных языках, например, в которых вы можете изменять определения методов или размышлять, вы получаете еще большую гибкость. Без швов все может быть сложнее, и иногда вы просто не хотите пытаться забить гвоздь своей обувью, а скорее следуйте потоку инструмента.