> At the architectural level, who-the-ef cares about about state vs instances methods in Java Who-the-ef should care is anyone who has to implement or maintain

> At the architectural level, who-the-ef cares about about state vs instances methods in Java Who-the-ef should care is anyone who has to implement or maintain the code. After all, the debate at hand is what is worth unit testing, which very much concerns the programming language and the actual implementation. Don't know about you, but I both architect the system and write the code. > If you do not have (1) or (3)--I hate to break it to you--but all your program does is burn CPU. I haven't written production code that doesn't have (1) or (3) in my 25 years of programming, so not sure who you are talking to here. > If you're at the level where you're worried about "static or instance methods", you're not dealing with how data changes in large systems at all. Those words are at the level of state within a language. You have to tend to this stuff at both the generic data processing and language level. Using a given language's constructs for differentiating between stateful and stateless code is an important part of making the code document itself. Coding style matters.