|
|
|
|
|
by sqeaky
694 days ago
|
|
I hadn't thought about it explicitly like this before, and I think I agree. My more nebulous thought process was something like: 1. Try to solve the problem purely functionally. 2. If that failed because of data issue, model the data with objects and simple operations in an OOP style or well thought collection of arrays (game devs answer to OOP causing memory and caching problems, but the end result programming is similar to OOP thought process) 3. If that is can't happen because some external restriction is impose use the minimal amount of procedural logic to solve the problem and round off as many sharp corners as is practical until it is unlikely any on the team gets cut. Logically that is very close to inversion of thought process and ordering of operations to what you suggested. But I think we would recognize each others attempts to pick a design paradigm in code. Now I want to think about this more. Is there some underlying principle here? Is this some kind of underlying principle? Where do domain specific languages fit in? Do other paradigms fit in? What are the bounds of this pattern, where does this process fail? |
|