5 ms·

Objects are much easier to debug then their predecessors: methods making use of global state variables. With objects, state is encapsulated and not modified by

by Hermel 12y ago

Objects are much easier to debug then their predecessors: methods making use of global state variables. With objects, state is encapsulated and not modified by the outside, making them much more predictable and thus also easier to test.

rayiner 12y ago
I'd rather deal with a procedural program modifying global variables than an object-oriented one. Strewing an algorithm across a bunch of methods makes control flow incomprehensible.
- ionrock 12y ago
  I've felt the same way at times until I realized the issue is just my perspective. OO provides an organizational tool for organizing functions and variables. The same thing can often be accomplished by changing the way code is organized. For example, in Python, if I have two functions that implement a "download" operation, but they accept different types of locations, I could use different modules to implement them: from mypkg.endpoints import ftp from mypkg.endpoints import http ftp.download(ftp.info(some_ftp_info)) http.download(http.info(some_http_info)) You can see that we pass the result of `ftp.info` to each, which is essentially defining its type somewhat reliably. In OO, you can simplify things a great deal by encapsulating data in an object, as well as organizing functionality accordingly. I think (in Python at least) the same benefit can be accomplished by using modules for namespaces and grouping, like you would a class. By using modules in this way, it is then possible to utilize types like you might in haskell as well as enforce immutability, assuming the "types" you create are immutable (like namedtuples). All that said, I've yet to have the courage to enforce this sort of paradigm in a project. I worry that it would be prohibitively expensive to my fellow developers who may not appreciate the benefits. With that said, I would be interested if the paradigm would be reasonable over time.
- vinceguidry 12y ago
  Me too, but I'm going to immediately take that procedural program and embed it into its own class, refactoring it until the complexity is nicely tucked away. The other case is dealt with by moving all the methods back into a main (giant) method. Then I'll refactor that. It's more fuss, but not that much more.
l_dopa 12y ago
Objects are far from the only way to limit access to state. Modules, lexical scope and closures, even C's static storage class all predate the current crop of OO languages.

by Hermel 12y ago

rayiner 12y ago

I'd rather deal with a procedural program modifying global variables than an object-oriented one. Strewing an algorithm across a bunch of methods makes control flow incomprehensible.

ionrock 12y ago
I've felt the same way at times until I realized the issue is just my perspective. OO provides an organizational tool for organizing functions and variables. The same thing can often be accomplished by changing the way code is organized. For example, in Python, if I have two functions that implement a "download" operation, but they accept different types of locations, I could use different modules to implement them: from mypkg.endpoints import ftp from mypkg.endpoints import http ftp.download(ftp.info(some_ftp_info)) http.download(http.info(some_http_info)) You can see that we pass the result of `ftp.info` to each, which is essentially defining its type somewhat reliably. In OO, you can simplify things a great deal by encapsulating data in an object, as well as organizing functionality accordingly. I think (in Python at least) the same benefit can be accomplished by using modules for namespaces and grouping, like you would a class. By using modules in this way, it is then possible to utilize types like you might in haskell as well as enforce immutability, assuming the "types" you create are immutable (like namedtuples). All that said, I've yet to have the courage to enforce this sort of paradigm in a project. I worry that it would be prohibitively expensive to my fellow developers who may not appreciate the benefits. With that said, I would be interested if the paradigm would be reasonable over time.
vinceguidry 12y ago
Me too, but I'm going to immediately take that procedural program and embed it into its own class, refactoring it until the complexity is nicely tucked away. The other case is dealt with by moving all the methods back into a main (giant) method. Then I'll refactor that. It's more fuss, but not that much more.

l_dopa 12y ago

Objects are far from the only way to limit access to state. Modules, lexical scope and closures, even C's static storage class all predate the current crop of OO languages.