4 ms·

You realize that there's a war between people who write static code analysis software and "software architects", the former trying to detect global state buried

You realize that there's a war between people who write static code analysis software and "software architects", the former trying to detect global state buried in object hierarchies and the latter disguising global state as something else in the interest of "decoupling" things that need coupling. Every class property is effectively global state (has the printer been initialized? what objects of this type have been created?) If you don't think class properties are useful... Globals are a tool. Used badly they're terrible, but so are design patterns. For a long time many very useful pieces of software ran very well with lots of global state, but the egregious cases of misuse spoiled it for everyone. The problem with the "never use globals" approach is that if you need them, disguising them as something other than what they are makes things FAR, FAR more difficult to reason about.

jschwartzi 11y ago
I agree. For example, the OO project that I'm working with at my job has a bunch of global state, but it's hidden in references to structs and pops up in a million different places throughout the system. It's still spaghetti code but it's spaghetti code with namespaces. The point of OO isn't to separate or eliminate global state itself. At some level everything is global(agreeing with you). The purpose of OO is to establish a strict separation of concerns. The idea is to say "We need a component of our system to deal with the Blargle operation," and then determining what elements of the system the Blargle functionality actually needs in order to be performed, then making sure that Blargle is aware of only those parts of the system. Additionally it means that system components that existed before Blargle was implemented are still blissfully unaware that Blargle is a thing now. All of the features of OO languages, like encapsulation, inheritance, design patterns, and messaging are there to allow you to write software where unrelated components can be implemented and reasoned about entirely in isolation. You can do this in any computer language, and systems like the Linux kernel are good examples of separation of concerns that don't happen to use an OO language. You can also do this with global variables, but it takes more discipline.

jschwartzi 11y ago

I agree. For example, the OO project that I'm working with at my job has a bunch of global state, but it's hidden in references to structs and pops up in a million different places throughout the system. It's still spaghetti code but it's spaghetti code with namespaces. The point of OO isn't to separate or eliminate global state itself. At some level everything is global(agreeing with you). The purpose of OO is to establish a strict separation of concerns. The idea is to say "We need a component of our system to deal with the Blargle operation," and then determining what elements of the system the Blargle functionality actually needs in order to be performed, then making sure that Blargle is aware of only those parts of the system. Additionally it means that system components that existed before Blargle was implemented are still blissfully unaware that Blargle is a thing now. All of the features of OO languages, like encapsulation, inheritance, design patterns, and messaging are there to allow you to write software where unrelated components can be implemented and reasoned about entirely in isolation. You can do this in any computer language, and systems like the Linux kernel are good examples of separation of concerns that don't happen to use an OO language. You can also do this with global variables, but it takes more discipline.