<div dir="ltr">Hi all,<div><br></div><div>I believe that a class can be justified simply because it gives you</div><div>an intention revealing name in the code, and room to put a</div><div>class comment (possibly an extensive one).</div><div><br></div><div>Especially with exceptions it can be difficult to understand</div><div>what exactly the exception is for, and a class comment can</div><div>be extremely helpful.</div><div><br></div><div>So, one thing that I am saying is that a class with NO behavior</div><div>but a well-chosen name, superclass and a clear class comment, can</div><div>be a very valuable part of a system.</div><div><br></div><div>Another thing I believe is that a class by itself is not very complex.</div><div>Complex in the sense of adding to the overall complexity of the system.</div><div><br></div><div>I have been interested in complexity and reducing it for a very long time</div><div>(since before I started with Smalltalk) and I have often thought about</div><div>the rules one would put into a tool that automatically measured the</div><div>complexity of a system of code.</div><div><br></div><div>One application of such a tool would be refactoring. Generally, after I</div><div>refactor, all my old tests should still run, but also, my overall complexity</div><div>should be lower.</div><div><br></div><div>At least, that was my thinking, and a tool that measures</div><div>complexity could help with that. In a sense it would be a more</div><div>sophisticated version of the "rule of three".</div><div><br></div><div>In any case, I never implemented such a tool, but did develop a set of</div><div>heuristics/rules that I let guide me to decide whether I should extract</div><div>methods, extract classes, etc. Part of these heuristics was that a class</div><div>by itself did not add that much.</div><div><br></div><div>I don't remember most of my rules although I probably still follow them</div><div>intuitively. Perhaps a class added more complexity than a method, but not</div><div>more than two methods, I don't really know.</div><div><br></div><div>I wonder what others do to decide how to factor code.</div><div><br></div><div>Cheers, Peter</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 1, 2015 at 2:52 PM, Nicolas Cellier <span dir="ltr"><<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">2015-06-30 0:17 GMT+02:00 Dan Norton <span dir="ltr"><<a href="mailto:dnorton@mindspring.com" target="_blank">dnorton@mindspring.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>On 29 Jun 2015 at 13:23, Juan Vuletich wrote:<br>
<br>
> Hi folks,<br>
><br>
> On 6/29/2015 10:51 AM, Ken.Dickey wrote:<br>
> > On Mon, 29 Jun 2015 07:09:43 -0400<br>
> > "Phil (list)"<<a href="mailto:pbpublist@gmail.com" target="_blank">pbpublist@gmail.com</a>> wrote:<br>
> >> .. Is it<br>
> >> worth having a class for this vs. raising the more general<br>
> Notification<br>
> >> and then checking for a #ReparseAfterSourceEditing signal, and if<br>
> it<br>
> >> isn't, re-raise Notification in its sole handler?<br>
> >> ..<br>
> >> This is a specific example of the more general question of where<br>
> to draw<br>
> >> the line on having single, or very limited, use classes and<br>
> methods vs.<br>
> >> adding a tiny bit of complexity in one or two methods to simplify<br>
> the<br>
> >> overall image or package in question. Thoughts?<br>
> > I would say the overriding goal is clarity.<br>
> ><br>
> > It is important work to refactor code to have the same behavior<br>
> but be easier to understand.<br>
> ><br>
> > A Smalltalk style goal is to have small methods which do things<br>
> clearly. This tends to lead to lots of small methods.<br>
> ><br>
> > Specializing classes for one or just a few methods may seem<br>
> wasteful, but computer resources are cheap.<br>
> ><br>
> > Look at class #PartsBinMorph. Would you say the having the<br>
> additional class is wasteful?<br>
> ><br>
> > It is a tough balance. Aesthetics and restraint require judgement<br>
> and we don't always get it right. It takes time.<br>
> ><br>
> > I only have so many life hours left. I feel my time is valuable.<br>
> I prefer to understand.<br>
> ><br>
> > Thank you so much for taking the time to make Cuis more<br>
> comprehensible.<br>
> ><br>
> > $0.02<br>
> > -KenD<br>
><br>
> I fully support Ken. I don't think that a general answer is correct<br>
> in<br>
> all cases here. It is a matter of making code easy to understand.<br>
> But<br>
> also making it consistent and pretty.<br>
><br>
> In general, I don't like making general classes know much about<br>
> details<br>
> of specific use cases. But there might be exceptions.<br>
><br>
> If you feel like experimenting with this kind of stuff, send your<br>
> suggestions to the mail list so we can discuss.<br>
><br>
> In the particular case of ReparseAfterSourceEditing, I agree that a<br>
> class that does nothing is a bit strange. But, what is the<br>
> alternative?<br>
> How would the sole exception handler know what to do with a general<br>
> Notification? I think the handler looks quite reasonable right now.<br>
> And<br>
> the pollution of the global space might be tolerable if the<br>
> alternative<br>
> is more convoluted code...<br>
><br>
<br>
</div></div>Making code easy to understand is very valuable. Simple things should be simple to<br>
accomplish, but achieving this in an API may not always be easy.<br>
<br>
This weekend I spent lots of "quality time" with the debugger, trying to figure out why I could<br>
not get a new window with a PluggableListMorph to work like another one which had exactly<br>
the behavior I wanted. The bug was that a method referred to by the #indexSetter: keyword<br>
needed to send the #selectedItem: message, which is not mentioned by keyword. Not sure<br>
what the answer is for that one but I'm working on notes to try to avoid that stupid mistake in<br>
the future. :)<br>
<br>
I'm just saying we should do anything we can to enhance clarity as well as simplify.<br>
<span><font color="#888888"><br>
- Dan<br>
</font></span><div><div><br></div></div></blockquote><div><br></div></div></div><div>Since you are using the right keywords, maybe it's time to view it again<br></div><div>Simple made easy<br><a href="http://www.infoq.com/presentations/Simple-Made-Easy" target="_blank">http://www.infoq.com/presentations/Simple-Made-Easy</a> <br><br></div><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>
_______________________________________________<br>
Cuis mailing list<br>
<a href="mailto:Cuis@jvuletich.org" target="_blank">Cuis@jvuletich.org</a><br>
<a href="http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org" rel="noreferrer" target="_blank">http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org</a><br>
</div></div></blockquote></span></div><br></div></div>
<br>_______________________________________________<br>
Cuis mailing list<br>
<a href="mailto:Cuis@jvuletich.org">Cuis@jvuletich.org</a><br>
<a href="http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org" rel="noreferrer" target="_blank">http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org</a><br>
<br></blockquote></div><br></div>