I have come across the following problem many times in various guises in my programming career. As a simple example, consider the following:
Let’s say there is a method (B) that could differ depending on customer requirements. This could be for any number of reasons. Common sense tells you that as things are now, you should write them as a common method and add branching code in the future to handle any future edge cases.
Customer 1: A-->B-->C
Customer 2: A-->B-->C
However, your experience tells you that this particular bit of code is likely to change so it would be easier to have separate methods (B1 & B2) and change the logic for one customer rather than continually add branching code making method (B) non-generic.
Customer 1: A-->B1-->C
Customer 2: A-->B2-->C
Are there any rules of thumb that can be applied in such cases or does every case have to be taken on its merits?
As an aside, I’ve come across plenty of people who staunchly advocate one approach over the other and I can see the merits of both. But surely there is some middle ground that can be reached based on reasoned arguments?
1
In general, business logic tends to be similar by coincidence. On the other hand, program logic (meaning the structure and flow of your application) tends to be similar by convention.
If you think about different types of business entities, they’re all going to have a fileTaxReturn method (’tis the season), but there’s very little reason for them to use the same method because the way an LLC files its taxes is completely different from the way a C Corp files its taxes. This is business logic.
On the other hand, if you have some sort of behavior (maybe it’s an event emitter that gets hooked for logging) that is part of the program logic, it’s very likely that that’s a convention of the application and can be reused.
There are two maintenance oriented aspects of this question.
-
Implicit polymorphism – for business logic, often times it makes a lot of sense to prematurely abstract, because otherwise as you add more base cases all of your methods are going to turn into ugly switch statements. By making business cases clear scenarios early on, it makes intent visible and prevents switch statement hell.
-
Premature abstraction – On the other hand, if you are saying to yourself “Maybe we’ll want to log to the database, but sometimes to a flat file, and other times to an RSS feed, and maybe Twitter, or Facebook, or a serial port…”, you’re doing premature abstraction – creating unnecessary complexity in a system, and outright confusion for the maintenance programmer. Well-encapsulated code is easy to refactor, and will not suffer from a lack of abstraction.
2
Yes, each case needs to be taken on its own merit, as there is not general rule that says “all branches must be in their own methods”.
The branching needs to be done in either case. It’s just a matter of deciding if you want to put it in B per your first example, or in A as in your second. Deciding how to do boils down to two things:
- Readability: Is the code more readable if you put branching in A vs. B?
- Maintainability: Is the code easier to maintain if you put branching in A vs. B?
More often than not, these two goes hand in hand. Code that is easy to understand tend to be easier to change. Start with the simplest possible case (all code in one place) and then extract stuff out until you reach a point where the code is short and sweet, but still compact enough to make out the details.
When (if) you need to add B3 and B4, you have a candidate for introducing something a bit more flexible, like creating a common superclass and what not. But not before that.
3
Are there any rules of thumb that can be applied in such cases or does every case have to be taken on its merits?
There are at least one or two dozen different kind of solutions for that kind of problem, and to choose the “best” one (whatever that means) depends on the details of the specific situation. That does not mean there are “no rules of thumb” – there are a lot, but I guess more than it would make sense trying to list them here in one posting.
Said that, here are some things which could influence your decision:
- what “triggers” the branching? Do you need a compile time or a run-time switch?
- how big are the differences between B1 and B2? Does one have to duplicate code in B1 and B2? Are you going to duplicate code by doing “A -> B1 -> C” and “A -> B2 -> C” (which would be a bad thing)?
- is B getting “too big” or “too complex” (and why doesn’t B just branch between B1 and B2)?
- do you use OOP and are A, B and C parts of a class where applying “template method pattern” may be the right thing to do?
- do you have a programming language at hand where instead of calling B1 or B2, you could inject a callback to either B1 or B2 into the code which has to call either B1 or B2?
- must the decision “B1 vs. B2” be made at just one place in code, or are there many places where the result of that decision is evaluated (and the switch between B1 and B2 has to be done again)?
B is behavior. So have an interface for it and introduce new implementations as needed. Equip different object instances with different implementations when instantiating them. This way you stick to the Open Closed Principle, because you just need to implement an interface and configure its usage. The owner of such an interface instance won’t be affected by introductions of new interface implementations.
This way you are also separating the branching, which is a configuration issue, and the actual execution. The code will get a lot more readable, because there won’t be any branches during the execution of the business logic.
1
KISS & YAGNI
…simple & intuitive systems are usually way easier to evolve/adapt than complex systems that try to cover all possible “potential evolutions” upfront.
If the differences are minor, go for a common method/object/whatever.
If the differences are big, implement them in distinct method/object/whatever.
My 2 cents