http://www.perlmonks.org?node_id=259379


in reply to Short Refactoring Tip: let the object do it for you

I would have thought this was common knowledge/sense, but maybe that's just me :) (Different programming/logic backgrounds etc.) Generally its good to reduce such things to the essentials that will be needed by anything calling the object, and not make them know how it works internally. (The class interface to the outside world, that is ,)

C. *forgets we're dealing with newbie programmers here quite often*

  • Comment on Re: Short Refactoring Tip: let the object do it for you

Replies are listed 'Best First'.
Re2: Short Refactoring Tip: let the object do it for you
by dragonchild (Archbishop) on May 20, 2003 at 14:34 UTC
    Ah, but it isn't common sense. In old-time C, for example, you wouldn't write something like that. Instead, you would write something like:
    #define STATUS1 (1 << 0) #define STATUS2 (1 << 1) #define STATUS3 (1 << 2) #define STATUS4 (1 << 3) ... typedef int Status; ... Status product_status = 0; ... if (product_status & (STATUS1 | STATUS2)) { // Do stuff here }
    It's imperative programming, man! You gotta be in control or you lose your job! (Think about it - if you couldn't point to incomprehensible code, your PHB would find someone who could. I mean, if anyone could write code that works, then how do you justify your 6-figure consulting fee?)

    Also, writing good class interfaces requires both time and understanding of the business domain. Maybe your world allows for these, but no application I've ever had the (mis)fortune to work on has ever been in that most blessed of states. (No, that isn't Texas, either.)

    ------
    We are the carpenters and bricklayers of the Information Age.

    Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

    Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

      I have no idea what common sense has to do with C.. (Or rather why something shouldn't be, just because someone did it in C differently).

      (For the record, I avoid C/C++ like the plague, or try to..)
      Not everyone *can* write code that works, much less code that is maintainable, usable etc. Obfuscating for the sake of it never appealed to me.
      We do take time here and define our interfaces (between products+components) - it saves lots of hassle later.

      C.