Method arguments: more specific or more general?

Say hi to the method:

public void hello(Data data); 

This method uses some data and performs… whatever. Now, written like this, the method is very specific – i.e. the argument is very specific. But now, in real life, this Data (for example) may come from e.g. class called DataProvider:

public class DataProvider() {     public Data getMeData(int from, int to); } 

Now most of the times when we call hello we need to call dataProvider.getMeData(). Since this is repetitive, you might do:

public void hello(int from, int to); 

Which is essentially:

public void hello(DataProvider dp); 

This looks convenient as, maybe, in future, I will need different data besides the Data class, and no signature will be changed. In other words, method itself will know which data to take.

This second case is an example of a method with more general arguments.

Which one would make more sense:

  • The first one, more strict, more focused.
  • The second one, generic, but less focused.

This is not about passing custom objects. In both cases, custom objects are passed. The difference is that the scope of passing the object is different. The first one contains just raw data. The second one is more general, contains more what that method needs.


So you are asking when to introduce an additional layer of abstraction to decouple pieces of code. It's impossible to give a general answer. Most of developers just follow their experience and the Open/Closed-Principle.

… maybe, in future, I will need different data …

The best answer I can give based on the information provided: You Aren't Gonna Need It!

As the other answer already pointed out, you can make a case-by-case decision based on standard principles like OCP or YAGNI.

Next, it generally makes sense to distinguish two different abstraction levels:

  1. On the lower level, the hello method is part of a smaller component and rather far away from service interfaces.

In that case, you typically want your argument as generic as possible for reuse. Though "generic" here refers to the data, not the data-creation or -retrieval.

For example, you don't want the hello signature to require an ArrayList when a more generic List or Collection interface would be sufficient.

  1. On the higher level, the hello method can be considered a sort of facade to a lot of deeper functionality, realized by multiple classes or what-not.

In that case, your functionality changes can quickly require a change in the signature of the data. So in order to not have to change that vital signature all the time, it makes more sense in such a scenario to get more data than you may need at the moment.

In summary, the fun conclusion is that the scope of the method determines the scope of the data it requires. Duh, I know.

I think the most relevant guideline here is the Single Responsibility Principle. A method that is responsible for processing a Data object should have no business in creating or retrieving it. Instead, it should be passed in as a dependency; just what your first version does.

I disagree that the second version is, by any standard, more generic. It only works for Data objects retrieved from a DataProvider by specifying a pair of ints. The first version will work with any Data, no matter where it came from.

If you find yourself typing

hello(this.dataProvider.getMeData(14, 92));

a lot, there is nothing wrong with adding a private convenience method

private void helloData(final int from, final int to) {
    hello(this.dataProvider.getMeData(from, to));

to that class and use it internally as this.helloData(14, 92). Going the other way round – making the function that expectes a DataProvider and a pair of ints to accept a Data object that came from elsewhere – is not nearly as easily possible, however.

Category: design Time: 2016-07-29 Views: 1
Tags: Design

Related post

iOS development

Android development

Python development

JAVA development

Development language

PHP development

Ruby development


Front-end development


development tools

Open Platform

Javascript development

.NET development

cloud computing


Copyright (C), All Rights Reserved.

processed in 0.119 (s). 12 q(s)