Шаблон для обмена данными между объектами в C++

Почему бы не передать инварианты в качестве параметра функции или конструктору класса, имеющего метод calculateFactor ?

также попробуйте собрать параметры вместе, если у вас слишком много параметров для одной функции (например, вместо (x, y, z) передать 3D-точку, у вас есть только 1 параметр вместо 3).

три логических шага, представленных тремя различными классами

возможно, это был не лучший подход.

один класс может иметь большое количество "глобальных" переменных, общих для всех методов класса.

что я сделал при преобразовании старых кодов (C или Fortran) в новые структуры OO, это попытаться создать один класс, который представляет собой более полную "вещь".

в некоторых случаях хорошо структурированный FORTRAN будет используйте" именованные общие блоки " для кластеризации вещей в значимые группы. Это намек на то, что "вещь" действительно был.

кроме того, FORTRAN будет иметь много параллельных массивов, которые на самом деле не являются отдельными вещами, они являются отдельными атрибутами общей вещи.

DOUBLE X(200)
DOUBLE Y(200)

- это действительно небольшой класс с двумя атрибутами, которые вы бы поместили в коллекцию.

наконец, вы можете легко создавать большие классы только с данными, отдельно от класса, который содержит функции, которые выполняют работу. Это своего рода жутко, но это позволяет вам утончить общую проблему, переведя общий блок в класс и просто передав экземпляр этого класса каждой функции, которая использует COMMON.

существует очень простой класс шаблона для обмена данными между объектами в C++, и он называется shared_ptr. Он находится в новом STL и в boost.

Если два объекта имеют shared_ptr к одному и тому же объекту, они получают общий доступ к любым данным, которые он содержит.

в вашем конкретном случае вы, вероятно, не хотите этого, но хотите простой класс, который содержит данные.

class FactorCalculator
{
   InvariantsType invA;
   InvariantsType invB;

public:
   FactorCalculator() // calculate the invariants once per calculator
   {
      invA.CalculateValues();
      invB.CalculateValues();
   }

   // call multiple times with different values of x, y, z
   double calculateFactor( double x, double y, double z ) /*const*/ 
   {
       // calculate using pre-calculated values in invA and invB
   }
};

вместо передачи каждого параметра по отдельности создайте другой класс для их хранения и передайте экземпляр этого класса:

// Before
void f1(int a, int b, int c) {
    cout << a << b << c << endl;
}

// After
void f2(const HighEnergyParams& x) {
    cout << x.a << x.b << x.c << endl;
}

первый пункт: глобалы не почти как плохо (в себе), как много (большинство?) программисты утверждают. На самом деле, сами по себе они не так уж плохи. Они в первую очередь являются симптомом других проблем, в первую очередь 1) логически отдельные части кода, которые были излишне перемешаны, и 2) код, который имеет ненужные зависимости данных.

в вашем случае это звуки как уже устранены (или, по крайней мере, сведены к минимуму) реальные проблемы (будучи инварианты, а не переменные, сами по себе устраняют один основной источник проблем). Вы уже заявили, что не можете устранить зависимости данных, и вы, по-видимому, не смешали код до такой степени, что у вас есть по крайней мере два разных набора инвариантов. Не видя кода, это может быть более грубая гранулярность, чем действительно необходимо, и, возможно, при ближайшем рассмотрении некоторые из этих зависимостей могут быть полностью устранены.

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

учитывая, что они предназначены для инвариантности, что вы, вероятно,должны do является принудительным, что явно. Например, имейте класс фабрики (или функцию), который создает инвариантный класс. Инвариантный класс делает фабрику своим другом, но это только способ изменения членов инвариантного класса. Класс factory, в свою очередь, имеет (например) статическое bool, и выполняет assert Если вы попытаетесь запустить его несколько раз. Это дает (разумный уровень) уверенность в том, что инварианты действительно инвариантны (да,reinterpret_cast позволит вам изменять данные в любом случае, но не авария.)

единственный реальный вопрос, который у меня был бы, - есть ли реальная точка в разделении ваших инвариантов на два "куска", если все вычисления действительно зависят от обоих. Если есть четкое, логическое разделение между ними, это здорово (даже если они привыкнут вместе). Однако, если у вас есть логически единый блок данных, попытка разбить его на части может быть контрпродуктивной.

итог: глобалы (в худшем случае) являются симптомом, а не болезнью. Настаивая на том, что вы going понизить температуру пациента до 98,6 градуса может быть контрпродуктивно-особенно если пациент животное, нормальная температура тела которого на самом деле 102 градуса.