将所有枚举类型放在带有其他常量的头文件中的应用程序被认为是一种不好的做法吗？

Question

我的iOS objective-C应用程序中有一些枚举类型用于不同的类，对于它们我觉得将它们放在constants.h文件中是好的，但是其他不一定用于多个类的其他类型？它会被认为是一种不好的做法吗？

Answer 1

是的，这是不好的做法。

如果将所有常量（包括枚举）放入一个文件中，则只要您想重用部分代码，就必须导入该文件。

更好的做法是按功能分组常量（适用于您的应用程序的任何级别），并包含仅在类文件本身的单个类中使用的常量，或者，如果必须，则包含在单独的标题中

Answer 2

虽然sapi的答案没有错，但这是我倾向于做的事情......

跨多个文件使用的一组常量将进入文件。假设我的所有Foo常量都进入FooConstants.h。

现在是另一个小组，比如说Bar个常量，他们都会进入BarConstants.h。

这些文件中将包含常量，枚举和协议定义。

在仅需要Foo常量的文件中，我将导入FooConstants.h。

在仅需要Bar常量的文件中，我将导入BarConstants.h。

根据项目的不同，我可能只有其中一个文件，或者我可能有10个或更多。通常我会有一个名为SegueNames.h的文件，其中我的所有故事板segue标识符都创建为常量并放入此文件中，因此我绝不会拼错一个segue名称。我通常也会DefaultsKeys.h，我会把钥匙放在我NSUserDefaults的所有内容中。

然后我时不时地开始意识到，我可能有一个使用其中6个常量文件的文件，所以我开始创建Constants.h。

Constants.h除了导入所有其他常量文件外没有任何内容。这清理了我的一些文件的顶部。

但是在一天结束时，我仍然将常量组织在他们自己的文件中，并将某些常量组合在一起。正如sapi指出的那样，任何仅在单个文件中使用的常量应该在该文件中定义。

Answer 3

这取决于具体情况。你的课程组织得有多好？如果它有点混乱，那么从Errors.h / m文件开始并不会有什么坏处，你可以在.h文件中将错误代码定义为枚举，将错误域定义为NSStrings。 m文件（.h文件中有相应的extern NSString * const）。

如果您的组织好一点，那么您已将您的班级划分为模块，每个模块都有一个入口点，您应该在其中定义这些内容。但结果并没有改变：枚举值和extern声明的错误标题，extern赋值的错误实现。

我的所有错误声明文件都是这样的：

// ErrorFile.h
typedef enum {
    ModuleErrorOne = 1,
    ModuleErrorTwo,
    ModuleErrorThree
} ModuleError;

extern NSString * const ModuleErrorDomain;

// ErrorFile.m
NSString * const ModuleErrorDomain = @"ModuleErrorDomain";

您可以将其粘贴在预编译的标题中，以提高编译速度。

编辑：感谢nhgrif和GraniteRobert的评论，他们改进了我的答案。