Object oriented design

Currently developing a game for console. In a later stage will develop it to windows interface.

Would like to know about the following things:

1. Currently I have some several classes which are holding the game logic. I also have a class for managing the whole game and a class which is managing the view for the console which is using开发者_运维知识库 the game manager. The class which is managing the view is being accessed through Program class (with void main)

Question is: In a matter of Access modifiers which should I use for each class of the above (in general), should I use internal or public? Consider that I want this to be suitable for any later implementation without changing the code of the logical part of the game.

2.a.In matter of code organization to NameSpaces or Projects, how should it be organized?

Should I create two Namespaces(projects) under the same solution: One will hold the game logical classes, second the program class and the class which manages the view for console?

b.And how the access modifiers should be now in accordance to an arrangement like this?

Sorry for the long story

Thanks

I would seperate the assemblies, and create one assembly with the "view logic", that maps in-/output to your chosen user interface (console, WinForms, WPF, XNA), and another assembly containing the game logic.

Now for the access modifiers of your game logic:

1. Classes: Make most of them internal, and only expose the classes publicly that you need to access from your UI.

2. Methods / Properties: Only expose the methods and properties that you really need, keep them private until other classes need access, then make them internal / public as needed.

We have a rule of setting all accessors to private and set them to public where needed. This is just to reduce the clutter of auto complete in visual studio.

Changes from private to public won't break existing code but needs a rebuild before everything works again. If that's acceptable i'd just add the most prohibitive accessors and make them more public where needed.

Depending on the complexity I would add projects when needed and where entire dll can be reused.

On 2: You could place the logic in a new folder in your project. This creates automatically a new namespace, and saves you the trouble of multiple projects and their dependencies.

Best practice would say don't set your classes to public unless they need to be public. Sounds like you can get away with making everything apart form your main program internal.

@Residuum's suggestion about splitting into seperate projects for different interfaces makes sense but only if you loosely couple the game logic and the interface code. If it's got hard dependencies then it's pointless.

You seem slightly confused about namespaces and assemblies (projects) so this might be useful for you. http://msdn.microsoft.com/en-us/library/ms973231.aspx