Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!usenet.ukfsn.org!not-for-mail From: Martin Gregorie Newsgroups: comp.lang.java.programmer Subject: Re: Aspect questions? Date: Tue, 28 Feb 2012 00:12:48 +0000 (UTC) Organization: UK Free Software Network Lines: 50 Message-ID: References: <4f4a6b1d$0$290$14726298@news.sunsite.dk> NNTP-Posting-Host: 84.45.235.129 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Trace: localhost.localdomain 1330387968 901 84.45.235.129 (28 Feb 2012 00:12:48 GMT) X-Complaints-To: usenet@localhost.localdomain NNTP-Posting-Date: Tue, 28 Feb 2012 00:12:48 +0000 (UTC) User-Agent: Pan/0.135 (Tomorrow I'll Wake Up and Scald Myself with Tea; GIT 30dc37b master) Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:12457 On Mon, 27 Feb 2012 05:20:48 +0000, Novice wrote: > I've really struggled with this. I have things set up a certain way now > but I'm constantly second-guessing myself and wondering if its the best > way to do things. > In that case, leave the package structure as it is unless you find problems with it. In fact I'd go so far as to say don't subdivide it into separate packages unless there's a really good reason for doing so. Once you've written a few programs, particularly if most of the classes in them require access to at least one of your common classes it becomes a real pain to repartition them between packages because doing so will cost significant effort to go through all your application classes and adjusting their 'import' statements. Most common classes tend to be quite small and you probably won't have all that many of them: my collection has evolved over the last 10 years and stand at 21 classes which contain 5800 lines of source including the Javadocs documentation comments, so the collection would have to grow by at least 50% before I'd consider splitting up that package. This number of classes hasn't changed for a while now, though some classes may gain a method or two as I find extra things I need them to do. For example my logging class has methods corresponding to 'info' and 'error' logging levels but there is no method equivalent to a 'warning' logging level. However, it is something I may need some day because calling error() causes the program to stop after dumping the circular trace buffer (if its enabled) but there is currently no way of dumping the buffer and letting the run continue. This is something a warn() method might do if I find a need for it. > For instance, I've got some utilities classes and I put them altogether > in a single package. But they are a mix of very different kinds of > utilities. Some deal with String manipulation, some with dates, some > with databases, etc. etc. Sometimes I wonder if I should take utilities > that deal with dates and group them with lookup classes that deal with > dates rather than group them on the basis of them being a utility or > lookup. After all "utility" is not something I could easily define in a > satisfying way and "lookup" is similarly unsatisfying. > So are mine, which range from my logging class to a pair of classes that handle the client and server ends of a message oriented socket connection via a command line parsing class and a class for calculating and checking numeric identifiers that use Luhn check digits. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |