3 ms·

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

> 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

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