Beefy Boxes and Bandwidth Generously Provided by pair Networks
more useful options

comment on

( #3333=superdoc: print w/replies, xml ) Need Help??

You do realize that you can write bad code with any module, not just Moose. Just because Moose makes things a little easier and standardizes/formalizes a few concepts does not mean it forces you to then go use those things badly. Seems to me that is the fault of someone not understanding good OO design and/or abusing the features provided by the tool. This really isn't Moose's fault, it is the users.

So Moose doesn't really allow you to talk about object attributes unless you write (or, much more likely, generate) accessor methods.

Actually, Moose advises you that accessors are a good way to encapsulate attribute access, but if you don't want to generate an accessor you don't have too. And if you want to then do direct HASH access internally, you can. Moose does not stop you from doing that, nor does is it impose any penalties and not allow you to take advantage of other things like managed instance construction, etc.

So OO design using Moose will almost always revolve around, primarily focus on what attributes you want your object to have and the accessor methods for them. And that leads to class design that is mostly glorified hashes (or Pascal 'record's, aka. C 'struct's). And I've seen that suck in the long run so many times.

Actually, if you do proper OO design, then no, this is not true. You are blaming the tool for the mess the user made with it.

Implement attributes as constants so you get compile-time catching of typos on their names. Make internal accessing of attributes actually look different and a bit ugly, so you know the difference and you keep internal implementation details internal.

I agree that making everything methods does kind of make everything blend together, and that Perl's highly "virtual" approach to method dispatching makes it very hard to catch typos. However the encapsulation is kind of a good thing.

Delegate rather than inherit when combining classes.

Sure, Moose makes this easy too with the handles attribute option.

If you start slipping back into type-based validation (as you are almost pushed into doing as use more Moose), you will find yourself more and more doing C++/Java-style design.

Again, you are not pushed into using types in Moose, it is an option.

You'll end up with classes as bags of attributes with accessors and then you'll try to put protections around those accessor by adding "types" and adding 'before' and 'after' wrappers. Your logic for a single class will be split apart into tons of tiny pieces where the order and interactions will become almost impossible to see, predict, adjust, and debug.

Again, don't blame the tool for someone being stupid. Nothing about Moose forces you into doing something as idiotic as you describe. Just because a feature exists doesn't mean you have to use it, and most certainly does not mean that you should abuse it.

(Yes, I'm actually working on several simple tools to make good OO design more convenient in Perl 5. For example, delegation of a whole list of methods should be something trivial to write, almost as trivial to write as 'use base "Thingy";' or 'does CoolStuff;'. But even while it isn't trivial in Perl 5, it also isn't particularly hard. Just a bit inconvenient.)

Where is the code? I would love to have a look.


In reply to Re^2: How Large Does Your Project Have To Be to Justify Using Moose? (modular) by stvn
in thread How Large Does Your Project Have To Be to Justify Using Moose? by jgamble

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?

What's my password?
Create A New User
Domain Nodelet?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (2)
As of 2023-01-29 02:48 GMT
Find Nodes?
    Voting Booth?

    No recent polls found