如何将此结构转换为良好的OO设计？ [英] How do I turn this structure into a good OO design?

问题描述

大家好，



我使用C＃在WinForms，Silverlight等中创建小游戏。我有一个关于建立类结构的正确OO方式的问题。



这是我的典型结构：



Soldier.cs

SoldierCollection.cs（一系列士兵加上处理此阵列操作的方法）

Board.cs（GUI组件，例如WinForms中的Form1。在这里，我用SoldierCollection中的数据（即士兵）填充图片框。

Rules.cs（检查允许移动的规则等）



现在发生的事情是：

1.首先，Board.cs创建一个Soldiercollection.cs实例。



2.接下来，它在这个SoldierCollection.cs实例中调用一个方法，然后创建一个Soldiers数组。



3.之后已完成，Board.cs以图形方式填充，使用来自SoldierCollection.cs实例的数据。



4.当一名士兵（比如一个图片框）被拖过来时董事会使用在鼠标中，调用Soldiercollection.cs中的另一个方法，该方法又调用Rules.cs中的相应方法。结果然后发送回SoldierCollection，它决定发生了什么，结果返回到Board.cs，更新比赛场地或者显示胜利。



问题是所有这些应该如何尽可能好地连接到彼此。



例如，Rules.cs和SoldierCollection.cs都只会出现曾经（而不是Soldier.cs，可能有几十个实例）。因此，我很想将它们设置为静态。但是，我有一种感觉，从OO的角度来看这是被忽视的。



所以我的具体问题是：我的上述设计和流程是否合适，还是应该以其他方式更好？我应该将SoldierCollection或Rules类保持静态吗？在这里使用静态类的优缺点是什么？ （我也猜想如果我想跟踪胜利或者保持游戏，那么必须在Board.cs中完成，或者我需要另一个类，比如Game.cs.也许我应该从一个Game.cs类开始反过来连接到SOldierCollection等，然后将数据刷新到Board.cs进行显示？）



谢谢！



Petter

Hi all,

I create small games in WinForms, Silverlight etc using C#. I have a question regarding the correct OO way of buiding the structure of classes.

This is a typical structure for me:

Soldier.cs
SoldierCollection.cs (an array of Soldiers plus methods that take care of manipulations of this array)
Board.cs (the GUI component, such as "Form1" in WinForms. Here I fill pictureboxes with data (ie Soldiers) from the SoldierCollection.
Rules.cs (Rules for checking for allowed movements etc)

What happens now is this:
1. First, Board.cs creates an instance of Soldiercollection.cs.

2. Next, it calls a method in this instance of SoldierCollection.cs, which in turn creates an array of Soldiers.

3. After this has been done, Board.cs gets graphically filled, using data from the instance of SoldierCollection.cs.

4. When a soldierpiece (say a picturebox) is dragged over the board using the mouse, another method in Soldiercollection.cs is called, which in turn calls the appropriate method(s) in Rules.cs. The result is then sent back to SoldierCollection, which decides what happens, and the result is returned to Board.cs, to update the playing field or perhaps showing a win.

The question is how all of these should connect to each other as OO-nicely as possible.

For example, both Rules.cs and SoldierCollection.cs will only appear once (as opposed to Soldier.cs, which may have dozens of instances). Therefore, I am tempted to set these to static. However, I have a feeling that this is looked down upon from an OO viewpoint.

So my specific question is: Is my design and process described above suitable or should it better be done in another way? And should I have the SoldierCollection or Rules classes static? What would be the pros and cons of using static classes here? (I also guess that if I want to track wins or keep playerturns, this must either be done in Board.cs or I would need yet another class, such as Game.cs. Perhaps I should start out with a Game.cs class that in turn connects to SOldierCollection etc and then flushes out the data to Board.cs for display?)

Thanks!

Petter

推荐答案

我有一个游戏类，其中包含常规设置，上下文等，可以显示Board，Options，Highscores等等。



你的董事会只是愚蠢的看法，它除了显示数据之外什么都不做。

处理士兵的士兵经理 - 地形结果，规则调用等...



SoldierCollection照顾士兵（只有收集方法，如添加，删除，获取，getAt等......） />


基础（甚至抽象）持有通用数据的士兵类（生命值，力量，护甲，等等） ）



来自士兵的继承课程 - 重型步兵，骑兵等...



每个士兵都应该知道它能移动多少，剩下多少运动，伤害等等......他应该知道他在哪里和类似的数据（这个可移动的数据可能是士兵更新的单独类）



这不是真正可以快速讨论的东西。除非必须，否则不要使类静态。将他们的实例保存在Game（主）课程中并从那里开始工作。

I'd have one Game class with general settings, context and such which would show Board, Options, Highscores, whatever.

You have Board which is just "stupid" View, it doesn't do anything but show data.
SoldierManager which handles the soldiers - terrain results, rule invocation etc...

SoldierCollection which takes care of soldiers (only having collection methods such as add, remove, get, getAt etc...)

Base (or even abstract) Soldier class holding generic data (hitpoints, strength, armor, whatever)

Inherited classes from Soldiers - Heavy infantry, Cavalry etc...

Each soldier should know how much it can move and how much movement remains to him, how hurt it is etc...he should know where he is and similar data (this "moveable" data could be separate class that soldier updates)

This is not really something that can be quickly discussed. Don't make the classes static unless you have to. Keep their instances in Game (main) class and work from there.

这篇关于如何将此结构转换为良好的OO设计？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！