Loading ...
Sorry, an error occurred while loading the content.

Re: How To Make Your Java Code Understandable

Expand Messages
  • strazhce
    Hi, ... ok, this is a basic principle - no magic numbers. Not new, but very important. This made me think... We have a codebase, where we use named constants.
    Message 1 of 4 , Apr 4, 2010
    • 0 Attachment
      Hi,

      --- In extremeprogramming@yahoogroups.com, "Abder-Rahman" <abderrahmanali@...> wrote:
      >
      > Simply follow this link to view the article: http://www.agilejavaoop.com/java/how-to-make-your-java-code-understandable/
      >
      ok, this is a basic principle - no magic numbers. Not new, but very important. This made me think...

      We have a codebase, where we use named constants. E.g.:
      class InsuranceConstants{
      final static int INSURANCE_OF_CAR;
      }
      Note the type "int".

      I wonder:
      1. Is there any substantial value to using more specific type? E.g.:
      ...
      final static EInsurance INSURANCE_OF_CAR
      ...
      2. If you have an existing code using "int" approach, what would you do when adding some new features, some new enumerations:
      a] stick to the int approach
      b] mix - use specific types (see 1) for new features, leave ints where they already are
      c] refactor existing ints (replace type code with class refactoring) - BUT: this may need substantial effort, so only a] or b] may be viable

      Thanks for your opinion/ideas.

      Oleg
    • Curtis Cooley
      Primitive obsession is bad. Whenever you have a value that has a meaning, I strongly encourage you to consider making it an object. Often, once you have the
      Message 2 of 4 , Apr 4, 2010
      • 0 Attachment
        Primitive obsession is bad. Whenever you have a value that has a meaning, I
        strongly encourage you to consider making it an object. Often, once you have
        the object, it attracts behavior. If the object doesn't start to hold it's
        own weight, you can get rid of it.

        Beware that constants and enums often lead to
        http://ponderingobjectorienteddesign.blogspot.com/2008/09/if-bugs.html which
        is why I like to make objects. Easier to convert to polymorphism if you
        already have the object.

        On Sun, Apr 4, 2010 at 9:28 AM, strazhce <infobox.oleg@...> wrote:

        >
        >
        > Hi,
        >
        >
        > --- In extremeprogramming@yahoogroups.com<extremeprogramming%40yahoogroups.com>,
        > "Abder-Rahman" <abderrahmanali@...> wrote:
        > >
        > > Simply follow this link to view the article:
        > http://www.agilejavaoop.com/java/how-to-make-your-java-code-understandable/
        > >
        > ok, this is a basic principle - no magic numbers. Not new, but very
        > important. This made me think...
        >
        > We have a codebase, where we use named constants. E.g.:
        > class InsuranceConstants{
        > final static int INSURANCE_OF_CAR;
        > }
        > Note the type "int".
        >
        > I wonder:
        > 1. Is there any substantial value to using more specific type? E.g.:
        > ...
        > final static EInsurance INSURANCE_OF_CAR
        > ...
        > 2. If you have an existing code using "int" approach, what would you do
        > when adding some new features, some new enumerations:
        > a] stick to the int approach
        > b] mix - use specific types (see 1) for new features, leave ints where they
        > already are
        > c] refactor existing ints (replace type code with class refactoring) - BUT:
        > this may need substantial effort, so only a] or b] may be viable
        >
        > Thanks for your opinion/ideas.
        >
        > Oleg
        >
        >
        >



        --
        Curtis Cooley
        curtis.cooley@...
        home:http://curtiscooley.com
        blog:http://ponderingobjectorienteddesign.blogspot.com
        ===============
        Leadership is a potent combination of strategy and character. But if you
        must be without one, be without the strategy.
        -- H. Norman Schwarzkopf


        [Non-text portions of this message have been removed]
      • extremeprogrammer
        Hi. There are many reasons that yield substantial value: 1. It s an enumerated value 2. It s not an arbitrary integer 3. It helps the code to document itself
        Message 3 of 4 , Apr 5, 2010
        • 0 Attachment
          Hi.

          There are many reasons that yield substantial value:

          1. It's an enumerated value
          2. It's not an arbitrary integer
          3. It helps the code to document itself
          4. It prevents certain kinds of programming errors (the fundamental purpose of a type system) by not throwing away type safety
          5. It helps you to add new values to the enumeration
          6. There is almost certainly some conditional logic related to the enumeration. As Curtis has already pointed out, when you Make It An Object (I'm sure this used to be a page on the Mother Wiki, but I can't find it any more), it tends to attract behaviour which can then be handled polymorphically.

          I actually wrote a rather angry blog about this a while ago: http://www.stateofflow.com/journal/62/anti-social-enumerations

          When adding new values to the enumeration, I would most likely take it as an opportunity to replace the integers with enums, primarily to provide type safety, but also as a first step towards redistributing the system intelligence. Since you are most likely going to need to inspect every use of the constants you have in order to determine if the new values need to be considered, changing the type (from int to enum) means that the compiler will tell you where the uses are, and most uses can potentially be fixed by changing the word 'int' to <the name of your enum>. This may result in a bigger checkin that you would have had otherwise, but your codebase will be the better for it.

          Regards,

          Lance


          --- In extremeprogramming@yahoogroups.com, "strazhce" <infobox.oleg@...> wrote:
          >
          > Hi,
          >
          > --- In extremeprogramming@yahoogroups.com, "Abder-Rahman" <abderrahmanali@> wrote:
          > >
          > > Simply follow this link to view the article: http://www.agilejavaoop.com/java/how-to-make-your-java-code-understandable/
          > >
          > ok, this is a basic principle - no magic numbers. Not new, but very important. This made me think...
          >
          > We have a codebase, where we use named constants. E.g.:
          > class InsuranceConstants{
          > final static int INSURANCE_OF_CAR;
          > }
          > Note the type "int".
          >
          > I wonder:
          > 1. Is there any substantial value to using more specific type? E.g.:
          > ...
          > final static EInsurance INSURANCE_OF_CAR
          > ...
          > 2. If you have an existing code using "int" approach, what would you do when adding some new features, some new enumerations:
          > a] stick to the int approach
          > b] mix - use specific types (see 1) for new features, leave ints where they already are
          > c] refactor existing ints (replace type code with class refactoring) - BUT: this may need substantial effort, so only a] or b] may be viable
          >
          > Thanks for your opinion/ideas.
          >
          > Oleg
          >
        Your message has been successfully submitted and would be delivered to recipients shortly.