David,

Thanks for the reply. I like the idea of keeping the methods small. In some cases, another method which calls some of these small methods in an appropriate order might also be helpful. That could keep the object flexible and easy to use. A naming convention for the methods also puts up a light bulb. Thanks again for the input.

>There are some pretty serious OOP gurus in this forum, and I'm not one of them. But my experience would say use access and assign methods very sparingly. They are incredibly powerful tools, but at the same time, they can be a nightmare to debug, especially if you put the code in abstract classes.
>
>I've also played around with generic "calculate()" methods, which can be OK, but they can lead to very confusing code loaded with conditional logic which are also difficult to debug. I personally love using lots of small methods with a well thought out naming convention (i.e. one that identifies the property being calculated - like this.lineitemsum).
>
>I'm sure there are some "best practices," but I frequently find that purist approaches are considerably more work than they're worth. I can name some very specific examples, but I won't for fear of being tarred and feathered.
>
>
>
>>Is there a "best practice" for where to put the code for calculated values stored in the properties of an object? Access methods are nice, but the calculations get executed a lot more often than necessary. In the interests of polymorphism, I thought about using a Calculate() method which is passed a code string (ie. oMyObject.Calculate("TAX")) to determine which calculation to perform. Although this provides a standard interface, I don't really think it meets the goals of polymorphism, since you have to know the code of each calculation you want to perform. Perhaps a custom method for each calculation is the best way to go (ie. oMyObject.CalcTax()). It does tell you exactly what the method does.
>>
>>What do you think? Your opinion is appreciated.