There seem to always be two sides of a story when writing code, and to some extent, the process of finding "the right" code, or the most elegant solution ends up proceeding as follows:
I just allow the code to essentially battle itself, with me as the programmer acting as the mediator in the negotiation.
So, the negotiation typically starts with the calling system asking attempting to call a function on the responding system that does not originally exist. Consider this an "opening offer" where the calling system provides as much (or as little) detail as IT thinks is necessary for the responding system to answer the question or request.
This will generate a matching method in the responding system. Now, we try to respond to the calling system's request, specifically from the perspective of the responding system. Hopefully, the information provided is sufficient and an answer can simply be provided.
In many cases though - the responding system will need more information - so it should "request" this additional information by adding a parameter to it's function signature. This will generate an error in the calling system's code.
By switching back to the calling system's perspective, providing the additional parameter is usually possible. But if it is not directly possible, either the calling system needs to go get the relevant information, or provide the next best option available.
By switching back to the responding system now, maybe the alternate information provided actually works, or may cause the responding system to change it's usage again.
This process continues until a mutually agreeable set of code is found.
An important note about this process is that at the point that the original "opening offer" was presented, a final solution to the problem was NOT completely understood. This process is the method to FIND the solution. It is NOT presumed that the solution is known at the beginning of this process.
No comments:
Post a Comment