Encapsulation is too global



  • Our boss hired this offshore-H1B super-developer who swears he always uses the best design patterns because it's the right way of doing things.

    This guy wrote a class that has about 50 modest private methods, each with between 10 and 20+ parameters. Why? Because class-level encapsulation is (his words) "too global" - he was never able to explain what he meant by this.

    To get around that, he always passes every variable a method references as a parameter, and never uses instance variables.

    As with most mature systems, the call stack can be somewhat deep, so methods frequently pass through parameters (that they themselves don't need) on their way to lower level methods. Any time we need to omit a parameter from some method, we need to delete it from that methods' signature, then work backwards up the stack to see what breaks. Thankfully, at least we have IDEs to point out the errors; doing this in the days of vi-as-dev-environment would have been horrific. 

    Gotta love this profession!

     



  • <meta http-equiv="CONTENT-TYPE" content="text/html; charset=utf-8"><title></title><meta name="GENERATOR" content="OpenOffice.org 3.0 (Win32)"><style type="text/css"> </style>

    Sounds like he really doesn't understand OO. Perhaps he should stop worrying about "patterns" and concentrate on OO basics.

    Sadly, I've seen this sort of code before. You have my sincerest sympathies.






  • @snoofle said:

    Our boss hired this offshore-H1B super-developer who swears he always uses the best design patterns because it's the right way of doing things.

    This guy wrote a class that has about 50 modest private methods, each with between 10 and 20+ parameters. Why? Because class-level encapsulation is (his words) "too global" - he was never able to explain what he meant by this.

    To get around that, he always passes every variable a method references as a parameter, and never uses instance variables.

    As with most mature systems, the call stack can be somewhat deep, so methods frequently pass through parameters (that they themselves don't need) on their way to lower level methods. Any time we need to omit a parameter from some method, we need to delete it from that methods' signature, then work backwards up the stack to see what breaks. Thankfully, at least we have IDEs to point out the errors; doing this in the days of vi-as-dev-environment would have been horrific. 

    Gotta love this profession!

     

    Well that's...a pattern.



  • @snoofle said:

    To get around that, he always passes every variable a method references as a parameter, and never uses instance variables.

    But, don't you see, his methods are now referentially transparent, so the compiler can be far more aggresive optimising them :)

     


  • ♿ (Parody)

    @snoofle said:

    This guy wrote a class that has about 50 modest private methods, each with between 10 and 20+ parameters
    Could've been worse.  Could have been 5 or 10 gigantic private methods.




Log in to reply