Label Signing Methods - Overloading over a Long Name

Question

It's just interesting what you think of these two different approaches: overload methods versus long / long method names.

Update: I am looking for a common template / best practice. The following is an example.

Given the structure of the organization with parent / child relationships

> OrgUnit > - OrgUnit > -- OrgUnit > -- OrgUnit 

two methods that use the same code in large parts to get children for an xml element.

 // 1) only 1 level down children getSubOrgUnits() // 2) all levels down getSubOrgUnits(boolean includeChildren) // 3) alternative naming of 1) getDirectSubOrgUnits() // 4) alternative naming of 2) getAllSubOrgUnits() 

So, 1 and 2 use the parameters And 3 and 4 use the imperceptible naming.

What would you do and why? Also think that 1) and 2) can get additional parameters that lead to materials like getChilds (true, false, null), and 3) and 4) can get names like getDirectSubUnitsExcludeSome ()

JAVA may be specific, but a broader view of this is appreciated.

Answer 1

In my opinion, using a verbal method name is the best solution.

• This is more clear, your code will require fewer comments.
• It’s easier to maintain, you can change the implementation without affecting existing signatures. You can still add a new signature without regression.

But be careful, in some situations it is preferable to add some parameters

Example 1

 private List<Element> getElementsByType(MyTypeEnum type); public List<Element> getElementsOfType1(); public List<Element> getElementsOfType2(); public List<Element> getElementsOfType3(); /* VS */ public List<Element> getElementsByType(MyTypeEnum type); 

Both implementations are good, it depends on you, on the size of MyTypeEnum , on its ability to increase size. What do you want to expose? Do you want the caller getElements*** be able to get all Element types?

Example 2

 public void log(Level l, String s, Exception e); /* VS */ public void logInfo(String s); public void logWarning(String s); public void logError(String s, Exception e); 

In this case, the second part is better. Because it is more readable, easy to understand at a glance. And since when you log in to INFO and WARNING , you do not need to specify an Exception . Therefore, specialization of the method is good. However, it is important to keep the method public void log(Level l, String s, Exception e); publicly, not private, since in some cases it would be useful to use this general method.

Conclusion

It really depends on the situation, but if you have the opportunity to add certain methods, with detailed names that specialize in target behavior, do it.

Answer 2

It all comes down to aroma.

As a general practice, you can go with "The smallest options, the better." This is convenient from the point of view of code clarity, and actually saves stack memory (not so much, but every bit is important in the end).

Having different names, you can also use autocomplete.

For example, I would go for

 GetAllSubOrgUnitsList() GetFirstSubOrgUnitsList() 

The reason for this, after receiving, the first letter I write will determine what I want.

As you already mentioned, if you cannot have an intuitive name, you can add default options.

In your example

 GetDirectSubUnitsExcludingSome() 

I would replace it with a minimal set of parameters

 GetFilteredSuborgUnits(ISuborgFilter aFilter); 

And then, from the architecture, ask developers to implement their custom filters. A filter can request hierarchical depth, a specific property, etc. (You are an architect, you decide).

So, as a brief summary: KISS!

Even if GetAllSuborgUnits () provides the same with GetFilteredSubOrgUnits (null), then giving a quick and clear alternative to behavior is better than a complex name / set of parameters. After all, layoffs are not always bad things :).

Answer 3

First, I would call this method getChildren() , not getChilds() . :)

If you have multiple levels, why not enter an argument for the depth level?

 // Get children up to depthLevel getChildren(final int depthLevel) // For convenience getChildren() 

In the case of a parameterless method, add meaningful information to let other developers know if you are returning the entire or only the first level.

---

Edit: The OP asked: “So, in general, what approach do you use, why, in what cases? Can you share your thoughts about this a little bit.”

It is very opinion based. As @OldCurmudgeon stated, many libraries that process tree structures use special methods to access the secondary layer. This is normal if you do it regularly. On the other hand, introducing the depthLevel argument gives you more options if you want to access a specific level of your structure. It really depends on your normal use.

Therefore, if it is very likely that you need to get the first child of an object, enter getFirstChild() and getChildren() . If you are more likely to access deeper levels of data more often, or if you need access to selected levels, enter the depth parameter.

Answer 4

A common method of processing this type is:

 // Used when you KNOW there is only one child. getFirstChild(); // Used when there may be many children. getChildren(); 

This is the template used by the XOM getChildElements and getFirstChildElement to view the structure of the XML file.

You can always use:

 thing.getFirtsChild().getChildren(); 

for access to deeper levels.

Answer 5

I do not agree that longer names are a better approach.

It "depends", but let me clarify something:

• Two methods that do the same thing but accept different parameters should, IMHO, have the same name (be overloaded).
• Two methods that do different things (except that determined by the parameters) must have different names. In other words, there should be one name for a common function (albeit with variants) and separate names for different functions.

It is worth noting that overloading is almost the same practice used in the JRE.

I find a slight advantage in long names in practical use. Provided by:

  getSubOrgUnits() 

This is more obvious than:

  getSubOrgUnits(true) 

If I included this in the formal API, I would either give them separate names or make the second one as a constant:

  getSubOrgUnits(INCLUDE_SUB_UNITS) 

Although most IDEs allow you to immediately see how the true parameter is interpreted, hover over the method (which usually displays Javadoc in a popup window).

For me, the benefits of overloading are that it makes a formal association of options. This is also a nicer presentation at Javadocs.