4 ms·

The problem is in OO, or rather how people learn OO. They learn that objects encapsulate behavior, and soon start deriving all kinds of non-objects to hold the

The problem is in OO, or rather how people learn OO. They learn that objects encapsulate behavior, and soon start deriving all kinds of non-objects to hold their actions ("ConnectionManager", "ConnectionHandler", etc.), while the state is kept all over the place. You should look at objects as just another data structure. Once you realize this, it's pretty clear that you should have a "Connection" that keeps the state and a bunch of methods to manipulate it. This comes natural if you program in C or other paradigms, where a "Connection" would be a struct or something like a hash. Another code-smell is a codebase littered with singletons.

unclebucknasty 14y ago
>* They learn that objects encapsulate behavior, and soon start deriving all kinds of non-objects to hold their actions* If I understand you correctly, it seems you would have reached the opposite conclusion: that is, if I learn that objects encapsulate behaviors/actions then I would create classes like "Connection" with all the attendant methods and would have no need for external classes like ConnectionManager. But, if I treat a Connection like a struct, then I would need these external classes like ConnectionManager to perform the actions. So, it seems exactly opposite from what you suggest.
- hcarvalhoalves 14y ago
  > So, it seems exactly opposite from what you suggest. Can I make it more clear? People learn (wrongfully) in OO that objects encapsulate behavior, so the first thing they do is create "Manager" classes and outline their program flow. This is even worse in languages that only gives you classes to work with - e.g., Java. Wrong. The first thing one should do is define the data structures - and when using OO, doubly so, because the data structures will map to classes seamlessly. When you have those "Manager/Controller/Handler" classes, it's a pretty big sign you're inventing a non-object to store all the control flow in one place, instead of thinking about proper objects and message passing.
  - unclebucknasty 14y ago
    That is clearer. Thanks. Now, I know that it makes no sense. :) Classes can and should encapsulate behavior in good OO design. This is why classes can contain methods. I don't know if you think that feature is also "wrong" in an OO language, but without it some of the primary benefits of OO, such as polymorphism, begin to disappear. Speaking of polymorphism, how do you propose that would be achieved under the constraints you would impose? Prior to editing the parent, you had written that you prefer something like: Connection conn = Connection( params ) instead of Connection conn = new ConnectionManager().getConnection( params ) In that case, how would you propose that the former code (i.e. your preferred approach) instantiate the appropriate Connection subclass? There wasn't even a new operator or valid construction syntax in your preferred approach, so perhaps you recognized this limitation and were suggesting some magic would occur. Before editing, you also said not to "get you started on statics". So, without statics, you couldn't even do something like Connection.getInstance(params) to allow the Connection class to determine which subclass to create. So, the calling code would have to be aware of which subclass to instantiate, which would be simply awful. Perhaps this is why you edited your comment. But leaving your edits aside, you still seem to think of objects as only data or structs with no behaviors, which is an extremely limiting constraint on OO design. In fact, it would eliminate so many benefits of OO programming that it wouldn't be OO at all.
    - hcarvalhoalves 14y ago
      > Classes can and should encapsulate behavior in good OO design. This is why classes can contain methods. I don't know if you think that feature is also "wrong" in an OO language, but without it some of the primary benefits of OO, such as polymorphism, begin to disappear. Of course, classes encapsulating behavior is the reason behind OO. What's wrong is the backwards thinking: "I need a place to hold my behavior, let me write a ThingManager class for that". > Connection conn = Connection( params ) instead of Connection conn = new ConnectionManager().getConnection( params ) In that case, how would you propose that the former code (i.e. your preferred approach) instantiate the appropriate Connection subclass? There wasn't even a new operator or valid construction syntax in your preferred approach, so perhaps you recognized this limitation and were suggesting some magic would occur. The point is, why do you have a class after all then? A normal function that returns the appropriate object suffices. Of course this is not possible in pure-OO languages, like Java, so you abuse classes to hold logic like a namespace. Static methods are an even worse perversion of OO, for the same reason (lack of pure functions inside namespaces).

unclebucknasty 14y ago

>* They learn that objects encapsulate behavior, and soon start deriving all kinds of non-objects to hold their actions* If I understand you correctly, it seems you would have reached the opposite conclusion: that is, if I learn that objects encapsulate behaviors/actions then I would create classes like "Connection" with all the attendant methods and would have no need for external classes like ConnectionManager. But, if I treat a Connection like a struct, then I would need these external classes like ConnectionManager to perform the actions. So, it seems exactly opposite from what you suggest.

hcarvalhoalves 14y ago
> So, it seems exactly opposite from what you suggest. Can I make it more clear? People learn (wrongfully) in OO that objects encapsulate behavior, so the first thing they do is create "Manager" classes and outline their program flow. This is even worse in languages that only gives you classes to work with - e.g., Java. Wrong. The first thing one should do is define the data structures - and when using OO, doubly so, because the data structures will map to classes seamlessly. When you have those "Manager/Controller/Handler" classes, it's a pretty big sign you're inventing a non-object to store all the control flow in one place, instead of thinking about proper objects and message passing.
- unclebucknasty 14y ago
  That is clearer. Thanks. Now, I know that it makes no sense. :) Classes can and should encapsulate behavior in good OO design. This is why classes can contain methods. I don't know if you think that feature is also "wrong" in an OO language, but without it some of the primary benefits of OO, such as polymorphism, begin to disappear. Speaking of polymorphism, how do you propose that would be achieved under the constraints you would impose? Prior to editing the parent, you had written that you prefer something like: Connection conn = Connection( params ) instead of Connection conn = new ConnectionManager().getConnection( params ) In that case, how would you propose that the former code (i.e. your preferred approach) instantiate the appropriate Connection subclass? There wasn't even a new operator or valid construction syntax in your preferred approach, so perhaps you recognized this limitation and were suggesting some magic would occur. Before editing, you also said not to "get you started on statics". So, without statics, you couldn't even do something like Connection.getInstance(params) to allow the Connection class to determine which subclass to create. So, the calling code would have to be aware of which subclass to instantiate, which would be simply awful. Perhaps this is why you edited your comment. But leaving your edits aside, you still seem to think of objects as only data or structs with no behaviors, which is an extremely limiting constraint on OO design. In fact, it would eliminate so many benefits of OO programming that it wouldn't be OO at all.
  - hcarvalhoalves 14y ago
    > Classes can and should encapsulate behavior in good OO design. This is why classes can contain methods. I don't know if you think that feature is also "wrong" in an OO language, but without it some of the primary benefits of OO, such as polymorphism, begin to disappear. Of course, classes encapsulating behavior is the reason behind OO. What's wrong is the backwards thinking: "I need a place to hold my behavior, let me write a ThingManager class for that". > Connection conn = Connection( params ) instead of Connection conn = new ConnectionManager().getConnection( params ) In that case, how would you propose that the former code (i.e. your preferred approach) instantiate the appropriate Connection subclass? There wasn't even a new operator or valid construction syntax in your preferred approach, so perhaps you recognized this limitation and were suggesting some magic would occur. The point is, why do you have a class after all then? A normal function that returns the appropriate object suffices. Of course this is not possible in pure-OO languages, like Java, so you abuse classes to hold logic like a namespace. Static methods are an even worse perversion of OO, for the same reason (lack of pure functions inside namespaces).