关于大型物体的问题 [英] Question about large objects
问题描述
我一直在写游戏，我也读过很好的编程
技巧。我倾向于创建大量的东西，做很多事情。一个
我有一个好的例子是一个单位对象。该对象控制并保持
我游戏中的一个单元应该做的所有事情。什么一些
治疗这种大型物体或者他们没关系，因为他们
代表一件事。如果没有什么是设计对象的更好方法
的行为方式相同。使用继承或
的朋友会更好吗？在哪里可以更好地用
做同样的事情？
这是我创建的已完成游戏中的单位。
的头文件最不能让我知道一个较大的对象。
#include< fstream>
＃包括< vector>
#include< cmath>
#include< map>
#include" coord.h"
#include" color.h"
#include" graphics.h"
#include" tbox.h"
#ifndef UNIT_H
#define UNIT_H
班级单位{
受保护：
HWND hwnd;
coord loc;
coord currentLoc;
graphics * gr;
tbox * combatBox;
std :: vector< color> colors;
std :: map< char，coordkeys; //移动引擎
coord n; //指示
coord s;
coord e;
coord w;
char kind;
浮动攻击;
浮动数据包;
浮动防御;
int move;
int move;
int dmove;
int range;
bool canmove;
bool selected;
bool mark;
bool支出;
int col;
void create（）;
void displayBox（HDC，coord）;
int convert（const int n）{return n * 16;}
public：
unit（）;
单位（HWND，graphics *，int，int，int）;
单位（HWND，图形* ，int，int，int，int，int）;
单位（HWND，graphics *，DWORD，float，float，int，int，int）;
unit（ HWND，graphics *，DWORD，float，float，int，int，int，bool）;
unit（unit *）;
~unit（）;
DWORD sideColor（）{return colors [0] .getCode（）;}
int intAttack（）{return attack;}
int intDefence（）{return defense;}
float Attack（）{return attack;}
float Defense（）{return defense;}
int Moved（）{return moved;}
void display（HDC）; //显示在crrent loc
void display（HDC，int，int）; //在特定位置显示
void display（HDC，int）; //显示带偏移量的堆叠
void displayBig（HDC，int，int）;
无效更改（HWND）;
无效更新（ HWND，coord）;
coord nextCoord（char）;
void mover（coord&，int）;
void reset （）;
void tomark（）; //标记死亡单位;
bool标记（）{返回标记;}
coord getCoord（）{return loc;}
coord getCurrent（）{return currentLoc;}
bool canMove（）{return canmove;}
bool isSelect（）{return selected;}
bool inRange（coord）;
void selectOn（）{selected = true;}
void selectOff（）{selected = false;}
void isArt（）{range = 12;}
void cBoxOn（）{combatBox = new tbox;};
void disbersed（）;
void unDisberse（）{disburse = false;}
void write（std :: ofstream&）;
void load（std :: ifstream&）;
void addk（char k）{kind = k;}
};
#endif
I have been writing games and I also read about good programming
techniques. I tend to create large objects that do lots of things. A
good example I have is a unit object. The object controls and holds
everything a unit in my game is supposed to do. What are some some
cures for this kind of large object or are they OK because they
represent one thing. If not what are better ways to design objects
that behave the same way. Would it be better to use inheritance or
friends and where can I look to be able to do the same thing in a
better way?
Here is a unit from a completed game I created. The header file at
least to give an idea of one of my larger objects.
#include<fstream>
#include<vector>
#include<cmath>
#include<map>
#include"coord.h"
#include"color.h"
#include"graphics.h"
#include"tbox.h"
#ifndef UNIT_H
#define UNIT_H
class unit{
protected:
HWND hwnd;
coord loc;
coord currentLoc;
graphics * gr;
tbox * combatBox;
std::vector<color>colors;
std::map<char, coordkeys; //movement engine
coord n; //directions
coord s;
coord e;
coord w;
char kind;
float attack;
float dattack;
float defence;
int move;
int moved;
int dmove;
int range;
bool canmove;
bool selected;
bool mark;
bool disburse;
int col;
void create();
void displayBox(HDC, coord);
int convert(const int n){return n * 16;}
public:
unit();
unit(HWND,graphics*,int,int,int);
unit(HWND,graphics*,int,int,int,int,int);
unit(HWND,graphics*,DWORD,float, float, int, int, int);
unit(HWND,graphics*,DWORD,float, float, int, int, int, bool);
unit(unit*);
~unit();
DWORD sideColor(){return colors[0].getCode();}
int intAttack(){return attack;}
int intDefence(){return defence;}
float Attack(){return attack;}
float Defence(){return defence;}
int Moved(){return moved;}
void display(HDC); //display at crrent loc
void display(HDC, int, int); //display at specific loc
void display(HDC, int); //display with offset for stacking
void displayBig(HDC, int, int);
void change(HWND);
void update(HWND, coord);
coord nextCoord(char);
void mover(coord&, int);
void reset();
void tomark(); //marks unit for death;
bool marked(){return mark;}
coord getCoord(){return loc;}
coord getCurrent(){return currentLoc;}
bool canMove(){return canmove;}
bool isSelect(){return selected;}
bool inRange(coord);
void selectOn(){selected = true;}
void selectOff(){selected = false;}
void isArt(){range = 12;}
void cBoxOn(){combatBox = new tbox;};
void disbersed();
void unDisberse(){disburse = false;}
void write(std::ofstream&);
void load(std::ifstream&);
void addk(char k){kind = k;}
};
#endif
推荐答案
2007-04-20 17:53，JoeC写道：
On 2007-04-20 17:53, JoeC wrote:
我一直在写游戏我还读到了关于良好的编程
技术。我倾向于创建大量的东西，做很多事情。一个
我有一个好的例子是一个单位对象。该对象控制并保持
我游戏中的一个单元应该做的所有事情。什么一些
治疗这种大型物体或者他们没关系，因为他们
代表一件事。如果没有什么是设计对象的更好方法
的行为方式相同。使用继承或
的朋友会更好吗？在哪里可以更好地用
做同样的事情？
I have been writing games and I also read about good programming
techniques. I tend to create large objects that do lots of things. A
good example I have is a unit object. The object controls and holds
everything a unit in my game is supposed to do. What are some some
cures for this kind of large object or are they OK because they
represent one thing. If not what are better ways to design objects
that behave the same way. Would it be better to use inheritance or
friends and where can I look to be able to do the same thing in a
better way?
这取决于很多东西，比如单位是什么。如果单位是很多东西的概括，你的单位级别可以作为任何一个，那么你应该把它分解成一个单元级的
包含在不同单元类型之间共享的所有代码，并为每种单元类型创建子类
。或者也许创建一个子类，如果只能识别单元类型子集中常见的代码，那么
是进一步的子类。
从发布的代码看起来该单元是一个图形对象，可以在屏幕上绘制
，这个功能大部分都可能是
投入基础班。保存和加载方法不一定要成为会员，也许他们会更好地成为朋友，所以很难
告诉我们给出的代码。
-
Erik Wikstr？m
That depends on a lot of things, like what a unit is. If unit is a
generalization of a lot of things and your unit-class can act as any of
those then you should definitely break it down into a unit-class which
has all code shared among the different unit types and create subclasses
of it for each of the unit types. Or perhaps create a subclasses which
are further subclasses if it''s possible to identify code that is common
for only a subset of the unit-types.
From the code posted it looks like the unit is a graphical object that
can be drawn on the screen, much of this functionality could probably be
put in a base-class. The save and load methods does not necessarily have
to be members, perhaps they are better of as friends or so, it''s hard to
tell just from looking at the code given.
--
Erik Wikstr?m
4月20日，11日：53：00，JoeC< enki ... @ yahoo.comwrote：
On Apr 20, 11:53 am, JoeC <enki...@yahoo.comwrote:
我一直在写游戏，我也读过很好的编程
技巧。我倾向于创建大量的东西，做很多事情。一个
我有一个好的例子是一个单位对象。该对象控制并保持
我游戏中的一个单元应该做的所有事情。什么一些
治疗这种大型物体或者他们没关系，因为他们
代表一件事。如果没有什么是设计对象的更好方法
的行为方式相同。使用继承或
的朋友会更好吗？在哪里可以更好地用
做同样的事情？
I have been writing games and I also read about good programming
techniques. I tend to create large objects that do lots of things. A
good example I have is a unit object. The object controls and holds
everything a unit in my game is supposed to do. What are some some
cures for this kind of large object or are they OK because they
represent one thing. If not what are better ways to design objects
that behave the same way. Would it be better to use inheritance or
friends and where can I look to be able to do the same thing in a
better way?
[snip]
没有一个单一的答案，但有哲学观念
用于寻找正确的答案。或者至少是一个更好的答案。
将对象视为服务的导出者。如果该服务
作为统一的单个集合是有意义的，那么这是一个很好的
对象。如果那个对象碰巧是巨大的，那并不总是坏事。
正如Erik所说，你很可能会使用继承来放
单个类中的常用功能，并且只实现一次
。这将使一个对象集合中的每一个更简单，但代价是一些抽象。它并不总是很容易决定这是否是一场胜利。所以，看着你的单位，你可能会考虑继承一类
移动的东西。或攻击的东西或或在屏幕上绘制
的东西等等。但是，如果只有一个单元格，那可能不是一个很大的改进。
另一个常见的习语是构图。也许你可以有一个移动的东西。 class，并给每个单元一个数据
成员，它是移动的东西的实例。
然后你可以将移动分开。来自
其余课程的服务，只实现移动一次。
再次，这将使每个对象集合
更简单，牺牲了一些复杂性
的设计。再说一次，判断
这是否合理并不总是那么容易。
你想在
$时考虑这些服务类b $ b你有一些东西会对几个班级来说很常见。例如，在图形
重度程序中，在
屏幕上绘制可能是相当常见的。因此，许多其他代码使用的
服务类很有意义。
要在继承和组合之间做出决定，请考虑
关于类如何相关。你有一个单元
级。你的程序或游戏还有其他东西
是种类吗？那个单位？如果有，那么你可能想要继承。
。如果你需要一个单位
并且可以放一个树单位在那里，作为一个例子，
这是继承的真正好例子。但也许
你有单位含义的东西可以移动，
和背景的东西，比如树木，如某些画出的那样
其他方式有更简单的数据。所以这可能是组合的好例子。你添加到单位
和树上他们需要的部分。
尝试将你的程序的任务分析成
服务作为单个整体有意义，但是如果你试图细分它们就没有意义。
寻找有很多互动的区域
紧密绑定的数据，对象，方法等，并尝试使用
将它们保存在一个或几个对象中。当
服务之间的连接非常松散时，比如说一个或只有两个函数的电话，那就是
现货的好候选人将事物分成两类或更多类。如果有两个
对象最后拨打多个电话，
也许他们不应该是两个对象而是一个。
并试着考虑
包之间的关系。特别地，寻找是是是。并且有一个
和与...对话关系。
袜子
[snip]
There is no one-size answer, but there are philosophical notions
to use to hunt for the right answer. Or at least a better answer.
Think of an object as an exporter of a service. If that service
makes sense as a unified single collection, then that''s a good
object. If that object happens to be enormous, it is not always
a bad thing.
As Erik said, you may well be able to use inheritance to put
common features in a single class, and only implement them
one time. That will make each of a collection of objects
simpler at the expense of some abstraction. It is not always
an easy decision whether that''s a win or not. So, looking at
your unit, you might think about inheriting from a class of
"thing that moves" or "thing that attacks" or "thing that gets
drawn on the screen" and so on. However, if there''s only one
kind of unit, that may not be a big improvement.
Another common idiom is composition. Maybe you can have
a "thing that moves" class, and give each unit a data
member that is an instance of the "thing that moves."
You could then divide the "moving" service from the
rest of the class, and only implement moving once.
Again, this will make each of a collection of objects
somewhat simpler at the expense of some complexity
in the design. Again, it''s not always easy to decide if
this makes sense.
You want to think about such service classes when
you have something that is going to be common to
several classes. For example, getting drawn on the
screen is likely to be quite common in a graphic
heavy program. So that makes a lot of sense as a
service class that a lot of other code uses.
To decide between inheritance and composition, think
about how the classes are related. You''ve got a unit
class. Are there other things in your program or game
that are "kinds of" that unit? If there are, then you
probably want to think inheritance. If you need a unit
and can put a "tree unit" there, just as an example,
that''s a real good case for inheritance. But maybe
you''ve got unit meaning things that can move around,
and background stuff, like trees, as drawn in some
other way with much simpler data. So that might be
a good case for composition. You add onto the unit
and the tree the portions they need.
Try to analyse your program''s task into packages of
services that make sense as single wholes, but that
would not make sense if you tried to subdivide them.
Look for areas where there is a lot of interaction among
tightly bound data, objects, methods, etc., and try
to keep them in one or a few objects. When there is
very loose connection between services, say one or
two function calls only, that''s a good candidate for a
spot to divide things into two or more classes. If two
objects wind up calling eachother with many calls,
maybe they ought not to be two objects but one.
And try to think in terms of relationships between the
packages. In particular look for "is a" and "has a"
and "talks to a" relationships.
Socks
JoeC< en ***** @ yahoo。在消息中写了...
JoeC <en*****@yahoo.comwrote in message ...
这是我创建的已完成游戏中的一个单位。
的头文件最不能让我知道一个较大的对象。
Here is a unit from a completed game I created. The header file at
least to give an idea of one of my larger objects.
一件小事（与你的问题无关）：把你的标题包括
警卫
''围绕''标题中的所有内容。
[在小型项目中，它没什么区别。在大型项目中，它将更快地解析
（因此编译速度更快）。 ]
#ifndef UNIT_H //把这些放在这里。
#define UNIT_H
//现在编译器不必检查包含保护
//每次*每个*以下标题（仅限第一次使用）。
One little thing (not related to your question): Put your header include
guards
''around'' everything in your header.
[ On small projects, it makes little difference. On big projects, it will
parse faster
(thus, compile faster). ]
#ifndef UNIT_H // put these here.
#define UNIT_H
// now the compiler does not have to check the include guards
// in *each* of the following headers every time (only the first use).
>
#include< fstream>
#include< vector>
#include< cmath>
#include< map>
#include" coord.h"
#include" color.h"
#include" graphics.h"
#include" tbox.h"
>
#include<fstream>
#include<vector>
#include<cmath>
#include<map>
#include"coord.h"
#include"color.h"
#include"graphics.h"
#include"tbox.h"
// #ifndef UNIT_H //移到文件顶部
// #define UNIT_H
// #ifndef UNIT_H // move to top of file
// #define UNIT_H
>
class unit {protected：
>
class unit{ protected:
// ... ..
// .....
public：
public:
// .....
// .....
}; //班级单位
#endif
}; // class unit
#endif
-
Bob R
POVrookie
--
Bob R
POVrookie
这篇关于关于大型物体的问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
