I often encounter the following program while programming. There is a "partial" solution to a problem, which provides all the functionality that is necessary, but the documentation explaining said functionality and the behaviour of the solution is very dense and esoteric. Then, there is a "full" solution, which provides more functionality than is necessary, but the documentation doesn't have to explain why it doesn't work in certain cases, and thus is very simple and easy to understand.
Just as an off-the-cuff example, consider a method
Foo(A a) that takes a single argument of type
A. Let's just say there's an easy implementation of
Foo, but it requires
A to have certain properties, and the explanation for why those properties are necessary is long and complex.
The "partial" solution is at the beginning of
Foo I simply check if
A has the required properties, and then reject it if it doesn't. This, however, makes the documentation very complex as now I have to explain why it doesn't work for certain objects.
On the other hand I have the "full" solution, which is simply to make
Foo work for all
As, regardless of their properties. Suppose I theoretically could implement a
Foo that accomplishes this, but it requires a lot more code than the "partial" implementation.
Which is better?
Maybe that's a bad example, but I run into generalizations of this problem very frequently in a lot of my larger projects. Which solution should I choose when faced with this dilemma (if either of the "partial" or "full")? Are there any general tips for preventing this situation from arising?