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

Re: [agile-usability] Agile IDEs?

Expand Messages
  • Jon Kern
    i m hung up on your comment that refactoring should result in ...lots of classes with a couple of methods each... is that an assertion of yours or are you
    Message 1 of 12 , Sep 19, 2006
    • 0 Attachment
      i'm hung up on your comment that refactoring should result in
          "...lots of classes with a couple of methods each..."
      is that an assertion of yours or are you lamenting a side effect of non-Smalltalk IDEs?

      Could you expand on this?

      -- jon


      acyment said the following on 9/19/2006 5:43 PM:

      Hi everyone out there,

      I reckon that many of you agile people have used Smalltalk for some
      time. I worked as a ST developer for over an year and, after coming
      back to the Java/.NET world there's one thing I really miss from
      those days: the browser. The contradiction I see in most (non-
      Smalltalk) IDEs goes as follows:

      - Refactoring is a great engineering practice (great: IDEs support
      refactoring)
      - As a consequence of refactoring we should get lots of classes with
      a couple of methods each, which leads to
      - Loads of new files (associated to the newly created classes)
      - Classes with 10-12 methods each, which are not as easily browsed
      as they were when they only had 2 monstruous 100-lines methods

      My point is: isn't a Smalltalk-like IDE (Class browser that lets you
      navigate the hierarchy and that would show only one method at the
      same time + stop depending on files for storing source code) the
      logical step to take after having embraced refactoring?

      Wonder what you people think about this...

      Cheers,
      Alan

    • acyment
      Don t ask me, ask Sun & Microsoft! Both Java & .NET compilers and IDEs make strong assumptions on the 1-to-1 relationship between files & classes. This I find
      Message 2 of 12 , Sep 19, 2006
      • 0 Attachment
        Don't ask me, ask Sun & Microsoft! Both Java & .NET compilers and IDEs
        make strong assumptions on the 1-to-1 relationship between files &
        classes. This I find incredibly awkward.

        Cheers,
        Alan
        --- In agile-usability@yahoogroups.com, Phlip <phlip2005@...> wrote:
        >
        > acyment wrote:
        >
        > > - Refactoring is a great engineering practice (great: IDEs support
        > > refactoring)
        > > - As a consequence of refactoring we should get lots of classes with
        > > a couple of methods each, which leads to
        > > - Loads of new files (associated to the newly created classes)
        >
        > Why? Why should there be many files, just because there are many
        > classes? Shouldn't the programmer have the option to store part of a
        > class, all a class, or a module with many classes in a file, depending
        > on other factors? Why should the decision to en-class something be
        > automatically tied to the decision to en-file it??
        >
        > --
        > Phlip
        > http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!
        >
      • Phlip
        ... Wait till you see what Ruby on Rails can do with the Model View Controller pattern, using techniques which I suspect include splitting class definitions
        Message 3 of 12 , Sep 19, 2006
        • 0 Attachment
          acyment wrote:

          > Don't ask me, ask Sun & Microsoft! Both Java & .NET compilers and IDEs
          > make strong assumptions on the 1-to-1 relationship between files &
          > classes. This I find incredibly awkward.

          Wait till you see what Ruby on Rails can do with the Model View
          Controller pattern, using techniques which I suspect include splitting
          class definitions across different files.

          --
          Phlip
          http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!
        • acyment
          Good point. It is my assertion, but not a fully justified one. I mainly stated that after recalling OOP classes back in school: aim at having shallow
          Message 4 of 12 , Sep 19, 2006
          • 0 Attachment
            Good point. It is my assertion, but not a fully justified one. I
            mainly stated that after recalling OOP classes back in school: "aim at
            having shallow hierarchies of classes with not too long a protocol in
            each one". Any other combination sounds (I admit I might be
            overgeneralizing) like an uglier design or too simple an app:

            - Few/Lots classes with lots of methods in each one("more than one
            responsability in those classes")
            - Few classes with only a few methods in each one ("simple app, not
            the ones I'm referring to here")

            Do you people agree with this, at least in general terms?

            Cheers,
            Alan
          • Jon Kern
            i think it is funny being called you people ;=) i can t speak for others... however, there is often a correlation between good design and - depth of
            Message 5 of 12 , Sep 19, 2006
            • 0 Attachment
              i think it is funny being called "you people" ;=)

              i can't speak for others... however, there is often a correlation between good design and
                  - depth of inheritance hierarchy being shallow
                  - number of methods in a class
                  - number of attributes in a class
                  - ratio of attributes to methods in a class

              -- jon

              acyment said the following on 9/19/2006 11:17 PM:

              Good point. It is my assertion, but not a fully justified one. I
              mainly stated that after recalling OOP classes back in school: "aim at
              having shallow hierarchies of classes with not too long a protocol in
              each one". Any other combination sounds (I admit I might be
              overgeneralizing) like an uglier design or too simple an app:

              - Few/Lots classes with lots of methods in each one("more than one
              responsability in those classes")
              - Few classes with only a few methods in each one ("simple app, not
              the ones I'm referring to here")

              Do you people agree with this, at least in general terms?

              Cheers,
              Alan

            • Desilets, Alain
              ... For that matter, why should there be many small classes at all? We all know that systems with huge bloated classes are hard to understand and work with.
              Message 6 of 12 , Sep 20, 2006
              • 0 Attachment
                > > - Refactoring is a great engineering practice (great: IDEs support
                > > refactoring)
                > > - As a consequence of refactoring we should get lots of
                > classes with a
                > > couple of methods each, which leads to
                > > - Loads of new files (associated to the newly created classes)
                >
                > Why? Why should there be many files, just because there are
                > many classes? Shouldn't the programmer have the option to
                > store part of a class, all a class, or a module with many
                > classes in a file, depending on other factors? Why should the
                > decision to en-class something be automatically tied to the
                > decision to en-file it??

                For that matter, why should there be many small classes at all?

                We all know that systems with huge bloated classes are hard to
                understand and work with. But in my own experience, systems with tiny
                useless classes (in the sense that they don't do much by themselves) are
                equally hard to understand and work with.

                When refactoring, I tend to adopt a very pragmatic approach, as opposed
                to one that is based abstract principle. In other words, I won't split a
                big class in two, just for the sake of making my class size smaller. But
                if I find I am having difficulty understanding how a class works because
                it's too large, then I will split it into smaller ones.

                Alain
              • Desilets, Alain
                i think it is funny being called you people ;=) i can t speak for others... however, there is often a correlation between good design and - depth of
                Message 7 of 12 , Sep 20, 2006
                • 0 Attachment
                  Message
                   

                  i think it is funny being called "you people" ;=)

                  i can't speak for others... however, there is often a correlation between good design and
                      - depth of inheritance hierarchy being shallow
                      - number of methods in a class
                      - number of attributes in a class
                      - ratio of attributes to methods in a class 
                   
                  How do you define "good" design.
                   
                  Alain
                • Ilja Preuss
                  ... The Eclipse developers obviously thought that it might be a good idea, because you can configure to do something that quite close. Not too surprising,
                  Message 8 of 12 , Sep 20, 2006
                  • 0 Attachment
                    acyment schrieb:

                    > My point is: isn't a Smalltalk-like IDE (Class browser that lets you
                    > navigate the hierarchy and that would show only one method at the
                    > same time + stop depending on files for storing source code) the
                    > logical step to take after having embraced refactoring?
                    >
                    > Wonder what you people think about this...

                    The Eclipse developers obviously thought that it might be a good idea,
                    because you can configure to do something that quite close.

                    Not too surprising, taking into account that Eclipse is the successor of
                    Visual Age for Java, which quite closely resembled a Smalltalk
                    environment (probably modeled after Visual Age for Smalltalk) - to the
                    point that it didn't use files to store the source code.

                    Cheers, Ilja
                  • Carl Zetie
                    Ilja Preuss The Eclipse developers obviously thought that it might be a good idea, because you can configure to do something that quite close. Not too
                    Message 9 of 12 , Sep 21, 2006
                    • 0 Attachment
                      "Ilja Preuss">>>
                      The Eclipse developers obviously thought that it might be a good idea,
                      because you can configure to do something that quite close.

                      Not too surprising, taking into account that Eclipse is the successor of
                      Visual Age for Java, which quite closely resembled a Smalltalk
                      environment (probably modeled after Visual Age for Smalltalk) - to the
                      point that it didn't use files to store the source code.
                      <<<
                       
                      Yes, many of the same indviduals who created VA SmallTalk went on to build VA Java and ultimately Eclipse, retaining and refining many of their best design concepts along the way.
                       
                      In fact, if memory serves VA Java was not only modeled after VA SmallTalk, it was actually written in VA SmallTalk (in its earliest versions). 
                       
                      However, I also remember that VA Java's class-centric approach (contrasted with other IDE's file-centric approach) tended to generate polar responses: many people who were used to a traditional file-centric approach  (which makes a lot more sense in a language like C, with its Includes and Defines) or coming to Java from a trad 3GL background (C, Fortran, Pascal...) found it made the learning curve steeper, and meant it took longer to get past the point where the IDE was a hindrance not a help. On the other hand, the (sadly, smaller) population coming from SmallTalk and similar backgrounds found it very natural.
                       
                      Again if memory serves, IBM eventually had to bow to market pressure and the preferences of the majority and adopt in its WSAD line the file-centric approach -- but the class-centric approach lived on in the minds of the creators of Eclipse.
                       
                       
                      ***PLEASE NOTE: this is my personal, possibly unreliable, memory of events that I lived through. Your Memory May Differ. This in no way whatsoever represents my employer's official position or any kind of official history of VA or Eclipse!
                       

                      --
                      View my personal blog at TheCzarDictates.blogspot.com

                      The contents of this message represent the
                      personal opinion of Carl Zetie and do not
                      reflect the opinions of his employer
                    • Desilets, Alain
                      ... Here s a question for this community. Was bowing to market pressure a good thing or not in this particular case? ... Alain Désilets, MASc Agent de
                      Message 10 of 12 , Sep 21, 2006
                      • 0 Attachment
                        > Again if memory serves, IBM eventually had to bow to market pressure and the
                        > preferences of the majority and adopt in its WSAD line the file-centric approach --
                        > but the class-centric approach lived on in the minds of the creators of Eclipse.

                        Here's a question for this community. Was bowing to market pressure a good thing or not in this particular case?


                        ----
                        Alain Désilets, MASc
                        Agent de recherches/Research Officer
                        Institut de technologie de l'information du CNRC /
                        NRC Institute for Information Technology

                        alain.desilets@...
                        Tél/Tel (613) 990-2813
                        Facsimile/télécopieur: (613) 952-7151

                        Conseil national de recherches Canada, M50, 1200 chemin Montréal,
                        Ottawa (Ontario) K1A 0R6
                        National Research Council Canada, M50, 1200 Montreal Rd., Ottawa, ON
                        K1A 0R6

                        Gouvernement du Canada | Government of Canada
                      Your message has been successfully submitted and would be delivered to recipients shortly.