C++: Как разработать служебный класс?

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

Если вы хотите обеспечить логическую группировку классов, то нет никакого реального вреда в том, чтобы они были статическими функциями-членами класса - но я не вижу причин, почему такие функции, как MapRGB() и CopyString() должны быть членами одного класса.

Одним из факторов является то, помещать ли их в класс или просто помещать их в качестве членов в пространство имен (в Java вам придется использовать класс, но C ++ предлагает пространства имен).

Если вы действительно сделаете его членом класса, то самое важное решение, которое вы должны принять в отношении каждой функции, - это будет ли она требовать или должна ли влиять на какое-либо состояние, которое не получено или не передано через его параметры и возвращаемое значение. В противном случае его следует сделать статическим , поскольку вы не будете использовать скрытый аргумент «this».

Одним из аргументов в пользу использования класса вместо пространства имен является то, что вашему служебному классу может потребоваться вызвать дополнительные методы для его реализации (например, в случае рекурсии, сложных вычислений и т. Д.). Затем вы можете сделать свой метод статическим общедоступным и все, что он реализуется поверх static private . Прошло много лет с тех пор, как я использовал C ++, но я не думаю, что вы можете «спрятать» функции, не являющиеся членами, в пространстве имен (кто-нибудь поправит меня, если я ошибаюсь).

При разработке интерфейса функции учитывайте количество аргументов. Если входящих аргументов слишком много (особенно если они имеют похожие типы, а некоторые из них связаны), вы можете рассмотреть возможность использования дополнительных типов вместо передачи нескольких аргументов. Например, вместо calculateVolume (int x, int y, int z) вы можете сделать что-то вроде calculateVolume (Point3D) . Точно так же в вашем случае используйте класс RGB. Это может показаться глупым, но может избавить от некоторых досадных ошибок (например,, если у вас есть функции, которые принимают int и RGB) и время (если вам нужно передать значения другим функциям). Вы можете создать статический фабричный метод, чтобы упростить создание этих типов при передаче аргументов. Например: doSomethingWithColor (RGB.create (20,30,40))

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

Я бы попытался использовать осмысленные пространства имен - объединение MapRGB и CopySstring не имеет большого смысла. Если вам действительно нужны и то, и другое, и у вас действительно нет каких-либо других функций, которые имеют дело со строками или отображением RGB, их размещение в пространстве имен utillity может иметь смысл, но если вы их используете, это похоже, что у вас есть еще несколько строковых «вещей» и еще несколько «цветных» вещей, и, вероятно, вы могли бы получить выгоду от наличия пространства имен для каждого из них.

Обычно у меня есть .a (.lib в Windows), называемый "util", который подключается. Однако обычно класс "util" - плохая новость, и он вводит зависимость, которая нарушает стандартный объектно-ориентированный дизайн. Теперь, если вы попытаетесь извлечь класс для повторного использования в другом проекте, у вас будут тысячи скрытых зависимостей в вашей библиотеке утилит. В принципе, это полезно, но постарайтесь не класть туда вещи.