One of the members of my class is actually a function that evaluates some properties and returns a value.I suppose i should implement it as a method. The question is that this member must be called several times even if the parameters did not change.Is the followjng an admissible solution?-implement a private method to evaluate the function.-implement a private booelan flag to keep track of changes in the parameters.-implement my function as a read-only property.-in the get method, --look first for value of the flag--if false, call evaluate function--update property--return property--set flag=false again.could anyone tell me if this is a bad code design or not?thanks.

I think it's a good question to explore the trade off between elegance and efficiency.Possibly a better process is to have the Set function carry out the evaluation as well. The Get function would simply return a precalculated value.A good metric for the quality of code is to work out how easy it is to change.The bad variation on this would be to have a large number of bools each of which monitors some subset of variables.

I'd like to know more details of the original problem as it's difficult to suggest an optimal solution.Having an internal boolean state as to whether the object is calculated or not seems OK to me. Every set would automatically reset this flag to false. The trouble with having every set force an evaluation is that you might want to set several parameters and run the calculation once.I would also think about why the application is repeatedly calling a method even though its inputs havent changed. Some efficiency saving possible there?

I am writing this class to be used in a variety of different programs. Members of the class are options and other derivatives.I am using these members in collections to generate portfolios or baskets, and evauate scenarios, back testing, ...I want it ot be quite general, but the problem is whether the optimization should be done at the level of the class, or at the level of the specific program that uses the class (for instance, implement outputs as properties and a calculate method, and then let the programmer of the specific application decide when to update the members.I think that if done at the class level, the programmer will find the task easier, but the class becomes more complicated to change and as Dominic said, that would be a bad code. On the other hand, If the programer has to take care of this issues the application will become more confusing and difficult to change as well.The question could be reprased in: Who's responsable of optimization? the class developper or the application developper?

Obviously there are lots of tradeoffs to consider each time in designing any interface. Usually these considerations are directly opposed to efficiency (e.g. custom, purpose-written code with hard-coded values is almost always faster, easier to maintain and smaller than generic, general-purpose code). But the best way I have found to make the evaluation decision is through capricious rules. Eg. If a function needs more than seven parameters, it is doing too much, no functions of more than 37 lines, etc. -- and anything that fits within these rules (yes, they are arbitrary) in my head is "okay". One other rule is to do things at as low a level as possible while writing initially, because code gets re-used a lot less than one thinks it will, but do it at as high a level as possible when doing maintenance (because documentation is never as good as you thing it is, and the law of unintended consequnces will get you every time).So, when it comes to your function, I would definitely make it the responsibility of the class to be efficient. That's the whole purpose of setter/getter functions -- to check inputs, to insert efficiency short cuts, etc.Finally, elegance is good for physics. But not for code. The number of times I have seen folks who write one line functions just because they were always taught to use setter/getter functions without using their brains... oi! don't get me started.