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.
Method arguments: more specific or more general?
design
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 typinghello(this.dataProvider.getMeData(14, 92));a lot, there is nothing wrong with adding a private convenience methodprivate 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.