Предотвратите создание класса, функции членства которого являются всеми помехами
Nexus - менеджер репозитория Maven, а репозитории Maven требуют все эти файлы:
- pom.xml: описывает ваш проект
- файлы sha и md5: контрольные суммы для проверки целостности из файлов артефактов
Скорее всего, вы не сможете избавиться от этих файлов и подпапок, поскольку они являются частью спецификации репозитория maven.
Если все, что вам нужно, это файл, который нужно загрузить куда-то, FTP-сервер может быть более полезным.
5 ответов
Как сказанные другие, пространство имен - то, что необходимо использовать. Если Вы хотите остаться со своим классом, создать класс, который имеет частного конструктора, и произойдите из него, для создания намерения очевидным:
class NonConstructible {
NonConstructible();
};
class SuperUtils: NonConstructible {
static void foo();
// ...
static std::vector<int> globalIDs;
// ...
};
Хорошо, теперь давайте изучим пространство имен, которые являются тем и только способом сделать это:
namespace SuperUtils {
void foo() {
// ....
}
std::vector<int> globalIDs;
};
Можно назвать то использование SuperUtils::foo(); в обоих случаях, но пространство имен имеет преимущество, которое в объеме можно использовать объявление пространства имен и директиву для обеспечения бесспорный или все участники в текущую область, так, чтобы можно было сослаться на них без использования SuperUtils:::
void superFunction() {
using namespace SuperUtils;
foo();
}
В то время как обычно, которого нужно избежать, может быть полезно, когда метод использует исключительно много материала от SuperUtils, который затем может улучшить удобочитаемость кода.
Вместо того, чтобы использовать класс со всеми статическими методами, можно быть более обеспеченным созданием методов автономные функции в отдельном пространстве имен. Синтаксис вызова был бы тем же:
namespace::function() вместо classname::function()
и Вы не должны иметь дело с кем-то пытающимся инстанцировать Вашего класса.
Для использования конструктора копии, которого у Вас должен быть объект скопировать, поэтому при блокировке вниз конструктора по умолчанию, необходимо быть в безопасности.
Создание частного конструктора по умолчанию должно быть достаточным. Обе из других конструкций по умолчанию (копируют конструктора и присвоение) полагаются на наличие экземпляра для работы правильно. Если нет никакого конструктора по умолчанию затем нет никакого способа создать экземпляр, следовательно никакой способ на самом деле добраться до части конструкции копии.
Это, вероятно, сохранило бы Вас несколько головных болей, хотя определить все 3 как частные и не реализованное.
Лучший способ предотвратить создание объектов не"кучи" состоит в том, чтобы сделать деструктор частным. Затем нет никакого способа, которым компилятор может разрушить объект, когда он выйдет из объема, и он будет жаловаться. Это не будет препятствовать тому, чтобы любой делал новый как бы то ни было.