>Let me rephrase - putting in one class/one category two pieces of code
>that could live just as easily separately is bad software engineering.
>It is called "low cohesion". 
>
>It is considered bad SE, because it makes software harder, not easier,
>to understand.
>
>If you want to solve a human interface problem, you create a UI. You
>don't twist the code until is solves this specific problem, which is
>just one of many according to which you could shape the code (on
>alternative is - we should have all printing stuff together, without
>separating system settings from implementation. Now which do you
>choose?).
>
>Daniel

You don't have to twist the code, I think this is demonstrated by 
Stephane, who creates easily new classes and drag and drop's the 
methods over there. Look for instance at Utilities class comment. It 
says: 'methods that don't naturally attach to anything else'. These 
methods are functions and you won't create instances of the new 
classes, they are just more or less function-holders. There is no 
complicated interdependency of classes and methods to understand. It 
is only a question of 'listing' these functions. 

So this is not normal code, and besides, your rule of thumb that only 
separated code is good SE is oversimplified, because there is always 
an optimal balance of separation and aggregation. 

To integrate code with an UI means more work than simply grouping
pieces of code together and an UI would need this grouping-info anyway.
 

There is no need to put printing-related stuff together, because there 
is a method-category 'printing' and printing selectors include 
something like 'print'. This stuff is what you will find with browsing 
implementors/selectors without putting it together! 

regards,
Martin