[Cuis] Where to put the complexity?

Wed Jul 1 15:10:31 CDT 2015

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).

Especially with exceptions it can be difficult to understand
what exactly the exception is for, and a class comment can
be extremely helpful.

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.

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.

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20150701/09108f29/attachment-0004.html>