From MapbenderWiki

representation of an object. Collection of data and routines that share a cohesive purpose.

Contents 1 Why classes? 2 Class hierarchy 3 Layout 3.1 Class name 3.2 Sort order 4 General advice

Why classes?

• to work with real world (or abstract) entities
• to minimize complexity by hiding implementation details
• to isolate complexity and limit effect of changes
• to produce reusable code
• to set levels of abstraction to present complex operations in a simplified form

Class hierarchy

• interface = public routines (minimizing the interface minimizes complexity)
• internal operations = private routines
• member data = private variables only (hiding information minimizes complexity)

Layout

Class name

• first letter of class name shall be uppercase, first letter of each following word shall be uppercase as well.
• underscore is forbidden in class names!

Sort order

• constructor
• public routines
• private routines
• member data

One class per file is recommended

General advice

• encapsulation: minimize the extent to which a class collaborates with other classes
• treat even simple items as objects
• initialise member data in constructor
• provide public routines in pairs
  • get/set
  • first/last
  • begin/end
  • min/max
  • insert/delete
  • add/remove
  • next/previous
  • create/destroy
  • increment/decrement
  • open/close
  • show/hide
  • etc