3 ms·

> 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 firs

> 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
    >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). But this implies that there is never a natural hierarchy amongst classes or a case wherein you want a collection of objects to be managed by a class whose responsibility is to know about or manage objects. Those situations can and do arise. And shoving such functionality down into the "managed" objects themselves seems less desirable in my view. In such a design, the managed objects are basically saying "I am a subtype of x, and I also know about and manage other subtypes of x, similar to me". Why should each x carry around such baggage and worry about managing other objects? To me, that breaks good OO design and separation of concerns. So, while I think Manager concepts can be abused, I also believe it is overkill to simply "outlaw" their use in any situation. Again, going back to the DriverManager example, I would say that such a class is a more natural fit for managing drivers, registering them, etc., than the Driver class itself. I agree that static methods aren't very OO-compliant. Ironically, I think they exist in pure OO languages specifically because of the strong class orientation. So, they are at times, in effect, the "normal function that returns the appropriate object subclasses" that you prefer.

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
  >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). But this implies that there is never a natural hierarchy amongst classes or a case wherein you want a collection of objects to be managed by a class whose responsibility is to know about or manage objects. Those situations can and do arise. And shoving such functionality down into the "managed" objects themselves seems less desirable in my view. In such a design, the managed objects are basically saying "I am a subtype of x, and I also know about and manage other subtypes of x, similar to me". Why should each x carry around such baggage and worry about managing other objects? To me, that breaks good OO design and separation of concerns. So, while I think Manager concepts can be abused, I also believe it is overkill to simply "outlaw" their use in any situation. Again, going back to the DriverManager example, I would say that such a class is a more natural fit for managing drivers, registering them, etc., than the Driver class itself. I agree that static methods aren't very OO-compliant. Ironically, I think they exist in pure OO languages specifically because of the strong class orientation. So, they are at times, in effect, the "normal function that returns the appropriate object subclasses" that you prefer.