This leads one to the plausible Module, Service, or Object, of an interpreter (containing the function ''fromExpr''). Function Decomposition arguably yields insights about re-usability, such as if during the course of analysis, two functions produce the same type, it is likely that a common function/[[cross-cutting concern]] resides in both. To contrast, in [[Object-oriented programming|OOP]], it is a common practice to conjecture Modules prior to considering such a decomposition. This arguably results in costly [[refactoring]] later. FD mitigates that risk to some extent. Further, arguably, what separates FD from other design methods- is that it provides a concise high-level medium of architectural discourse that is end-to-end, revealing flaws in upstream [[requirements]] and beneficially exposing more design decisions in advance. And lastly, FD is known to prioritize development. Arguably, if the FD is correct, the most re-usable and cost-determined parts of the program are identified far earlier in the development cycle.
