1
\$\begingroup\$

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?

\$\endgroup\$
2
\$\begingroup\$

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.

| improve this answer | |
\$\endgroup\$
  • \$\begingroup\$ 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! \$\endgroup\$ – kaoD Apr 17 '12 at 12:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.