Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

For example I have this code.

class Command {

    var $responseFactory;
    var $service;

     * Returns the class name of the responseFactory if it is set 
     * or the default class name for the responseFactory of the service if it is set. 
    public function getResponseFactory(){
        if ($this->responseFactory != null) {
            return $this->responseFactory;

        if ($service != null) {
            return $service->getResponseFactory();

        return null;

Although it is fine by itself it could lead to someone being surprised in the future if they cloned a Command object, changed it's service property which then 'magically' changes the results of getResponseFactory.

The counter argument for why it should be named just getResponseFactory is 'duh, of course the internal behaviour of the class should be a black box`.

Should non-trivial get functions be called differently to indicate that they are not a trivial getter?

Edit Just to clarify the return type is the same if it is the Command responseFactory that is returned or the Service responsefactory.


migration rejected from Aug 16 at 12:59

This question came from our site for peer programmer code reviews. Votes, comments, and answers are locked due to the question being closed here, but it may be eligible for editing and reopening on the site where it originated.

closed as primarily opinion-based by durron597, Snowman, GlenH7, MichaelT, amon Aug 16 at 12:59

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

What would you call it? maybe you just need documentation. At the service function and Command class level. Names and documentation both have their place. – tgkprog Jul 12 '13 at 16:25
"What would you call it?" Maybe 'getEffectiveResponseFactory'? Which kind of sucks. – Danack Jul 12 '13 at 16:34

3 Answers 3

up vote 7 down vote accepted

The "duh" answer should probably be the winner here for three reasons:

First: The name of the method should describe what it does. Invoking getFoo() should return whatever a foo is. In your case, consider whether getResponseFactory() is sufficient or getResponseFactoryClassName() might better describe your method's purpose. This may depend on the language, so you have to make that evaluation for yourself.

Second: Where's the dividing line for trivial? The amount of gymnastics code has to do to find the result isn't really any of the caller's business. Building some sort of indication into the name of the method borders on being Hungarian notation, and finding a trivial way to do it later would invalidate the name.

Third: The documentation for the method should completely describe its behavior. If your class has methods to set the responseFactory and service members, make sure the effects of calls to those methods is described in the documentation for getResponseFactory(), e.g.,:

Returns the class name of the class used in the last call to setResponseFactory(). If the response factory hasn't been set but a service has been with setService(), the name of the response factory for that service will be returned instead. If neither has been set, the return value will be null.


Is the implementation non-trivial or the behavior non-trivial? Name with respect to the behavior. If the behavior is nontrivial in a way that as a result of calling a get the client code may need to do something special, don't just name it get. If the implementation is non-trivial, then, the API name shouldn't care.


  1. Non-trivial performance? Usually this is left to documentation, not names.
  2. Might fail? Languages like Java document this in a throw-spec. Otherwise I would probably leave to documentation, not name.
  3. Side-effects that affect behavior, particularly non-idempotent ones? Then change name.

You should either have two methods ( my preffered option ):

1. getResponseFactoryName()
2. getServiceResponseFactoryName()

or change the method name to something like:

1. getAvailableResponseFactoryName()
Sorry, I'll clarify it. Both the Command::getResponseFactory and service->getResponseFactory return the same type, a string - which is admittedly another smell. – Danack Jul 12 '13 at 18:09
@Danack Ok I'll modify my answer accordingly. – user61852 Jul 12 '13 at 18:12
@Danack Edited. – user61852 Jul 12 '13 at 18:17

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