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

Martin Wirblat <sql.mawi at t-link.de> wrote:
> >IOW, the solution to things being hard to find is to have better 
> >tools. Senders+selector browser are great for this, but maybe other 
> >needs mean more UIs, organized differently could help. 
> >
> >Grouping functionally unrelated things doesn't help, and IMO
> >"system-related" is too vague and too general to be a useful concept.
> >
> >Daniel
> 
> They are functionally related, the relation is: requesting information 
> about the system, adjusting behavior of the system. Senders+selector 
> browsing will not help that much, because you don't know what the 
> system offers or what it needs. That is, why I said browsing these 
> possibilities and requirements with one wellknown starting point is 
> needed. 
> 
> >Personally I think class categories are great for aiding browsing.
> >Simply make sure all these "system level" classes are grouped nicely 
> >in the categories and then I can't see the harm in having a few 
> >classes instead of a single one.
> >
> >It would even make it simpler IMHO to find things that way because you
> >get an extra top level "grouping". Saving the image? Hmmm, perhaps I
> >should look in class Image? :-)
> >
> >Class SystemDictionary doesn't really ring a bell for that.
> >
> >regards, Göran
> 
> Right, and it should be a *single* category to have the single 
> starting point of which I talked. This category would be characterized 
> as having classes which can: requesting information about the system, 
> adjusting behavior of the system. 
> 
> Of course not everything which is 'system-manipulation' can be sorted 
> smoothly in this category, but we should have this as an important 
> goal in mind and try accordingly. 
> 
> regards,
> Martin