Operations Manager 2007 lets the MP author use classes to model aspects of health information.  As with popular object based languages, Operations Manager classes represent a concept, and can include property values such as name, location, etc.    Unlike object based languages, the logic that populates a class is separated from the class - and is found in the Discovery section of the management pack.    Discoveries run when a condition (their target) exists under control of the current agent, and then discover class instances managed by that agent.    At runtime, Ops Manager discovery then populates the properties on these classes based on logic set by the author.  This enables the property values to appear on the operations console.  Classes are useful mostly as targets for monitors and rules - so once a class instance exists under a specific agent control, this will trigger the subsequent execution of any monitors, rules or other discoveries that use the class as a target condition.
If the MP author is not careful, or they are "too object oriented", they may add both static and volatile properties.  A static property is one that is set once by the initial run of the discovery operation.  Static properties are well behaved.  It is when authors unwittingly choose to set up volatile property values on classes and then set them each time the discovery runs that severe performance problems can result.   Common examples of volatile properties include last-time-discovery-ran and system values such as a performance counter value at the time the discovery ran.  Volatile properties are undesirable in large operations manager installations because the property maintenance operation is one of the most expensive (performance impacting) things you can do with operations manager.
When designing classes, avoid adding properties that change over time.  Let's examine what happens when a discovery sets a property on a class in operations manager.
The first time the discovery runs, the class instances are discovered so to the author testing their management pack, everything is good.  But each time the discovery runs, every class instance gets updated with new property values.  This causes the new discovery data to be pushed up to the Root management server (RMS) - a non-trivial operation.  When the class model of a system changes, other agents need to know about the change, so after updating the RMS, the agents are informed of the new state - including the agent that provided the discovery data.  This confirms that the system state is uniform - but this propagation upwards and then back downwards to the agents causes a lot of churn in the system - and this makes the RMS agents work overtime.  This may not seem like a lot of work, but the transfer of many instance level updates each time discovery runs adds load to the RMS server.  When discovery runs frequently, and the instance counts are high, this can destabilize ops manager overall because it is constantly working on updating the instances that are being monitored.
The only properties you should expose on a managed entity that is populated by discovery should be static data that is instance specific and that changes very infrequently (less than once a week).