# Which name should I choose for private abstract functionality with a public proxy?

I have an abstract class implementing some concrete functionality for its child classes:

abstract class Function {
def eval: Double = some_concrete_functionality_which_calls_fEval
def simplify: Funcion = more_concrete_calling_fSimplify

protected def fEval: Double
protected def fSimplify: Funcion
}


The child classes should implement fEval and fSimplify themselves, while eval and simplify act like a public proxy between them to provide common functionality before calling the actual implementation.

f stands for function but, although I feel fName is not very expressive, I can't think of any good alternatives (besides concreteEval which seems very bloated.)

Any suggestions? Should I stick to concreteEval? Maybe keep it like it is?

I think that it's more a matter of taste. If I were to come along behind you, I wouldn't have any particular problem with fEval and fSimplify.
I'm not sure that I would like concreteEval.
In my own code I tend to use doEval, but I could also imagine using evalImpl or myEval, depending on what it is exactly that is being done by these functions.
• I thought about myEval too but it looks very meaningless. Why it it 'yours'? Like fEval it doesn't explain why it is not just eval. doEval and evalImpl look good, they show that it's where you actuall do the eval and that it's an impl, respectively. I'll think of them. Thanks! – kaoD Apr 17 '12 at 12:41