Scoping Methods

From WikiContent

Revision as of 21:14, 29 January 2009 by Michael Hunger (Talk | contribs)
Jump to: navigation, search

Method scopes

It has long been known that we should scope our variables as narrow as possible. And with the advent of modern compilers even more so as they move them into the best location in the binary anyway. Why is that so?

  • Readability is greatly improved if the scope of a named variable is so small you can see its declaration some lines above its usage.
  • Variables leaving scope are quickly collected by the Garbage Collector.
  • Invalid reuse of locally scoped variables is impossible.
  • Assign once strategy (final local variables) is much easier.
  • Local variables are no shared state and therefore thread safe
  • etc.

But what about methods?

Its commonly discussed that you should manage the visibility of your methods by making only that public what should be exposed by the public interface. Keep overrideable methods for subclasses abstract or empty. Sometimes there are some layouting rules like - first the public then the private methods. Or the one from Uncle Bob - put the private method near their first usage (just below the public method which uses it).

Why don't we scope methods as well?

It is easy and helps a lot with the Single Responsibility Principle (SRP) - have one reason to change a class - and One Level Of Abstraction - within a (method) scope only have invocations on the same level of abstraction, no nested structures.

Just create objects for the public methods and move the private ones along with them. If you had (long) parameter lists for the private methods you can promote these parameters to instance variables of the method object.

Then have your original class declare its dependencies on these fragments and orchestrate their invocation. This keeps your orchestrating class in a controlling role and free of lots of small (as we like it) private methods. The lifetime of your method objects depends on their intended use. Mostly I create them within the scope just before being called and let them instantly die. You may also choose to give them higher status and have them injected by an DI framework or created by a factory.

These Method Objects give the newly created method scope a name and a location. They stay very narrowly focused (SRP). Often they become home for more functionality working on the state the took with them (e.g. promoted parameters or instance variables used by just these methods.)

If you have private methods that are quite often reused within different other methods it's perhaps time to accept their importance and promote them to public methods in a Method Object (or utility class -> traditional function for non-functional languages)

Partially this is comparable with AOP but this approach makes the delegated functionality visible as these are no cross cutting (technical) concerns but business functionality. A much better discussion about this principle is done by Jim Coplien (DCI - data context interaction) and Rickard Öbergs (COP - composite oriented programming, available in the qi4j framework) which focus on composing objects out of many fragments depending on the current role of the object within the current execution context.

Further Reading

  1. Rickard Öbergs qi4j [1]
  2. Jim Copliens DCI [2]
  3. Method Object Pattern (Design Patterns, GoF)
  4. Refactoring (Martin Fowler)
  5. Clean Code (Bob Martin)

--Michael Hunger 13:14, 29 January 2009 (PST)

Personal tools