在文件和类声明的关系不像在 java 中那样固定的，groovy 文件根据下面的规则能够包含多个公共类的声明：
如果一个 groovy 文件不包括类声明，那么它被作为一个脚本处理；也就是说，它透明的包装为 Script 类型的类，自动生成的类的名称与源文件名称相同（不包括扩展 名），文件只能够的内容被包装在一个 run 方法中，并且增加了一个 main 方法用来容易的启动脚本。
如果 groovy 文件中只包含一个类声明，并且这个类的名称与文件名相同（不 包括扩展名），那么这里有与 java 中一样的一对一的关系。
一个 groovy 文件也许包含多个不同访问范围的类声明，这里没有强制规则必须使类的名称与文件名一样，groovyc 编译器完美的为所有在这个文件中声明的类创建*.class 文件，如果你希望直接调用你的脚本，例如在命令行或者 IDE 中使用 groovy，那么在你的文件中的第一个类中应该有一个 main 方法。
一个 groovy 文件也许混合了类的声明和脚本代码，在这种情况下，脚本代码将变成一个主类被执行，因此不要声明一个与源文件同名的类。
当没有进行显式编译的时候，groovy 通过匹配相应名称的*.groovy 源文件来查找类，在这点上，名称变得十分重要，groovy 仅仅根据类名称是否匹配源文件名称来查找类，当这样的一个文件被找到的时候，在这个文件中声明的所有类都将被转换，并且 groovy 在后面的时间都将能找到这些类。
列表 7.11 显示一个简单的脚本，这个脚本中包括了两个简单的类，Vendor 和 Address，目前他们没有方法，只有公共的属性。
Vendor 和 Address 是简单的数据结构类，它们大概等价于 C 的结构或者 Pascal 的记录，我们很快将探索定义类的更优雅的途径。
列表 7.11 介绍了 groovy 支持的源文件，与类的映射规则的便利约定，这在我们早期讨论过的。这样的约定允许在相同的源文件中声明 main 方法类或者当前脚本的助手类。
与 java相比，这样允许你使用嵌套的类供本地类使用，这样不会干扰你的公共类的命名空间，也不会使在代码库中查找源代码文件更加困难，尽管这不是真正的一样，这种约定对于 groovy 开发人员来说有相似的行为。