[Cuis] Where to put the complexity?
Phil (list)
pbpublist at gmail.com
Wed Jul 1 15:54:22 CDT 2015
On Wed, 2015-07-01 at 22:10 +0200, Peter van Rooijen wrote:
> Hi all,
>
>
> I believe that a class can be justified simply because it gives you
> an intention revealing name in the code, and room to put a
> class comment (possibly an extensive one).
>
I believe that's the thinking that results in most of the current
Exception subclasses. I personally don't care for it, but will go with
the consensus which seems to be OK with it.
>
> Especially with exceptions it can be difficult to understand
> what exactly the exception is for, and a class comment can
> be extremely helpful.
>
But Exceptions have a #signal: value which could also easily convey that
information. (that's not always true, but the point is there are other
ways to convey the information other than subclassing) Also keep in
mind that many exceptions, such as the one I was pointing out, are never
even seen by the user: they are used as an alternate messaging channel
by the code.
>
> So, one thing that I am saying is that a class with NO behavior
> but a well-chosen name, superclass and a clear class comment, can
> be a very valuable part of a system.
>
>
> Another thing I believe is that a class by itself is not very complex.
> Complex in the sense of adding to the overall complexity of the
> system.
>
True, a single class by itself is not very complex. Multiply that by
100x or more and the story changes. To me, one of the more obvious
aspects of complexity is the aggregate # of classes/methods/lines of
code in a system. In this particular case, I was wondering out loud if
this particular trade-off (i.e. creating a class to save 1-2 lines of
code) was worth it. I find it interesting that exception handling is
one of the younger parts of Smalltalk and, to me at least, it really
stands out as being rather strangely implemented in terms of the class
hierarchy.
>
> I have been interested in complexity and reducing it for a very long
> time
> (since before I started with Smalltalk) and I have often thought about
> the rules one would put into a tool that automatically measured the
> complexity of a system of code.
>
>
> One application of such a tool would be refactoring. Generally, after
> I
> refactor, all my old tests should still run, but also, my overall
> complexity
> should be lower.
>
>
> At least, that was my thinking, and a tool that measures
> complexity could help with that. In a sense it would be a more
> sophisticated version of the "rule of three".
>
>
> In any case, I never implemented such a tool, but did develop a set of
> heuristics/rules that I let guide me to decide whether I should
> extract
> methods, extract classes, etc. Part of these heuristics was that a
> class
> by itself did not add that much.
>
>
> I don't remember most of my rules although I probably still follow
> them
> intuitively. Perhaps a class added more complexity than a method, but
> not
> more than two methods, I don't really know.
>
>
> I wonder what others do to decide how to factor code.
>
You might want to take a look at Moose http://www.moosetechnology.org/
It's a tool to help you analyze and understand a given body of code.
It's a bit fragile/brittle/incomplete, but right now it's about the best
I've found to date to try to analyze and quantify complexity. Also, you
could take a look at the work VPRI is doing related to FoNC/STEPS as
minimizing complexity is core to what they are working on.
>
> Cheers, Peter
>
>
>
>
>
> On Wed, Jul 1, 2015 at 2:52 PM, Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> wrote:
>
>
> 2015-06-30 0:17 GMT+02:00 Dan Norton <dnorton at mindspring.com>:
> On 29 Jun 2015 at 13:23, Juan Vuletich wrote:
>
> > Hi folks,
> >
> > On 6/29/2015 10:51 AM, Ken.Dickey wrote:
> > > On Mon, 29 Jun 2015 07:09:43 -0400
> > > "Phil (list)"<pbpublist at gmail.com> wrote:
> > >> .. Is it
> > >> worth having a class for this vs. raising the
> more general
> > Notification
> > >> and then checking for a
> #ReparseAfterSourceEditing signal, and if
> > it
> > >> isn't, re-raise Notification in its sole handler?
> > >> ..
> > >> This is a specific example of the more general
> question of where
> > to draw
> > >> the line on having single, or very limited, use
> classes and
> > methods vs.
> > >> adding a tiny bit of complexity in one or two
> methods to simplify
> > the
> > >> overall image or package in question. Thoughts?
> > > I would say the overriding goal is clarity.
> > >
> > > It is important work to refactor code to have the
> same behavior
> > but be easier to understand.
> > >
> > > A Smalltalk style goal is to have small methods
> which do things
> > clearly. This tends to lead to lots of small
> methods.
> > >
> > > Specializing classes for one or just a few methods
> may seem
> > wasteful, but computer resources are cheap.
> > >
> > > Look at class #PartsBinMorph. Would you say the
> having the
> > additional class is wasteful?
> > >
> > > It is a tough balance. Aesthetics and restraint
> require judgement
> > and we don't always get it right. It takes time.
> > >
> > > I only have so many life hours left. I feel my
> time is valuable.
> > I prefer to understand.
> > >
> > > Thank you so much for taking the time to make Cuis
> more
> > comprehensible.
> > >
> > > $0.02
> > > -KenD
> >
> > I fully support Ken. I don't think that a general
> answer is correct
> > in
> > all cases here. It is a matter of making code easy
> to understand.
> > But
> > also making it consistent and pretty.
> >
> > In general, I don't like making general classes know
> much about
> > details
> > of specific use cases. But there might be
> exceptions.
> >
> > If you feel like experimenting with this kind of
> stuff, send your
> > suggestions to the mail list so we can discuss.
> >
> > In the particular case of ReparseAfterSourceEditing,
> I agree that a
> > class that does nothing is a bit strange. But, what
> is the
> > alternative?
> > How would the sole exception handler know what to do
> with a general
> > Notification? I think the handler looks quite
> reasonable right now.
> > And
> > the pollution of the global space might be tolerable
> if the
> > alternative
> > is more convoluted code...
> >
>
>
> Making code easy to understand is very valuable.
> Simple things should be simple to
> accomplish, but achieving this in an API may not
> always be easy.
>
> This weekend I spent lots of "quality time" with the
> debugger, trying to figure out why I could
> not get a new window with a PluggableListMorph to work
> like another one which had exactly
> the behavior I wanted. The bug was that a method
> referred to by the #indexSetter: keyword
> needed to send the #selectedItem: message, which is
> not mentioned by keyword. Not sure
> what the answer is for that one but I'm working on
> notes to try to avoid that stupid mistake in
> the future. :)
>
> I'm just saying we should do anything we can to
> enhance clarity as well as simplify.
>
> - Dan
>
>
>
>
> Since you are using the right keywords, maybe it's time to
> view it again
>
> Simple made easy
> http://www.infoq.com/presentations/Simple-Made-Easy
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
>
>
>
> _______________________________________________
> Cuis mailing list
> Cuis at jvuletich.org
> http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
More information about the Cuis
mailing list