From the book 'Extreme Programming Explained' by Kent Beck (p. 48):
- [*]"Designing is creating a structure that organizes the logic in the system.
Good design organizes the logic so that a change in one part of the system
doesn't always require a change in another part of the system. Good design
ensures that every piece of logic in the system has one and only one home.
Good design puts the logic near the data it operates on. Good design allows
the extension of the system with changes in only one place.
Bad design is just the opposite. One conceptual change requires changes to
many parts of the system. Logic has to be duplicated. Eventually, the cost
of a bad design becomes overwhelming. You just can't remember any more
where all the implicitly linked changes have to take place. You can't add a
new function without breaking existing functions."[/list]
Our basic 'Coding Standard' is the common M-V-C approach. All programs consist of exactly three parts, each with a specific purpose, and Clash is no exception.
- [*]'DataModel' classes that hold all the state information for the
Game data.
[*]'Data View' classes (panels and such)
[*]'Controller' classes -- game state, turn logic, File IO stuff (including streaming for multiplay), etc.[/list]
All code should be seperated into these three parts. The first posts below will offer 'templates' for each of type of class that coders may use to ease/speed their development.
The posts after those will lay out the specific object hierarchy of game objects, and more detail on specific tasks and components needed.
P.S. -- if you disagree with anything in this thread, bring it up in the Clash Coding Standards Discussion thread. This is all subject to debate and revision -- open source, and all that!
[This message has been edited by F_Smith (edited August 13, 2000).]
Comment