You are clearly looking at the problem wrong. As a programmer/Analyst, you should not be looking for the most complicated solution to the problem, you should be looking for the simplest solution to the problem.

But before you do that, you should ask yourself if the original requirements (adding 2 and 2) can't be generalized into solving a more generic problem. If today a customer is asking you to add 2 and 2, then it seems very probabilistic that at some point in the future, some customer might want you to add 1 and 1, or even 3 and 3. This is where programming becomes an art, not a science. At some point there is a flash of inspiration that tells you that the right solution is some sort of add function that can support not just 2 and 2, but also 3 and 3. And, why not 1 and 2 or 6 and 4? WOW. FLASH OF INSIghT!!! Now we are talking about a generic solution that handles all business cases holistically, with perfect synergy between current customer demands and future customer needs. This is a WIN WIN.

But wait...it gets better. This solution only handles the addition business space. There are also good business cases for subtraction and even multiplication. And mathematics is an evolving field, so limiting the solution to only mathematical operations currently in use would limit the potential extensiblilty of the platform. What is called for here is a holistic, future proof solution that clearly delineates our role as a market leader in the field.

Clearly, we need a generic solution that accepts 2 operands and an operator. We should expose this interface using existing standard interfaces such as SOAP and REST. At a minimum, the result should be returned as either an XML document, or as JSON. As yet undefined return formats should also be supportable with a minimum amount of additional work to enhance the extensibility of the platform using industry standard best practices.

So we need to expose a web service using both SOAP and REST front ends. These front ends will delegate the work to a middle tier process to compute the actual values. An output formatter object will need to be instantiated using the factory pattern to produce the XML or JSON output. Support for additional output formatters should require a minimum of effort, in order to synergisticly meet future customer needs within their go-to-market timeframes.

Since we need to support all current and future binary mathematical operations, we will again need to use the factory pattern to instantiate an object that performs the actual binary operation. Supporting new operations might be achieved by using dependency injection, configuration file settings, or database metadata. That decision is left as an implementation detail.

In order to be robust, both from a security perspective, and in terms of extensabilty, it is strongly recommended that the actual computation code should be implemented as a stored procedure within our proprietary database engine. This might be accomplished by creating a table containing all possible results of the binary operation, using the 2 operands as a composite key (because efficiency of the solution will be an important metric that will differentiate our solution from competitive solutions). Alternatively, generating dynamic SQL to compute the result may also be an acceptable alternative. This is a decision that should be made by the DBA team. If we use the dynamic SQL solution, we will need to get a definitive statement from the SQL vendor that they are committed to fully supporting all new binary mathematical operations that might be invented within a time frame that will allow us to meet our SLA's. Given our strategic importance to DB vendor, this commitment should not be difficult to achieve, but we will need this commitment approved in writing, and it will need to be passed through legal before this solution moves from proposal to go forward status. Please schedule a meeting with the developers, DBAs and legal before proceeding with this option. Also include QA in this, as they are an additional steak holder.

That really wasn't that hard. I don't know why you insist on turning simple problems into complicated ones. Or do you work for the same company I do???

I don't have 2+2, but I have 1+1 ! If you want details, email me!