Re^3: How Large Does Your Project Have To Be to Justify Using Moose? (modular)by tye (Cardinal)
|on Oct 22, 2011 at 21:37 UTC||Need Help??|
I'm criticizing Moose for nearly discouraging the designing of a class based on just the interface and not exposing the attributes (which should be internal to the implementation). Even if you don't have Moose generate accessors, then it generates a constructor that still exposes the attributes. And if you don't generate accessors then you can't make use of many roles.
I'm starting to realize that there are people (I can't tell how many / how common yet) that can't even really conceive of designing a class without jumping straight to building a list of attributes, even after you explain to them that they should design the interface before designing the attributes (which are part of the implementation). Moose certainly encourages that mindset.
And I keep finding more and more instances of bad class design that look to me to be primarily due to way too much focus on an object as "just a bag of attributes".
When I design a class, the constructor(s) are just another part of the interface. They don't expose the internal attribute names. So I don't understand the mindset of making the constructor just be a list attribute-name and attribute-value pairs, even if that is just the default that can be overridden. It leads to classes that poorly encapsulate the internal details. It is anti-modular.
Worst of all, it encourages making classes that expose data structure which encourages encoding class-specific behavior outside of the class (the most common sign of "bad design" that I keep finding and then looking for the source of and tracking back to a class design concentrating on a list of attributes).
But I'd likely implement the square as a list of 4 x/y coordinates. And I'm not sure how I want to store the coordinates (as pairs or as parallel arrays or ?). I don't even think too much about how I'm going to implement the square's data when I'm defining the interface for the square.
I design the interface first and come up with my first stab at what attributes to use to implement it later. And changing my implementation shouldn't force me to change my interface.
Providing so many ways to plumb attributes straight into the class's interface actually makes it hard to keep the interface separate. And then there are the add-on tools that become useless or much less useful if you don't plumb your attributes to the interface.
I'm coming to realize that the benefit of modular programming practices is that they are slightly inconvenient and thus force you to see the lack of perfection in your first thought of a design and encourage you to spend some time re-thinking and iterating the design, often resulting in you improving the design (and sooner rather than later and thus saving much larger spans of time / effort).
It should be slightly inconvenient to delegate a method. That way, you don't just blithely delegate way too many methods and end up delegating methods that are quite inappropriate and are going to lead to problems (I've seen several instances of that just this week due to old uses of inheritance). It should be more inconvenient to provide a bare accessor to an attribute. You should only provide accessors when they really make sense for the interface, completely ignoring the current implementation.
The construction of an accessor should be motivated by the interface. When you go to implement that accessor, at that point you might decide that it also makes sense to make an attribute that simply mirrors the data plumbed via that accessor. You should not follow the design decision about including some attribute with trying to decide whether or not you want to have an accessor for it.
Otherwise, your interface is being driven by your implementation, and that is a perfect example of anti-modular design.