面向对象设计

Question

目前正在开发一款控制台游戏。 在后面的阶段将它开发到windows界面。

想知道以下几点：
1.目前我有几个掌握游戏逻辑的类。 我还有一个班级负责管理整个游戏，还有一个班级负责管理使用游戏管理器的控制台的视图。正在通过Program类访问 ，其管理所述视图中的类（具有空隙主）
问题是：其中我应该使用用于每个类别的上述的（一般）访问改性剂的问题，我应该使用内部还是公共？ 考虑一下，我希望这适用于以后的任何实现，而不必更改游戏逻辑部分的代码。

2.a。对于NameSpaces或Projects的代码组织，应该如何组织？
我应该在相同的解决方案下创建两个名称空间（项目）： 一个会保存游戏逻辑类，其次是程序类和管理控制台视图的类？
b。访问修饰符现在应该如何按照这样的安排？
对不起，说来话长
感谢

Answer 1

我们必须将所有的存取私人的规则，将其设置为公共需要的地方。这只是为了减少视觉工作室中自动完成的混乱。

从私有到公共的更改不会破坏现有代码，但需要重新编译才能再次运行。如果这是可以接受的，我只是添加最高限度的访问者，并在需要时让他们更公开。

根据复杂性，我会在需要时添加项目以及整个dll可以重用的位置。

Answer 2

我会分离程序集，并用“视图逻辑”创建一个程序集，它将输入/输出映射到您选择的用户界面（控制台，WinForms，WPF，XNA）以及包含游戏逻辑的另一个程序集。

现在你的游戏逻辑的访问修饰符：

1. 类：让大部分内部，只有公开揭露类，你需要从你的UI访问。方法/属性：只展示你真正需要的方法和属性，保持它们是私人的，直到其他类需要访问，然后根据需要使其成为内部/公共。

Answer 3

2：您可以将逻辑放置在项目的新文件夹中。这会自动创建一个新的名称空间，并为您节省多个项目及其依赖关系的麻烦。

Answer 4

最佳实践会说，除非他们需要公开，否则不要将您的课程设置为公开课程。听起来就像你可以脱离主流程序内部的一切。

@ Residuum关于将不同接口拆分成独立项目的建议是有道理的，但前提是你松散地将游戏逻辑和接口代码耦合在一起。如果它有很强的依赖性，那就没有意义了。

您似乎对名称空间和程序集（项目）有些困惑，所以这可能对您有用。 http://msdn.microsoft.com/en-us/library/ms973231.aspx