CODEWITHSUNDEEP
c#oopclassnamespacesaccess-modifiers
Mulder
Mulder

Reputation: 85

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

Upvotes: 1

Views: 166

Answers (4)

BenCr
BenCr

Reputation: 6052

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

Upvotes: 0

hcb
hcb

Reputation: 8357

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.

Upvotes: 0

Residuum
Residuum

Reputation: 12064

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.

Upvotes: 2

CodingBarfield
CodingBarfield

Reputation: 3398

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.

Upvotes: 0

Related Questions