Architecture, lots of methods vs long parameters lists

Question

We are trying to do things as clearly and cleanly as possible in a 3 tier architecture situation.

But the complexity of our system is leaving us confused about the best way to proceed.

If we use lots of chains of functions going through the service layer, with smaller parameter lists, this seems clear in terms of what is being done, yet it feels like a lot of functionality is being repeated across these methods.

However, if we use less methods, and have large lists of parameters to change functionality within the methods, this seems to get out of hand.

Our choice at the moment is have more functions as this feels easiest to manage than monolithic functions with lots of logic flows inside them. This obviously means smaller chunks of more manageable code.

It's just we hear about DRY a lot, so this feels like there is some repetition going on inside the methods. But it seems more flexible.

Answer 1

I think it will be better to provide 2 examples of what do you mean. It sounds like one of the following:

1. You have bad design.
2. You have interaction/behaviour spread out through many objects.
3. You are using DI\design pattern incorrectly.
4. Your code is actually procedural and not OO.

Because you didn't provide any example I will walk through only shortly for all of these options.

1. You have bad design.

3. You are using DI\design pattern incorrectly.

Maybe you should split out your code differently, maybe you should use DI or revisit of how you are using it. Maybe you should apply some design patterns to make the problem manageable.

2. You have interaction/behaviour spread out through many objects. Consider to use of DCI http://alexsmail.blogspot.com/2012/09/dci.html to tackle this problem.

4. Your code is actually procedural and not OO. I saw code wriitent in Java by the programmer that are regular to write procedural code. It has many parameters that tweak method execution. Solution will be to redesign your code and (re)train your programmers.