Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: Novice Newsgroups: comp.lang.java.programmer Subject: Re: Aspect questions? Date: Mon, 27 Feb 2012 05:20:48 +0000 (UTC) Organization: Your Company Lines: 44 Message-ID: References: <4f4a6b1d$0$290$14726298@news.sunsite.dk> NNTP-Posting-Host: Dmxgbnvd+eoRDUV2lwYf7Q.user.speranza.aioe.org X-Complaints-To: abuse@aioe.org User-Agent: Xnews/5.04.25 X-Antivirus-Status: Clean X-Notice: Filtered by postfilter v. 0.8.2 X-Antivirus: avast! (VPS 120226-4, 2012-02-26), Outbound message Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:12417 Martin Gregorie wrote in news:jieg2n$beo$1@localhost.localdomain: > On Sun, 26 Feb 2012 21:08:49 +0000, Novice wrote: > >> So, with respect to my common classes, should they all be in one big >> package, like com.novice.common? Or is it better to group them on >> some basis so that different types of common modules are in their own >> packages? If grouping them is a good idea, what's the best way to >> group them? >> > I'd say generally yes, unless you see a definite reason to put another > (set of) class(es) in a separate package. Example: > > My common set forms the org.gregorie.environ package because I regard > these as setting an environment for the stuff I write. However, I also > do a bit of image manipulation and found I was writing repetitive > common code in this area, so that got refactored as classes in the > org.gregorie.image package. And so forth.... > > Any time you find this approach puts a class where you don't expect to > find it, consider changing your package structure. Its helpful if your > 'common' package only contains classes that are likely to be useful > for any program you write (e.g logging and command line parsing) and > that your other packages contain classes that are often used together. > 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. 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. Thanks for sharing your views on this, Martin! -- Novice