更好的程序设计？

类单位：公共图形{ 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 butdesigining my programs is a challenge. I realize that there are manyways to design a program but what are some good rules to follow forcreating a program?I am writing a map game program. I created several objects: boardobject that is an array of integers each number 0-5 is a kind ofterrain, a terrain object that is an array of terrain types and eachnumber of the map coresponds to a kind terrain on the map. Finally Ihave a unit object:#include "graphic.h"#include "libs.h"#include "board.h"#ifndef UNIT_H#define UNIT_Hclass unit : public graphic{std::map<char, coordkeys; //movement enginecoord n; //directionscoord s;coord e;coord w;int xloc; //x locationint yloc; //ylocationint r, g, b; //colorint attack; //attack factorint defence; //defence facorint move; //movemnt factorint moved; //the number of factors usedvoid make();public:unit();void SetGr(int, int, int, BYTE c[]); //sets graphic infovoid SetData(int, int, int);//sets ofensive defensive and move facorsvoid Place(int, int); //puts on the mapvoid 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 unitvoid reset(); //restes movemntint red(){return r;} //returns colors for displayint grn(){return g;}int blu(){return b;}int getXloc()const {return xloc;} //returns locationint 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 designto send up the board and terrain objects to the function? I amplanning to have a fight function and that may involve even oreobjects, 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 butdesigining my programs is a challenge. I realize that there are manyways to design a program but what are some good rules to follow forcreating a program?Use a unit test rig, such as UnitTest++, and write test cases before youwrite the code to pass the tests.That simple step prevents many hours of debugging. int xloc; //x location int yloc; //ylocationNext, after the code works, you should "refactor" to remove duplication. Inthis case, you have a latent object called Point, with members x and y. Thenyou can write Point loc; here, and you can re-use the Point everywhere thatyou 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() woulddo nothing, and MobileUnit::maybeMove() would move.OO is about putting the behaviors inside the objects - not about stuffingobjects full of data and putting the behaviors outside them.This all works and my units move around the map but is it good designto send up the board and terrain objects to the function? I amplanning to have a fight function and that may involve even oreobjects, 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 isotherwise clean then this might be the best way.More importantly, my other guidelines attempt to make a program''s originaldesign less important than its tests. If you can upgrade the design afterthe program works, you can use the program itself to learn what the bestdesign 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 youwrite the code to pass the tests.That simple step prevents many hours of debugging. int xloc; //x location int yloc; //ylocationNext, after the code works, you should "refactor" to remove duplication. Inthis case, you have a latent object called Point, with members x and y. Thenyou can write Point loc; here, and you can re-use the Point everywhere thatyou 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 coordstruct. paint(obj.gcolor().r, obj.gcolor().bpaint(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() woulddo nothing, and MobileUnit::maybeMove() would move.I was trying to figure out how I could keep the move concept a seperateobject. I was able to derrive my unit class and terrain from mygraphic class. It may be a good idea to do the same with a colorclass.I try to avoid dynamic binding. The only thing I find it useful for isputting simmilliar objects in the same container. The terrain and theunits are in different containers and are different objects.>OO is about putting the behaviors inside the objects - not about stuffingobjects full of data and putting the behaviors outside them.I tried to put the behavior in the objects. I tell the objects what todo. Can move is internal to the object. If you tell an object to movewhen 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 isotherwise clean then this might be the best way.No my objects are not global. They are to enxtent so that they can becreated in the create part of the program and then are visible towinproc part of the program. I am using win32 for graphics support.>More importantly, my other guidelines attempt to make a program''s originaldesign less important than its tests. If you can upgrade the design afterthe program works, you can use the program itself to learn what the bestdesign will be.I have done some upgrade since I first wrote the program. Mostly I putthe workings of the move function in the object instead of outside ofit. But the problem is that I have several objects that influence eachother and I am worried that my functions will be too cumbersom and mycompiler 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 butdesigining my programs is a challenge. I realize that there are manyways to design a program but what are some good rules to follow forcreating a program?I am writing a map game program. I created several objects: boardobject that is an array of integers each number 0-5 is a kind ofterrain, a terrain object that is an array of terrain types and eachnumber of the map coresponds to a kind terrain on the map. Finally Ihave a unit object:#include "graphic.h"#include "libs.h"#include "board.h"#ifndef UNIT_H#define UNIT_Hclass 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 usedThat''s an awful lot of variables. I notice that ''newMove'' only useskeys, xloc, yloc, and moved. You may have more than one concept buriedin this class.One idea that I found useful in the past... Get some graph paper (or usea spreadsheet program.) List the member-variables in the first column,and the member-functions in the first row. Then go through and put an Xin the cell of each member-function that uses that particularmember-variable. You may find that several of the variables are onlyused in a proper subset of the functions, and they are only used in thatsubset. 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 designto send up the board and terrain objects to the function?I would limit the function to only the data it needs. I would beinclined to, for example, only send the one cell from trn that thefunction 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 atall.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 Alexandrescuhas a bunch, "Enough Rope to Shoot Youreelf in the Foot" by Holub has abunch, "Large Scale C++ Design" by Lakos has a bunch, the "EffectiveC++" series by Meyers, the list goes on and on. Many of these books haveheuristics that conflict with heuristics from a different book. A feweven have heuristics that conflict within the same book! You have toread the heuristics understand the motivation for them and decide foryourself which is more relevant to your particular situation.One book I think should be on every programmer''s shelf and read at leastevery other year... "The Pragmatic Programmer" by Hunt and Thomas. 这篇关于更好的程序设计？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！