更好的程序设计？ [英] Better program design?

问题描述

我是一名自学成才的程序员，我已经找到了大部分语法但

设计我的程序是一项挑战。我意识到有很多

方法可以设计一个程序，但有什么好的规则要遵循

创建一个程序？


我正在写一个地图游戏程序。我创建了几个对象：board

对象是一个整数数组，每个数字0-5是一种

地形，一个地形对象，是一个地形类型数组并且地图上的每个

数字都对应于地图上的种类地形。最后我

有一个单位对象：


#include" graphic.h"

#include" libs.h" ;

#include" board.h"


#ifndef UNIT_H

#define UNIT_H

类单位：公共图形{


std :: map< char，coordkeys; //移动引擎

coord n; //指示

coord s;

coord e;

coord w;


int xloc ; // x location

int yloc; // ylocation

int r，g，b; //颜色

int attack; //攻击因素

int defense; //防御因素

int move; // movemnt factor

int moving; //使用的因子数

void make（）;


public：

unit（）;

void SetGr（int，int，int，BYTE c []）; //设置图形信息

void SetData（int，int，int）; //攻击性防御和移动因素集合

void Place（int，int）; //放在地图上

void moveUD（int，int）; //处理下来的动作

//方向，进入下一个空间的成本。

void moveLR（int，int）;

void newMove （char，board *，terrain trn []）;

void show（HWND）; //显示单位

void reset（）; // restes movemnt

int red（）{return r;} //返回显示的颜色

int grn（）{return g;}

int blu（）{return b;}

int getXloc（）const {return xloc;} //返回位置

int getYloc（）const {return yloc; }

bool canMove（）; //仍然有移动因子。

};

void unit :: newMove（char ch，board * b，terrain trn []）{


int n，mv;

int tempX = xloc + keys [ch] .x;

int tempY = yloc + keys [ch]。 y;


mv = trn [b-> GetSpace（tempY，tempX）]。move（）;

if（move 0&& mv！= 0）{

移动 - = mv;

xloc = tempX;

yloc = tempY;

}

}


案例VK_UP：


if（red）{rteam [t1m] .newMove（ ''n''，b，trn）;}

else {yteam [t2m] .newMove（''n''，b，trn）;}


这一切都有效，我的单位在地图上移动，但设计好吗

将电路板和地形对象发送给函数？我是b $ b计划有一个战斗功能，甚至可能涉及到矿石

物体，即地图和地形两侧的单位。

是否有一些规则或指南我可以写出更好的程序？

例如我被告知要求对象做事。

解决方案

JoeC写道：

>我是一名自学成才的程序员，我已经找到了大部分语法但

设计我的程序是一个挑战。我意识到有很多

方法可以设计一个程序但是有什么好的规则要遵循

创建一个程序？

使用单元测试装备，例如UnitTest ++，并在你编写代码以通过测试之前编写测试用例。


这个简单的步骤可以防止长时间的调试。

int xloc; // x location

int yloc; // ylocation

接下来，代码工作后，你应该重构删除重复。在

这种情况​​下，你有一个名为Point的潜在对象，其成员为x和y。然后

你可以写Point loc;在这里，你可以在任何地方重新使用点，现在你有x和y。

int red（）{return r ;} //返回显示的颜色

int grn（）{return g;}

int blu（）{return b;}

类似，这里的单个访问器将返回一个Color对象。

int getXloc（）const {return xloc;} //返回位置

int getYloc（）const {return yloc;}

这些

bool canMove（）; //仍然有运动因素。

接下来，OO设计是用多态来替换条件语句（if和switch）

。如果那只是一个名为virtual maybeMove（）的方法，那么你可以从你的单元中获得一个MobileUnit。那么Unit :: maybeMove（）将会无所事事，而且MobileUnit :: maybeMove（）会移动。


OO是关于将行为放在对象中 - 不是关于填充

对象充满数据并将行为放在他们之外。

这一切都有效，我的单位在地图上移动但是是不是很好的设计

将电路板和地形对象发送给该功能？我是b $ b计划有一个战斗功能，甚至可能涉及到矿石

物体，即地图和地形两侧的单位。

也许或不是。这些项目不应该是全球性的。如果你的设计是

否则清洁那么这可能是最好的方法。


更重要的是，我的其他指南试图制作一个程序的原创

设计不如其测试重要。如果您可以在程序运行后升级设计，您可以使用程序本身来了解最好的设计是什么。

是否有一些规则或指南我可以编写更好的程序？

例如我被告知要求对象做事情。

谷歌这些，引用：


测试驱动开发

" ;重构

好莱坞原则"

"依赖倒置原则"


-

Phlip
http://c2.com/cgi/wiki?ZeekLand < - 不是博客!!!

Phlip写道：

JoeC写道：

我是一名自学成才的程序员，我已经找到了大部分语法，但

设计我的程序是一个挑战。我意识到有很多

方法可以设计一个程序但是有什么好的规则要遵循

创建一个程序？

使用单元测试装置，例如UnitTest ++，并在你编写代码以通过测试之前编写测试用例。


这个简单的步骤可以防止长时间的调试。

int xloc; // x location

int yloc; // ylocation

接下来，在代码工作之后，你应该重构删除重复。在

这种情况​​下，你有一个名为Point的潜在对象，其成员为x和y。然后

你可以写Point loc;在这里，你可以在任何地方重新使用点，现在你有x和y。

int red（）{return r ;} //返回显示的颜色

int grn（）{return g;}

int blu（）{return b;}

类似，这里的单个访问器将返回一个Color对象。

这真的很重要吗？这将是一个很像coord

struct的结构。 paint（obj.gcolor（）。r，obj.gcolor（）。b

paint（obj，r（），obj.b（）......

int getXloc（）const {return xloc;} //返回位置

int getYloc（）const {return yloc;}

这些

bool canMove（）; //仍有移动因子。

接下来，OO设计是用多态来替换条件语句（if和switch）

。如果那只是一个名为virtual maybeMove（）的方法，
你可以从你的单位派生出一个MobileUnit。然后Unit :: maybeMove（）会

什么也不做，而MobileUnit :: maybeMove（）会移动。

我试图找出如何将移动概念保持为单独的
对象。我能够从我的单元类和地形中消失

图形课。用颜色做同样的事情可能是个好主意。 >
class。


我尽量避免动态绑定。我发现它唯一有用的是

将simmilliar对象放在同一个容器中。地形和

单位在不同的容器中，是不同的对象。

>

OO是关于将行为放在对象中 - 而不是填充

对象已满数据并将行为置于其外部。

我试图将行为放在对象中。我告诉对象

做什么。可以移动是对象的内部。如果你告诉一个物体移动

，当它没有任何移动点时，它什么都不做。

>

这一切都有效，我的单位在地图上移动但设计好了

将电路板和地形对象发送到函数？我是b $ b计划有一个战斗功能，甚至可能涉及到矿石

物体，即地图和地形两侧的单位。

也许或不是。这些项目不应该是全球性的。如果您的设计是

否则清洁，那么这可能是最好的方法。

我的对象不是全局的。它们是enxtent，因此它们可以在程序的创建部分创建，然后可以在程序的
winproc部分中看到它们。我正在使用win32来支持图形。

>

更重要的是，我的其他指南试图制作一个程序的原始

设计比它的测试重要。如果您可以在程序运行后升级设计，您可以使用程序本身来了解最好的设计将是什么样的b $ b。

自从我第一次编写程序以来，我做了一些升级。大多数情况下，我把

的移动函数的工作放在对象中，而不是在
之外。但问题是我有几个对象影响每个其他的b $ b我担心我的功能太麻烦了，我的

编译器有时会开始抱怨。

>

是否有一些规则或指南我可以编写更好的程序？

例如我被告知要询问对象做事。

谷歌这些，引用：


测试驱动开发

" ;重构

好莱坞原则"

"依赖倒置原则"


-

Phlip
http://c2.com/cgi/wiki?ZeekLand < - 不是博客!!!

文章< 11 ********************** @ m79g2000cwm.googlegroups .com>，

" JoeC" < en ***** @ yahoo.comwrote：

我是一名自学成才的程序员，我已经找到了大部分语法，但是

设计我的课程是一项挑战。我意识到有很多

方法可以设计一个程序，但有什么好的规则要遵循

创建一个程序？


我正在写一个地图游戏程序。我创建了几个对象：board

对象是一个整数数组，每个数字0-5是一种

地形，一个地形对象，是一个地形类型数组并且地图上的每个

数字都对应于地图上的种类地形。最后我

有一个单位对象：


#include" graphic.h"

#include" libs.h" ;

#include" board.h"


#ifndef UNIT_H

#define UNIT_H

类单位：公共图形{


std :: map< char，coordkeys; //移动引擎

coord n; //指示

coord s;

coord e;

coord w;


int xloc ; // x location

int yloc; // ylocation

int r，g，b; //颜色

int attack; //攻击因素

int defense; //防御因素

int move; // movemnt factor

int moving; //使用的因子数

这是一个非常多的变量。我注意到''newMove''只使用

键，xloc，yloc和移动。你可能在这个课程中埋藏了不止一个概念

。


过去我觉得有用的一个想法......得到一些方格纸（或者使用

a电子表格程序。）列出第一列中的成员变量，

和第一行中的成员函数。然后通过并在每个使用该特定

成员变量的成员函数的单元格中放置一个X

。您可能会发现在函数的适当子集中使用的几个变量只是

，它们仅用于那个

子集。如果是这样的话，最好将它们分组在一个类中。

void make（）;


public ：

unit（）;

void SetGr（int，int，int，BYTE c []）; //设置图形信息

void SetData（int，int，int）; //攻击性防御和移动因素集合

void Place（int，int）; //放在地图上

void moveUD（int，int）; //处理下来的动作

//方向，进入下一个空间的成本。

void moveLR（int，int）;

void newMove （char，board *，terrain trn []）;

void show（HWND）; //显示单位

void reset（）; // restes movemnt

int red（）{return r;} //返回显示的颜色

int grn（）{return g;}

int blu（）{return b;}

int getXloc（）const {return xloc;} //返回位置

int getYloc（）const {return yloc; }

bool canMove（）; //仍然有剩余的移动因子。


};


void unit :: newMove（char ch，board * b，terrain trn [ ]）{$ / $

int n，mv;

int tempX = xloc + keys [ch] .x;

int tempY = yloc + keys [ch] .y;


mv = trn [b-> GetSpace（tempY，tempX）]。move（）;

如果（移动0&& mv！= 0）{

移动 - = mv;

xloc = tempX;

yloc = tempY ;

}

}


案例VK_UP：


if（red） {rteam [t1m] .newMove（''n''，b，trn）;}

else {yteam [t2m] .newMove（''n''，b，trn）;}


一切正常，我的单位在地图上移动，但设计好吗

将电路板和地形对象发送给该功能？

我会将函数限制为只需要它所需的数据。我会倾向于，例如，仅从

函数实际使用的trn发送一个单元格，或者可能将其限制为仅仅由
..move（）。这样做将无需将电路板发送到newMove

all。

是否有一些规则或指南我可以去写出更好的程序？

例如，我被告知要求对象做事。

有许多启发式方法。 Riel的书面向对象的设计启发式（B-B）具有一堆C ++编码标准和C ++编码标准。作者：Sutter和Alexandrescu

有一堆，足够的绳索射击你自己的脚作者：Holub有一个很好的b $ b $束，大规模C ++设计 Lakos有一堆，有效

C ++列表由迈耶斯，列表继续。这些书中的许多都有与其他书中的启发式冲突的启发式方法。一些

甚至在同一本书中也有冲突的启发式！你必须阅读启发式了解他们的动机，并自己决定

，这与你的特殊情况更相关。


我认为应该在每个程序员的书架上放一本书，并且每隔一年阅读一次至少

......实用程序员亨特和托马斯。

I am a self taught programmer and I have figured out most syntax but
desigining my programs is a challenge. I realize that there are many
ways to design a program but what are some good rules to follow for
creating a program?

I am writing a map game program. I created several objects: board
object that is an array of integers each number 0-5 is a kind of
terrain, a terrain object that is an array of terrain types and each
number of the map coresponds to a kind terrain on the map. Finally I
have a unit object:

#include "graphic.h"
#include "libs.h"
#include "board.h"

#ifndef UNIT_H
#define UNIT_H

class unit : public graphic{

std::map<char, coordkeys; //movement engine
coord n; //directions
coord s;
coord e;
coord w;

int xloc; //x location
int yloc; //ylocation
int r, g, b; //color
int attack; //attack factor
int defence; //defence facor
int move; //movemnt factor
int moved; //the number of factors used
void make();

public:
unit();
void SetGr(int, int, int, BYTE c[]); //sets graphic info
void SetData(int, int, int);//sets ofensive defensive and move facors
void Place(int, int); //puts on the map
void moveUD(int, int); //handled up down movment
//direction, cost to enter next space.
void moveLR(int, int);
void newMove(char, board *,terrain trn[]);
void show(HWND); //displays the unit
void reset(); //restes movemnt
int red(){return r;} //returns colors for display
int grn(){return g;}
int blu(){return b;}
int getXloc()const {return xloc;} //returns location
int getYloc()const {return yloc;}
bool canMove(); //still has movement factors left.
};
void unit::newMove(char ch, board * b, terrain trn[]){

int n, mv;
int tempX = xloc + keys[ch].x;
int tempY = yloc + keys[ch].y;

mv = trn[b->GetSpace(tempY, tempX)].move();
if(moved 0 && mv != 0){
moved -= mv;
xloc = tempX;
yloc = tempY;
}
}

case VK_UP:

if(red){rteam[t1m].newMove(''n'',b,trn);}
else{ yteam[t2m].newMove(''n'',b,trn);}

This all works and my units move around the map but is it good design
to send up the board and terrain objects to the function? I am
planning to have a fight function and that may involve even ore
objects, that is units from both sides the map and the kind of terrain.
Are there some rules or guides I can go by to write better programs?
For example I was instructed to tell on ask objects to do things.

解决方案

JoeC wrote:

>I am a self taught programmer and I have figured out most syntax but
desigining my programs is a challenge. I realize that there are many
ways to design a program but what are some good rules to follow for
creating a program?

Use a unit test rig, such as UnitTest++, and write test cases before you
write the code to pass the tests.

That simple step prevents many hours of debugging.

int xloc; //x location
int yloc; //ylocation

Next, after the code works, you should "refactor" to remove duplication. In
this case, you have a latent object called Point, with members x and y. Then
you can write Point loc; here, and you can re-use the Point everywhere that
you have x and y now.

int red(){return r;} //returns colors for display
int grn(){return g;}
int blu(){return b;}

Similary, a single accessor, here, would return a Color object.

int getXloc()const {return xloc;} //returns location
int getYloc()const {return yloc;}

And these

bool canMove(); //still has movement factors left.

Next, OO design is about replacing conditional statements (if and switch)
with polymorphism. If that were simply a method called virtual maybeMove(),
you could derive a MobileUnit from your Unit. Then Unit::maybeMove() would
do nothing, and MobileUnit::maybeMove() would move.

OO is about putting the behaviors inside the objects - not about stuffing
objects full of data and putting the behaviors outside them.

This all works and my units move around the map but is it good design
to send up the board and terrain objects to the function? I am
planning to have a fight function and that may involve even ore
objects, that is units from both sides the map and the kind of terrain.

Maybe or maybe not. The items shouldn''t be global. If your design is
otherwise clean then this might be the best way.

More importantly, my other guidelines attempt to make a program''s original
design less important than its tests. If you can upgrade the design after
the program works, you can use the program itself to learn what the best
design will be.

Are there some rules or guides I can go by to write better programs?
For example I was instructed to tell on ask objects to do things.

Google for these, with quotes:

"test driven development"
"refactoring"
"hollywood principle"
"dependency inversion principle"

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

Phlip wrote:

JoeC wrote:

I am a self taught programmer and I have figured out most syntax but
desigining my programs is a challenge. I realize that there are many
ways to design a program but what are some good rules to follow for
creating a program?

Use a unit test rig, such as UnitTest++, and write test cases before you
write the code to pass the tests.

That simple step prevents many hours of debugging.

int xloc; //x location
int yloc; //ylocation

Next, after the code works, you should "refactor" to remove duplication. In
this case, you have a latent object called Point, with members x and y. Then
you can write Point loc; here, and you can re-use the Point everywhere that
you have x and y now.

int red(){return r;} //returns colors for display
int grn(){return g;}
int blu(){return b;}

Similary, a single accessor, here, would return a Color object.

Does that realy matter? It would be a structure much like a coord
struct. paint(obj.gcolor().r, obj.gcolor().b
paint(obj,r(),obj.b()...

int getXloc()const {return xloc;} //returns location
int getYloc()const {return yloc;}

And these

bool canMove(); //still has movement factors left.

Next, OO design is about replacing conditional statements (if and switch)
with polymorphism. If that were simply a method called virtual maybeMove(),
you could derive a MobileUnit from your Unit. Then Unit::maybeMove() would
do nothing, and MobileUnit::maybeMove() would move.

I was trying to figure out how I could keep the move concept a seperate
object. I was able to derrive my unit class and terrain from my
graphic class. It may be a good idea to do the same with a color
class.

I try to avoid dynamic binding. The only thing I find it useful for is
putting simmilliar objects in the same container. The terrain and the
units are in different containers and are different objects.

>
OO is about putting the behaviors inside the objects - not about stuffing
objects full of data and putting the behaviors outside them.

I tried to put the behavior in the objects. I tell the objects what to
do. Can move is internal to the object. If you tell an object to move
when it dosn''t have any movement points, it does nothing.

>

This all works and my units move around the map but is it good design
to send up the board and terrain objects to the function? I am
planning to have a fight function and that may involve even ore
objects, that is units from both sides the map and the kind of terrain.

Maybe or maybe not. The items shouldn''t be global. If your design is
otherwise clean then this might be the best way.

No my objects are not global. They are to enxtent so that they can be
created in the create part of the program and then are visible to
winproc part of the program. I am using win32 for graphics support.

>
More importantly, my other guidelines attempt to make a program''s original
design less important than its tests. If you can upgrade the design after
the program works, you can use the program itself to learn what the best
design will be.

I have done some upgrade since I first wrote the program. Mostly I put
the workings of the move function in the object instead of outside of
it. But the problem is that I have several objects that influence each
other and I am worried that my functions will be too cumbersom and my
compiler will start to complain at times.

>

Are there some rules or guides I can go by to write better programs?
For example I was instructed to tell on ask objects to do things.

Google for these, with quotes:

"test driven development"
"refactoring"
"hollywood principle"
"dependency inversion principle"

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!

In article <11**********************@m79g2000cwm.googlegroups .com>,
"JoeC" <en*****@yahoo.comwrote:

I am a self taught programmer and I have figured out most syntax but
desigining my programs is a challenge. I realize that there are many
ways to design a program but what are some good rules to follow for
creating a program?

I am writing a map game program. I created several objects: board
object that is an array of integers each number 0-5 is a kind of
terrain, a terrain object that is an array of terrain types and each
number of the map coresponds to a kind terrain on the map. Finally I
have a unit object:

#include "graphic.h"
#include "libs.h"
#include "board.h"

#ifndef UNIT_H
#define UNIT_H

class unit : public graphic{

std::map<char, coordkeys; //movement engine
coord n; //directions
coord s;
coord e;
coord w;

int xloc; //x location
int yloc; //ylocation
int r, g, b; //color
int attack; //attack factor
int defence; //defence facor
int move; //movemnt factor
int moved; //the number of factors used

That''s an awful lot of variables. I notice that ''newMove'' only uses
keys, xloc, yloc, and moved. You may have more than one concept buried
in this class.

One idea that I found useful in the past... Get some graph paper (or use
a spreadsheet program.) List the member-variables in the first column,
and the member-functions in the first row. Then go through and put an X
in the cell of each member-function that uses that particular
member-variable. You may find that several of the variables are only
used in a proper subset of the functions, and they are only used in that
subset. If so, it would be a good idea to group them in a class.

void make();

public:
unit();
void SetGr(int, int, int, BYTE c[]); //sets graphic info
void SetData(int, int, int);//sets ofensive defensive and move facors
void Place(int, int); //puts on the map
void moveUD(int, int); //handled up down movment
//direction, cost to enter next space.
void moveLR(int, int);
void newMove(char, board *,terrain trn[]);
void show(HWND); //displays the unit
void reset(); //restes movemnt
int red(){return r;} //returns colors for display
int grn(){return g;}
int blu(){return b;}
int getXloc()const {return xloc;} //returns location
int getYloc()const {return yloc;}
bool canMove(); //still has movement factors left.
};
void unit::newMove(char ch, board * b, terrain trn[]){

int n, mv;
int tempX = xloc + keys[ch].x;
int tempY = yloc + keys[ch].y;

mv = trn[b->GetSpace(tempY, tempX)].move();
if(moved 0 && mv != 0){
moved -= mv;
xloc = tempX;
yloc = tempY;
}
}

case VK_UP:

if(red){rteam[t1m].newMove(''n'',b,trn);}
else{ yteam[t2m].newMove(''n'',b,trn);}

This all works and my units move around the map but is it good design
to send up the board and terrain objects to the function?

I would limit the function to only the data it needs. I would be
inclined to, for example, only send the one cell from trn that the
function actually uses, or maybe limit it to just the int returned by
..move(). Doing so would remove the need to send the board to newMove at
all.

Are there some rules or guides I can go by to write better programs?
For example I was instructed to tell on ask objects to do things.

There are many heuristics. The book "Object-Oriented Design Heuristics"
by Riel has a bunch, "C++ Coding Standards" by Sutter and Alexandrescu
has a bunch, "Enough Rope to Shoot Youreelf in the Foot" by Holub has a
bunch, "Large Scale C++ Design" by Lakos has a bunch, the "Effective
C++" series by Meyers, the list goes on and on. Many of these books have
heuristics that conflict with heuristics from a different book. A few
even have heuristics that conflict within the same book! You have to
read the heuristics understand the motivation for them and decide for
yourself which is more relevant to your particular situation.

One book I think should be on every programmer''s shelf and read at least
every other year... "The Pragmatic Programmer" by Hunt and Thomas.

这篇关于更好的程序设计？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！