Swaim's Object Oriented Programming Prime Directive:

In Star Trek one of the most important Starfleet directives is the Prime Directive which states that starships can visit and observe new worlds but they are not to interact with these worlds so as to alter their state of progress in technology.
I have modified the idea a little and applied it to object oriented programming. An object can be altered by "outside influences" which change its state. However, instead of the program (the "outside influencer") being responsible for keeping the object in a "correct" state, the object itself is responsible for maintaining its own internal integrety. This allows the program to concentrate on using the object without worrying about the correctness of the data the object contains. The Prime Directive in Object Oriented Programming is stated this way:

An object must never allow itself to be placed in an invalid state.

An invalid state is one where the values of the objects attributes are not consistant with the data type. For example, a date class should always represent a legal date. A date object holding the 32nd day of the 14th month is in an invalid state.

Keeping an object in a valid state is entirely the responsibility of the class methods. Any program using the class should never have to worry over whether an object is in a valid state. There are several things you can do when writing classes to insure that a valid state is maintained for all objects of the class:

• Make all attributes (data variables) private or protected. This is called "data hiding." The program using your class must go through the methods called "set" or "mutator" methods to set the values of the data.
  
  
• Check all input data in "set" methods before setting attributes. In some cases it may be that an attribute can have any value. An example of this might be a class representing a point on a plane. The x,y coordinates of the point could be any values, positive or negative. Watch for subtle value restrictions on data. For instance, a value that, by its own nature must be positive.
  
  
• If invalid data is detected in a "set" or "mutator" method either leave the attribute in its previous state or set it to some valid state. For example: If a "setMonth" method in a date class receives the month 14 do not default the month to zero. Use a valid month for a default value. Note that you never display an error message from within a class method. Remember, you are not writing code for program users. You are writing data types for other programmers to use. Instead of error messages use return values or exceptions to report errors to the program.
  
  
• Constructors must always set up the object in a valid state. For example: A default constructor for a date class should set a valid month, day and year, not all zeros.
  
  
• Methods that manipulate the values of the attributes of a class must check to make sure that they do not leave the object in an invalid state. For example: If we have a "nextday" method that increments the date by one day, it will need to make sure the day of the month is not 32 (or 31 for September, or 29 or 30 depending on leap year for February, etc.). If it is, the method should "normalize" the date. That is, increment the month and reset the day to one. Of course, if it increments the month it should check to make sure the month is not 13 also!