Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #12296 > unrolled thread
| Started by | Novice <novice@example..com> |
|---|---|
| First post | 2012-02-24 20:10 +0000 |
| Last post | 2012-02-25 00:22 +0000 |
| Articles | 20 on this page of 167 — 14 participants |
Back to article view | Back to comp.lang.java.programmer
Aspect questions? Novice <novice@example..com> - 2012-02-24 20:10 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-24 13:05 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-25 05:47 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-24 23:40 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-25 17:02 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-25 12:08 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-25 22:12 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-25 14:27 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-25 23:29 +0000
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-25 18:33 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-26 14:38 +0000
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 10:49 -0500
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 10:53 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-26 18:17 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-25 16:01 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-26 17:22 +0000
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 12:25 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-26 21:08 +0000
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 18:33 -0500
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 17:05 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 20:18 -0500
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 21:29 -0800
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-27 05:44 -0400
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-27 21:37 -0500
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-28 00:04 -0800
Re: Aspect questions? Patricia Shanahan <pats@acm.org> - 2012-02-28 01:39 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-29 14:54 +0000
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-28 17:24 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 04:53 +0000
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-02 17:08 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 05:12 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 21:38 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 17:27 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-27 12:22 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 22:50 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-27 17:24 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-29 15:00 +0000
Re: Aspect questions? Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-02-29 09:14 -0800
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-29 09:55 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-29 21:31 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-29 23:06 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-03-02 04:33 +0000
Re: Aspect questions? Novice <novice@example..com> - 2012-03-04 23:00 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-03-04 17:07 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-03-05 15:33 +0000
JavaDoc linking (Was: Aspect questions?) Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-03-05 08:38 -0800
Re: JavaDoc linking (Was: Aspect questions?) Novice <novice@example..com> - 2012-03-05 17:40 +0000
Re: JavaDoc linking (Was: Aspect questions?) Patricia Shanahan <pats@acm.org> - 2012-03-05 21:25 -0800
Re: JavaDoc linking (Was: Aspect questions?) Arne Vajhøj <arne@vajhoej.dk> - 2012-03-06 17:23 -0500
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-03-05 23:45 -0800
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-06 06:03 -0400
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-03-06 21:05 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-02 17:11 -0500
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-02 17:09 -0500
Re: Aspect questions? Martin Gregorie <martin@address-in-sig.invalid> - 2012-02-26 23:43 +0000
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 05:20 +0000
Re: Aspect questions? Patricia Shanahan <pats@acm.org> - 2012-02-26 21:32 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 17:36 +0000
Re: Aspect questions? Jeff Higgins <jeff@invalid.invalid> - 2012-02-27 13:18 -0500
Re: Aspect questions? Jeff Higgins <jeff@invalid.invalid> - 2012-02-27 14:05 -0500
Re: Aspect questions? Jeff Higgins <jeff@invalid.invalid> - 2012-02-27 14:33 -0500
Re: Aspect questions? Jeff Higgins <jeff@invalid.invalid> - 2012-02-27 14:53 -0500
Re: Aspect questions? Jeff Higgins <jeff@invalid.invalid> - 2012-02-27 15:16 -0500
Re: Aspect questions? Jeff Higgins <jeff@invalid.invalid> - 2012-02-27 17:57 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 22:59 +0000
Re: Aspect questions? Jeff Higgins <jeff@invalid.invalid> - 2012-02-28 05:50 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-29 15:03 +0000
Re: Aspect questions? Patricia Shanahan <pats@acm.org> - 2012-02-27 13:17 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 22:55 +0000
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-27 05:58 -0400
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 18:14 +0000
Re: Aspect questions? Martin Gregorie <martin@address-in-sig.invalid> - 2012-02-28 00:12 +0000
Re: Aspect questions? Novice <novice@example..com> - 2012-02-28 02:04 +0000
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-27 21:22 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-29 15:11 +0000
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-02 17:14 -0500
Re: Aspect questions? Martin Gregorie <martin@address-in-sig.invalid> - 2012-02-28 23:09 +0000
Re: Aspect questions? Novice <novice@example..com> - 2012-02-29 15:25 +0000
Re: Aspect questions? Martin Gregorie <martin@address-in-sig.invalid> - 2012-03-01 00:22 +0000
Re: Aspect questions? Novice <novice@example..com> - 2012-03-01 01:44 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-29 23:24 -0800
Re: Aspect questions? Martin Gregorie <martin@address-in-sig.invalid> - 2012-03-01 21:19 +0000
Re: Aspect questions? Novice <novice@example..com> - 2012-03-02 01:52 +0000
Re: Aspect questions? Martin Gregorie <martin@address-in-sig.invalid> - 2012-03-03 01:39 +0000
Re: Aspect questions? Novice <novice@example..com> - 2012-03-05 15:38 +0000
Re: Aspect questions? Martin Gregorie <martin@address-in-sig.invalid> - 2012-03-05 22:50 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-03-05 23:46 -0800
Re: Aspect questions? Patricia Shanahan <pats@acm.org> - 2012-03-06 08:14 -0800
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-03-06 21:23 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-08 20:10 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-03-02 01:49 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-03-01 22:38 -0800
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-02 06:05 -0400
Re: Aspect questions? Novice <novice@example..com> - 2012-03-02 14:25 +0000
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-03-02 18:10 -0400
Re: Aspect questions? Novice <novice@example..com> - 2012-03-02 14:12 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-03-02 08:57 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-03-05 15:57 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-03-05 23:48 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-03-07 20:33 +0000
Re: Aspect questions? Lew <lewbloch@gmail.com> - 2012-03-07 13:09 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-02 17:20 -0500
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-03-02 14:28 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-02 17:16 -0500
Re: Aspect questions? markspace <-@.> - 2012-02-26 10:10 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-26 20:52 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 13:48 -0800
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 13:47 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 18:40 -0500
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 18:36 -0500
Re: Aspect questions? markspace <-@.> - 2012-02-26 16:04 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 19:38 -0500
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 17:09 -0800
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-26 20:08 -0400
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 19:43 -0500
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-27 22:03 -0400
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-27 21:18 -0500
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 13:43 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 01:11 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 21:49 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-27 18:37 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-27 12:28 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-28 00:55 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-27 17:37 -0800
Re: Aspect questions? Novice <novice@example..com> - 2012-02-29 15:57 +0000
Re: Aspect questions? Leif Roar Moldskred <leifm@dimnakorr.com> - 2012-02-28 03:21 -0600
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-28 09:19 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-27 21:12 -0500
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-28 05:59 -0400
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-28 17:27 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-29 16:07 +0000
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-03-02 17:26 -0500
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-25 18:22 -0500
Re: Aspect questions? markspace <-@.> - 2012-02-25 20:22 -0800
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-25 22:20 -0800
Re: Aspect questions? markspace <-@.> - 2012-02-26 00:04 -0800
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 00:21 -0800
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 00:33 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 10:43 -0500
Re: Aspect questions? Martin Gregorie <martin@address-in-sig.invalid> - 2012-02-26 11:18 +0000
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-26 11:04 -0400
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-26 10:22 -0400
Re: Aspect questions? Novice <novice@example..com> - 2012-02-26 21:04 +0000
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-26 14:01 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 18:46 -0500
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 09:50 -0500
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-26 10:38 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-26 20:49 +0000
Re: Aspect questions? jlp <jlp@jlp.com> - 2012-02-25 09:47 +0100
Re: Aspect questions? Novice <novice@example..com> - 2012-02-25 17:03 +0000
Re: Aspect questions? jlp <jlp@jlp.com> - 2012-02-25 20:02 +0100
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-25 10:20 -0400
Re: Aspect questions? markspace <-@.> - 2012-02-25 08:18 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-25 12:04 -0500
Re: Aspect questions? Novice <novice@example..com> - 2012-02-25 17:17 +0000
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-25 18:40 -0400
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-25 18:18 -0500
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-25 09:21 -0500
Re: Aspect questions? Roedy Green <see_website@mindprod.com.invalid> - 2012-02-25 14:35 -0800
Re: Aspect questions? markspace <-@.> - 2012-02-24 14:30 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-24 19:47 -0500
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-24 20:52 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-25 09:31 -0500
Re: Aspect questions? Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-02-25 11:05 -0400
Re: Aspect questions? Lew <noone@lewscanon.com> - 2012-02-25 12:20 -0800
Re: Aspect questions? Arne Vajhøj <arne@vajhoej.dk> - 2012-02-24 19:00 -0500
Re: Aspect questions? Tom Anderson <twic@urchin.earth.li> - 2012-02-25 00:22 +0000
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-02-26 20:18 -0500 |
| Message-ID | <4f4ad9ff$0$292$14726298@news.sunsite.dk> |
| In reply to | #12403 |
On 2/26/2012 8:05 PM, Lew wrote: > Arne Vajhøj wrote: >> Novice wrote: >> > I'm currently grouping mine on a more-or-less functional basis. If the >> > class is essentially just a table lookup or enum, then it goes in the >> > com.novice.common.lookups package. If it is a utility, it goes into >> > com.novice.common.utilities. And so forth. >> >> That is general question not specific to logging or AOP. >> >> You need a good structure of your classes and source code. >> >> A key factor in the decision between com.novice.common and >> com.novice.common.xxxx must be the number of classes. >> >> Do you have so many classes that it makes sense to split up? > > That threshold would be one. > > Every type should be in a package. Every type should be in its > appropriate package, irrespective of how many types (not just classes!) > you have. A model-view-presenter program could, and probably should, > have three packages with just the five or six types (including the three > concrete classes but not the test code, which would add more). Nobody is suggesting classes should not be in package. If there is a good package structure given by the design, then that should be used. But the question was about com.novice.common vs com.novice.common.lookups + com.novice.common.utilities. I would let the number of classes decide that one. And the critical number is bigger than one. Arne
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-02-26 21:29 -0800 |
| Message-ID | <jif4aq$tnp$1@news.albasani.net> |
| In reply to | #12406 |
Arne Vajhøj wrote: > Lew wrote: >> Arne Vajhøj wrote: >>> Novice wrote: >>> > I'm currently grouping mine on a more-or-less functional basis. If the >>> > class is essentially just a table lookup or enum, then it goes in the >>> > com.novice.common.lookups package. If it is a utility, it goes into >>> > com.novice.common.utilities. And so forth. >>> >>> That is general question not specific to logging or AOP. >>> >>> You need a good structure of your classes and source code. >>> >>> A key factor in the decision between com.novice.common and >>> com.novice.common.xxxx must be the number of classes. >>> >>> Do you have so many classes that it makes sense to split up? >> >> That threshold would be one. >> >> Every type should be in a package. Every type should be in its >> appropriate package, irrespective of how many types (not just classes!) >> you have. A model-view-presenter program could, and probably should, >> have three packages with just the five or six types (including the three >> concrete classes but not the test code, which would add more). > > Nobody is suggesting classes should not be in package. > > If there is a good package structure given by the design, then > that should be used. > > But the question was about com.novice.common vs > com.novice.common.lookups + com.novice.common.utilities. > > I would let the number of classes decide that one. > > And the critical number is bigger than one. I disagree, with respect for your position. Not that the number will be greater than one, but that it's a motivator for the distinctions. The difference between 'com.novice.common' and 'com.novice.common.lookups' and 'com.novice.common.utilities' should take no note of how many types (NOT just classes!) would go in each package, but whether those in the first are merely "common", those in the second are common to "lookups", and those in the third are common "utilities". If you have a hard time semantically distinguishing one package from another, then you shouldn't have more than one package. Regardless of the number of types in it. A package is a namespace, not some finite-sized bucket that holds some particular number range of items. Its purpose is to semantically group related types together. What determines co-residence in a package is semantic similarity, not quantity. -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
[toc] | [prev] | [next] | [standalone]
| From | Arved Sandstrom <asandstrom3minus1@eastlink.ca> |
|---|---|
| Date | 2012-02-27 05:44 -0400 |
| Message-ID | <0gI2r.11608$zA2.371@newsfe02.iad> |
| In reply to | #12419 |
On 12-02-27 01:29 AM, Lew wrote: > Arne Vajhøj wrote: >> Lew wrote: >>> Arne Vajhøj wrote: >>>> Novice wrote: >>>> > I'm currently grouping mine on a more-or-less functional basis. If >>>> the >>>> > class is essentially just a table lookup or enum, then it goes in the >>>> > com.novice.common.lookups package. If it is a utility, it goes into >>>> > com.novice.common.utilities. And so forth. >>>> >>>> That is general question not specific to logging or AOP. >>>> >>>> You need a good structure of your classes and source code. >>>> >>>> A key factor in the decision between com.novice.common and >>>> com.novice.common.xxxx must be the number of classes. >>>> >>>> Do you have so many classes that it makes sense to split up? >>> >>> That threshold would be one. >>> >>> Every type should be in a package. Every type should be in its >>> appropriate package, irrespective of how many types (not just classes!) >>> you have. A model-view-presenter program could, and probably should, >>> have three packages with just the five or six types (including the three >>> concrete classes but not the test code, which would add more). >> >> Nobody is suggesting classes should not be in package. >> >> If there is a good package structure given by the design, then >> that should be used. >> >> But the question was about com.novice.common vs >> com.novice.common.lookups + com.novice.common.utilities. >> >> I would let the number of classes decide that one. >> >> And the critical number is bigger than one. > > I disagree, with respect for your position. > > Not that the number will be greater than one, but that it's a motivator > for the distinctions. > > The difference between 'com.novice.common' and > 'com.novice.common.lookups' and 'com.novice.common.utilities' should > take no note of how many types (NOT just classes!) would go in each > package, but whether those in the first are merely "common", those in > the second are common to "lookups", and those in the third are common > "utilities". > > If you have a hard time semantically distinguishing one package from > another, then you shouldn't have more than one package. Regardless of > the number of types in it. > > A package is a namespace, not some finite-sized bucket that holds some > particular number range of items. Its purpose is to semantically group > related types together. What determines co-residence in a package is > semantic similarity, not quantity. > Agreed. It's hard not to agree, your position is that taken by all credible documentation on Java packages. AHS -- -- Gaiety is the most outstanding feature of the Soviet Union. Josef Stalin, November 1935
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-02-27 21:37 -0500 |
| Message-ID | <4f4c3df1$0$281$14726298@news.sunsite.dk> |
| In reply to | #12419 |
On 2/27/2012 12:29 AM, Lew wrote: > Arne Vajhøj wrote: >> Lew wrote: >>> Arne Vajhøj wrote: >>>> Novice wrote: >>>> > I'm currently grouping mine on a more-or-less functional basis. If >>>> the >>>> > class is essentially just a table lookup or enum, then it goes in the >>>> > com.novice.common.lookups package. If it is a utility, it goes into >>>> > com.novice.common.utilities. And so forth. >>>> >>>> That is general question not specific to logging or AOP. >>>> >>>> You need a good structure of your classes and source code. >>>> >>>> A key factor in the decision between com.novice.common and >>>> com.novice.common.xxxx must be the number of classes. >>>> >>>> Do you have so many classes that it makes sense to split up? >>> >>> That threshold would be one. >>> >>> Every type should be in a package. Every type should be in its >>> appropriate package, irrespective of how many types (not just classes!) >>> you have. A model-view-presenter program could, and probably should, >>> have three packages with just the five or six types (including the three >>> concrete classes but not the test code, which would add more). >> >> Nobody is suggesting classes should not be in package. >> >> If there is a good package structure given by the design, then >> that should be used. >> >> But the question was about com.novice.common vs >> com.novice.common.lookups + com.novice.common.utilities. >> >> I would let the number of classes decide that one. >> >> And the critical number is bigger than one. > > I disagree, with respect for your position. > > Not that the number will be greater than one, but that it's a motivator > for the distinctions. > > The difference between 'com.novice.common' and > 'com.novice.common.lookups' and 'com.novice.common.utilities' should > take no note of how many types (NOT just classes!) would go in each > package, but whether those in the first are merely "common", those in > the second are common to "lookups", and those in the third are common > "utilities". > > If you have a hard time semantically distinguishing one package from > another, then you shouldn't have more than one package. Regardless of > the number of types in it. > > A package is a namespace, not some finite-sized bucket that holds some > particular number range of items. Its purpose is to semantically group > related types together. What determines co-residence in a package is > semantic similarity, not quantity. Hmmm. I can not disagree that logical grouping is a driver for package structure. But I don't believe that there is a single possible logical grouping. Let us compare: 1) com.foobar 2) com.foobar.a com.foobar.b 3) com.foobar.a.x com.foobar.a.y com.foobar.b.z com.foobar.b.w 4) com.foobar.a.x.bla com.foobar.a.x.blabla com.foobar.a.y.zzz com.foobar.a.y.zzzzz com.foobar.b.z.one com.foobar.b.z.two com.foobar.b.w.lion com.foobar.b.w.tiger In all of these 4 options the classes can be logical grouped. The question is at what granularity do you want to split. Everything in one package is not good. One package per class is not good. But somewhere in between one need to pick a level of granularity. And packages was not invented for fun but to help the developer. So one should pick the level of granularity that makes it easiest to find things. According to this source: http://binstock.blogspot.com/2008/04/perfecting-oos-small-classes-and-short.html then Thougthworks has recommended "no more than 10 classes per package". That seems a bit on the low side for me. YMMV Arne
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-02-28 00:04 -0800 |
| Message-ID | <jii1q4$f45$1@news.albasani.net> |
| In reply to | #12474 |
Arne Vajhøj wrote: > Hmmm. > > I can not disagree that logical grouping is a driver for package > structure. > > But I don't believe that there is a single possible logical > grouping. I agree with you on this point. > Let us compare: > > 1) > > com.foobar > > 2) > > com.foobar.a > com.foobar.b > > 3) > > com.foobar.a.x > com.foobar.a.y > com.foobar.b.z > com.foobar.b.w > > 4) > > com.foobar.a.x.bla > com.foobar.a.x.blabla > com.foobar.a.y.zzz > com.foobar.a.y.zzzzz > com.foobar.b.z.one > com.foobar.b.z.two > com.foobar.b.w.lion > com.foobar.b.w.tiger > > In all of these 4 options the classes can be logical grouped. > > The question is at what granularity do you want to split. > > Everything in one package is not good. > > One package per class is not good. > > But somewhere in between one need to pick a level of > granularity. > > And packages was not invented for fun but to help the > developer. > > So one should pick the level of granularity that makes it > easiest to find things. > > According to this source: > > http://binstock.blogspot.com/2008/04/perfecting-oos-small-classes-and-short.html > then Thougthworks has recommended "no more than 10 classes per package". > > That seems a bit on the low side for me. > > YMMV You illustrate one way in which programming is a matter of art. Ultimately you do what makes the most sense to you at the time. This is where Patricia's advice to refactor willingly (but not willy-nilly, of course) takes the heat off having to have one right answer right away. “A good plan violently executed now is better than a perfect plan next week.” — General George S. Patton, Jr., U.S. Army (Gods! I hear this in George C. Scott's voice. I can't help it.) -- Lew No battle plan survives contact with the enemy.
[toc] | [prev] | [next] | [standalone]
| From | Patricia Shanahan <pats@acm.org> |
|---|---|
| Date | 2012-02-28 01:39 -0800 |
| Message-ID | <CaCdnXluDfclPdHSnZ2dnUVZ_gmdnZ2d@earthlink.com> |
| In reply to | #12480 |
On 2/28/2012 12:04 AM, Lew wrote: ... > You illustrate one way in which programming is a matter of art. ... When it does come down to an art, after applying whatever science I have available, I often resort to the "What is easiest to document?" test. For example, I like a method for which it is really easy to write a Javadoc comment, especially the first sentence. To apply this to a packaging issue, try to write the Javadoc description(s). If you find yourself, within one package, having to say a lot about some particular subset of the classes, consider making that subset a separate package. The subset has a lot of commonality or interaction. If you find yourself doing a lot of cross-referencing between package descriptions, or repeating a lot of material, you may have divided things up too much. Patricia
[toc] | [prev] | [next] | [standalone]
| From | Novice <novice@example..com> |
|---|---|
| Date | 2012-02-29 14:54 +0000 |
| Message-ID | <XnsA008651E562FFjpnasty@94.75.214.39> |
| In reply to | #12482 |
Patricia Shanahan <pats@acm.org> wrote in news:CaCdnXluDfclPdHSnZ2dnUVZ_gmdnZ2d@earthlink.com: > On 2/28/2012 12:04 AM, Lew wrote: > ... >> You illustrate one way in which programming is a matter of art. > ... > > When it does come down to an art, after applying whatever science I > have available, I often resort to the "What is easiest to document?" > test. For example, I like a method for which it is really easy to > write a Javadoc comment, especially the first sentence. > > To apply this to a packaging issue, try to write the Javadoc > description(s). > > If you find yourself, within one package, having to say a lot about > some particular subset of the classes, consider making that subset a > separate package. The subset has a lot of commonality or interaction. > > If you find yourself doing a lot of cross-referencing between package > descriptions, or repeating a lot of material, you may have divided > things up too much. > I like this approach. As someone who often starts with comments and then writes code, this appeals to me. -- Novice
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-02-28 17:24 -0500 |
| Message-ID | <4f4d5406$0$294$14726298@news.sunsite.dk> |
| In reply to | #12480 |
On 2/28/2012 3:04 AM, Lew wrote: > Arne Vajhøj wrote: >> Hmmm. >> >> I can not disagree that logical grouping is a driver for package >> structure. >> >> But I don't believe that there is a single possible logical >> grouping. > > I agree with you on this point. > >> Let us compare: >> >> 1) >> >> com.foobar >> >> 2) >> >> com.foobar.a >> com.foobar.b >> >> 3) >> >> com.foobar.a.x >> com.foobar.a.y >> com.foobar.b.z >> com.foobar.b.w >> >> 4) >> >> com.foobar.a.x.bla >> com.foobar.a.x.blabla >> com.foobar.a.y.zzz >> com.foobar.a.y.zzzzz >> com.foobar.b.z.one >> com.foobar.b.z.two >> com.foobar.b.w.lion >> com.foobar.b.w.tiger >> >> In all of these 4 options the classes can be logical grouped. >> >> The question is at what granularity do you want to split. >> >> Everything in one package is not good. >> >> One package per class is not good. >> >> But somewhere in between one need to pick a level of >> granularity. >> >> And packages was not invented for fun but to help the >> developer. >> >> So one should pick the level of granularity that makes it >> easiest to find things. >> >> According to this source: >> >> http://binstock.blogspot.com/2008/04/perfecting-oos-small-classes-and-short.html >> >> then Thougthworks has recommended "no more than 10 classes per package". >> >> That seems a bit on the low side for me. >> >> YMMV > > You illustrate one way in which programming is a matter of art. Or craftsmanship. Arne
[toc] | [prev] | [next] | [standalone]
| From | Novice <novice@example..com> |
|---|---|
| Date | 2012-02-27 04:53 +0000 |
| Message-ID | <XnsA00615EB6E9jpnasty@94.75.214.39> |
| In reply to | #12392 |
Arne Vajhøj <arne@vajhoej.dk> wrote in news:4f4ac151$0$291$14726298
@news.sunsite.dk:
> On 2/26/2012 4:08 PM, Novice wrote:
>> Arne Vajhøj<arne@vajhoej.dk> wrote in
>> news:4f4a6b1d$0$290$14726298@news.sunsite.dk:
>>> The standard is to use the full (with package) class name as
>>> the name of the logger.
>>>
>>> Because logger configuration is applied tree wise, then you can
>>> still configure at package level.
>>>
>>> If you used package name as logger name, then you could
>>> not configure by class.
>>>
>> Okay, fair enough. Hmm, I need to think through the implications of
>> that....
>>
>> 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'm currently grouping mine on a more-or-less functional basis. If
the
> > class is essentially just a table lookup or enum, then it goes in the
> > com.novice.common.lookups package. If it is a utility, it goes into
> > com.novice.common.utilities. And so forth.
>
> That is general question not specific to logging or AOP.
>
> You need a good structure of your classes and source code.
>
> A key factor in the decision between com.novice.common and
> com.novice.common.xxxx must be the number of classes.
>
> Do you have so many classes that it makes sense to split up?
>
>> Also, do you have any idea where to find the log records I am writing
>> when I use Logger.getLogger("test") in my play code? I've tried the
>> location stated in logging.properties and I've tried
>>
>> <User Application Data Folder>\Sun\Java\Deployment\log on Windows
>>
>> as suggested in
>> http://docs.oracle.com/javase/1.5.0/docs/guide/deployment/deployment-
>> guide/tracing_logging.html
>>
>> but I'm not finding it. There are files there but the days of the week
>> are NOT in them and that's what I wrote to my logger.
>
> It should write to the file specified in the properties file.
>
> May we see that?
>
It's not very different from the standard one. I've just tweaked it a
little bit. Here it is with the comments stripped out:
============================================================
handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler
.level=INFO
java.util.logging.FileHandler.pattern = %h/java%u.log
java.util.logging.FileHandler.limit = 50000
java.util.logging.FileHandler.count = 1
java.util.logging.FileHandler.formatter = java.util.logging.XMLFormatter
java.util.logging.ConsoleHandler.level = INFO
java.util.logging.ConsoleHandler.formatter =
java.util.logging.SimpleFormatter
x.y.level = SEVERE
x.y.z.level = WARNING
org.sscce.level = WARNING
org.sscce.baz3.level = INFO
=========================================================================
I don't think the last four lines are going to do anything since I don't
believe I have any packages with those names. I think those are just
examples that I created when I first looked at logging a few years ago.
The code that I'm executing is:
==================================================================
package test;
import java.util.logging.Level;
import java.util.logging.Logger;
public class TestLogging {
public static void main(String[] args) {
@SuppressWarnings("unused")
TestLogging test = new TestLogging();
}
public TestLogging() {
Logger logger = Logger.getLogger("test");
logger.logp(Level.INFO, "myClass", "myMethod", "Monday");
logger.logp(Level.INFO, "myClass", "myMethod", "Tuesday");
logger.logp(Level.INFO, "myClass", "myMethod", "Wednesday");
logger.logp(Level.INFO, "myClass", "myMethod", "Thursday");
logger.logp(Level.INFO, "myClass", "myMethod", "Friday");
logger.logp(Level.INFO, "myClass", "myMethod", "Saturday");
logger.logp(Level.INFO, "myClass", "myMethod", "Sunday");
}
}
===================================================================
I'm running Windows XP so I know that %h is C:\Documents and Settings
\Novice. There are five log files there, java0.log through java4.log, but
none of them contain the days of the week or any log record that contain
today's date. So those logs are not getting written to that path.
I'm not sure if I'm doing something that is keeping them from being
written at all or if they are being written to somewhere else in the file
system. I don't _think_ I am suppressing them and I don't know where else
to look for them. The logs aren't where the docs say they should be....
--
Novice
[toc] | [prev] | [next] | [standalone]
| From | Arne Vajhøj <arne@vajhoej.dk> |
|---|---|
| Date | 2012-03-02 17:08 -0500 |
| Message-ID | <4f5144da$0$286$14726298@news.sunsite.dk> |
| In reply to | #12415 |
On 2/26/2012 11:53 PM, Novice wrote:
> Arne Vajhøj<arne@vajhoej.dk> wrote in news:4f4ac151$0$291$14726298
> @news.sunsite.dk:
>
>> On 2/26/2012 4:08 PM, Novice wrote:
>>> Arne Vajhøj<arne@vajhoej.dk> wrote in
>>> news:4f4a6b1d$0$290$14726298@news.sunsite.dk:
>>>> The standard is to use the full (with package) class name as
>>>> the name of the logger.
>>>>
>>>> Because logger configuration is applied tree wise, then you can
>>>> still configure at package level.
>>>>
>>>> If you used package name as logger name, then you could
>>>> not configure by class.
>>>>
>>> Okay, fair enough. Hmm, I need to think through the implications of
>>> that....
>>>
>>> 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'm currently grouping mine on a more-or-less functional basis. If
> the
>>> class is essentially just a table lookup or enum, then it goes in the
>>> com.novice.common.lookups package. If it is a utility, it goes into
>>> com.novice.common.utilities. And so forth.
>>
>> That is general question not specific to logging or AOP.
>>
>> You need a good structure of your classes and source code.
>>
>> A key factor in the decision between com.novice.common and
>> com.novice.common.xxxx must be the number of classes.
>>
>> Do you have so many classes that it makes sense to split up?
>>
>>> Also, do you have any idea where to find the log records I am writing
>>> when I use Logger.getLogger("test") in my play code? I've tried the
>>> location stated in logging.properties and I've tried
>>>
>>> <User Application Data Folder>\Sun\Java\Deployment\log on Windows
>>>
>>> as suggested in
>>> http://docs.oracle.com/javase/1.5.0/docs/guide/deployment/deployment-
>>> guide/tracing_logging.html
>>>
>>> but I'm not finding it. There are files there but the days of the week
>>> are NOT in them and that's what I wrote to my logger.
>>
>> It should write to the file specified in the properties file.
>>
>> May we see that?
>>
>
> It's not very different from the standard one. I've just tweaked it a
> little bit. Here it is with the comments stripped out:
>
> ============================================================
> handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler
>
> .level=INFO
>
> java.util.logging.FileHandler.pattern = %h/java%u.log
> java.util.logging.FileHandler.limit = 50000
> java.util.logging.FileHandler.count = 1
> java.util.logging.FileHandler.formatter = java.util.logging.XMLFormatter
> java.util.logging.ConsoleHandler.level = INFO
> java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
> I'm running Windows XP so I know that %h is C:\Documents and Settings
> \Novice. There are five log files there, java0.log through java4.log, but
> none of them contain the days of the week or any log record that contain
> today's date. So those logs are not getting written to that path.
If you delete those files - do they show up again?
Arne
[toc] | [prev] | [next] | [standalone]
| From | Novice <novice@example..com> |
|---|---|
| Date | 2012-02-27 05:12 +0000 |
| Message-ID | <XnsA006353B5A95jpnasty@94.75.214.39> |
| In reply to | #12392 |
Arne Vajhøj <arne@vajhoej.dk> wrote in news:4f4ac151$0$291$14726298 @news.sunsite.dk: [snip] I forgot to answer this part of your post in my other reply. > > > > I'm currently grouping mine on a more-or-less functional basis. If the > > class is essentially just a table lookup or enum, then it goes in the > > com.novice.common.lookups package. If it is a utility, it goes into > > com.novice.common.utilities. And so forth. > > That is general question not specific to logging or AOP. > You're absolutely right. This is a bit of a sidetrack. I think I need to be sure I've structured my packages correctly in order to do a good job with this. > You need a good structure of your classes and source code. > Agreed. I'm trying to figure out the best approach. > A key factor in the decision between com.novice.common and > com.novice.common.xxxx must be the number of classes. > > Do you have so many classes that it makes sense to split up? > I'm not sure what "so many" means in this case ;-) I actually split my Common project the other day into two parts. I left only the code that I consider polished and (more or less) correct in Common and moved all the stuff that is still crude and needs improving to a new project called Common Candidate. The latter is far bigger! But Common itself contains 9 classes in package com.novice.common, 8 classes in package com.novice.common.lookups, 3 classes in com.novice.common.menus, 2 classes in com.novice.common.prefs, and 18 classes in com.novice.common.utilities. The resource bundles for each package are in separate packages that have Resources as the last qualifier, e.g. com.novice.common.utilities.Resources. I have the impression, perhaps mistaken, that resource bundles are supposed to be in different packages than the classes they support.I don't remember where I got that; I think it was a newsgroup post a few years ago but it could have been in one of the online magazines.... I have no idea if this is a reasonable approach. Maybe this should all be simplified so that all of those common classes and enums and resource bundles are in one package together. Or just two, one for classes and enums and the other for resource bundles. Everything in the Common project is something I use regularly in various projects or that I expect to use regularly. The Commons Candidate project has quite a bit more code than the Common project and is organized the same way with the same package names (and maybe an additional package or two where none of the members are ready for the Common project.) Some of the members of that project don't belong there because they are just snippets that I've downloaded for learning purposes or simple sandbox code where I'm trying something out. It needs to be moved elsewhere but that's not a priority for me right now. But the bulk of it has the potential to go to the Common project as something I'd use regularly. I'd like to start the process of doing things correctly with my current project and Common so anything you can tell me about organizing things would be appreciated. [snip] -- Novice
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-02-26 21:38 -0800 |
| Message-ID | <jif4sl$uon$1@news.albasani.net> |
| In reply to | #12416 |
Novice wrote: > I actually split my Common project the other day into two parts. I left > only the code that I consider polished and (more or less) correct in > Common and moved all the stuff that is still crude and needs improving to > a new project called Common Candidate. The latter is far bigger! > > But Common itself contains 9 classes in package com.novice.common, 8 > classes in package com.novice.common.lookups, 3 classes in > com.novice.common.menus, 2 classes in com.novice.common.prefs, and 18 > classes in com.novice.common.utilities. The number isn't what's important. It's how related the types (not just classes - you had better gosh-darned well have some interfaces in there!) It's the relatedness of the types. Types in the same package are closely related to each other. Those in different packages aren't. It's how related the types should be that determines the designer's choice of which package holds them. > The resource bundles for each package are in separate packages that have > Resources as the last qualifier, e.g. > com.novice.common.utilities.Resources. I have the impression, perhaps The usual (but not universal) convention is to name packages in all lower-case with no underscores. That name looks like 'Resources' should be a type, not a package name element. Putting resources in a different package from the consuming type makes it harder for the consumer to locate the resource, but it's not really wrong. > mistaken, that resource bundles are supposed to be in different packages > than the classes they support.I don't remember where I got that; I think > it was a newsgroup post a few years ago but it could have been in one of > the online magazines.... There's no real rule like that. You sure have a lot of vague, half- (not to say mis-) remembered rules you try to live by without understanding. Why don't you abandon all these rules and substitute thought about the consequences of choices, and whether those consequences suit your purpose? > I have no idea if this is a reasonable approach. Maybe this should all be You tell us. What are the consequences? Do you want those consequences? I can tell you one. If you use something like 'Class#getResource[asStream]()' you have to be more careful specifying the resource location with a resource in a different package from the class represented by the instance making the call. Not that that is bad, but it's a consequence. > simplified so that all of those common classes and enums and resource > bundles are in one package together. Or just two, one for classes and > enums and the other for resource bundles. Why do you call that "simplified"? That seems like a recipe for an unholy mess. Again, use the degree of relatedness to determine package co-residence. > Everything in the Common project is something I use regularly in various > projects or that I expect to use regularly. > > The Commons Candidate project has quite a bit more code than the Common > project and is organized the same way with the same package names (and > maybe an additional package or two where none of the members are ready > for the Common project.) Some of the members of that project don't belong > there because they are just snippets that I've downloaded for learning > purposes or simple sandbox code where I'm trying something out. It needs > to be moved elsewhere but that's not a priority for me right now. But the > bulk of it has the potential to go to the Common project as something I'd > use regularly. > > I'd like to start the process of doing things correctly with my current > project and Common so anything you can tell me about organizing things > would be appreciated. Did you read the tutorial link? -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
[toc] | [prev] | [next] | [standalone]
| From | Novice <novice@example..com> |
|---|---|
| Date | 2012-02-27 17:27 +0000 |
| Message-ID | <XnsA0067FCB0ABB7jpnasty@94.75.214.39> |
| In reply to | #12421 |
Lew <noone@lewscanon.com> wrote in news:jif4sl$uon$1@news.albasani.net: > Novice wrote: >> I actually split my Common project the other day into two parts. I >> left only the code that I consider polished and (more or less) >> correct in Common and moved all the stuff that is still crude and >> needs improving to a new project called Common Candidate. The latter >> is far bigger! >> >> But Common itself contains 9 classes in package com.novice.common, 8 >> classes in package com.novice.common.lookups, 3 classes in >> com.novice.common.menus, 2 classes in com.novice.common.prefs, and 18 >> classes in com.novice.common.utilities. > > The number isn't what's important. It's how related the types (not > just classes - you had better gosh-darned well have some interfaces in > there!) It's the relatedness of the types. Types in the same package > are closely related to each other. Those in different packages aren't. > It's how related the types should be that determines the designer's > choice of which package holds them. > Then I'm definitely bundling things incorrectly. The classes in my package are not typically closely related. As for interfaces, I do have some but now you've got me worried that I'm not using as many as I should. It's entirely possible that I write classes when I should be writing interfaces. Another beginner mistake brought on by the helter- skelter way I've learned Java.... I really need to review some of the fundamentals! But then I suppose we've already established that over the last few days.... >> The resource bundles for each package are in separate packages that >> have Resources as the last qualifier, e.g. >> com.novice.common.utilities.Resources. I have the impression, perhaps > > The usual (but not universal) convention is to name packages in all > lower-case with no underscores. That name looks like 'Resources' > should be a type, not a package name element. > I'd like to clarify what you mean by "type". (And I'm not saying this is a usage that you invented; I have seen it in other places.) I tend to read "type" as a synonym for "class" but I'm getting the impression now that you mean classes, enums, interfaces, etc. In other words, classes, enums, and interfaces are _all_ types in the sense that you are using the word. Is that right? I've noticed that the Java Search in Eclipse lets you search for types, packages, fields, methods and constructors but doesn't give you an option for class (or enum). But if I select Type and look for a specific class or enum or interface, it will find them. > Putting resources in a different package from the consuming type makes > it harder for the consumer to locate the resource, but it's not really > wrong. > I have no objection to putting the resources in the same packages as the classes they are supporting. As I said, I was just doing something that I saw recommended somewhere. And I may just have misinterpreted the intent of that suggestion as I have other things. If there's no good reason to keep the resources separate, I'm inclined to move them into the packages of the classes they support. >> mistaken, that resource bundles are supposed to be in different >> packages than the classes they support.I don't remember where I got >> that; I think it was a newsgroup post a few years ago but it could >> have been in one of the online magazines.... > > There's no real rule like that. You sure have a lot of vague, half- > (not to say mis-) remembered rules you try to live by without > understanding. > > Why don't you abandon all these rules and substitute thought about the > consequences of choices, and whether those consequences suit your > purpose? > That's an excellent suggestion and one I've been thinking of for some time! It's just a matter of isolating which things need to be abandoned. I don't want to throw out the baby with the bathwater.... >> I have no idea if this is a reasonable approach. Maybe this should >> all be > > You tell us. What are the consequences? Do you want those > consequences? > > I can tell you one. If you use something like > 'Class#getResource[asStream]()' you have to be more careful specifying > the resource location with a resource in a different package from the > class represented by the instance making the call. Not that that is > bad, but it's a consequence. > That's hardly the end of the world. I think I can cope with that. I wish I could recall where I got the suggestion in the first place and why it was seen as a good thing to do but I just don't recall. >> simplified so that all of those common classes and enums and resource >> bundles are in one package together. Or just two, one for classes and >> enums and the other for resource bundles. > > Why do you call that "simplified"? That seems like a recipe for an > unholy mess. > > Again, use the degree of relatedness to determine package > co-residence. > Makes sense to me, now that you say it. So I'm going to put things that are frequently used together and not let other considerations enter into it because they are unimportant. And resources are going to go in the same package as their classes. There! I've just moved the stuff from the "...Resources" packages to the packages that had the corresponding classes and deleted the empty Resources packages. As for the other packages in Common and CommonCandidate, I think the vast majority are very soon going to be sitting in the same package, com.novice.common since they are unrelated except that they are commonly used. The vast majority are used independently, not together, so they aren't really related. The few that are both related and common will get their own packages. There! I've just put all the code in the Common project into one big package. A small handful of types will get moved again into separate packages as I figure out which ones really need that treatment. >> Everything in the Common project is something I use regularly in >> various projects or that I expect to use regularly. >> >> The Commons Candidate project has quite a bit more code than the >> Common project and is organized the same way with the same package >> names (and maybe an additional package or two where none of the >> members are ready for the Common project.) Some of the members of >> that project don't belong there because they are just snippets that >> I've downloaded for learning purposes or simple sandbox code where >> I'm trying something out. It needs to be moved elsewhere but that's >> not a priority for me right now. But the bulk of it has the potential >> to go to the Common project as something I'd use regularly. >> >> I'd like to start the process of doing things correctly with my >> current project and Common so anything you can tell me about >> organizing things would be appreciated. > > Did you read the tutorial link? The one about packages? Yes. But I found it very vague. I didn't know if the considerations I had were reasonable factors in grouping things together or not. But if the key thing is relatedness and the number of members in a package is irrelevant and I should not group all enums or data classes into separate packages to recognize those similarities, then things get a lot clearer. Since the various types are almost entirely unrelated, the only reasonable thing to do is put them all in the same package. I suppose I could put each type in its own distinct package to emphasize it's distinctiveness from the others but that just seems dumb. -- Novice
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-02-27 12:22 -0800 |
| Message-ID | <jigom7$e1d$1@news.albasani.net> |
| In reply to | #12436 |
Novice wrote: > Lew wrote: >> The number isn't what's important. It's how related the types (not >> just classes - you had better gosh-darned well have some interfaces in >> there!) It's the relatedness of the types. Types in the same package >> are closely related to each other. Those in different packages aren't. >> It's how related the types should be that determines the designer's >> choice of which package holds them. >> > Then I'm definitely bundling things incorrectly. The classes in my > package are not typically closely related. As for interfaces, I do have If you have a package called "miscellaneous", the types are related by virtue of having no relationship to each other or anything else. "Related" is up to you to define. > some but now you've got me worried that I'm not using as many as I > should. It's entirely possible that I write classes when I should be Relax. > writing interfaces. Another beginner mistake brought on by the helter- > skelter way I've learned Java.... Relax. Interfaces are a promise. Classes are a way to keep that promise. It's entirely possible to write a program without creating any new interfaces. It's likely that any program you write will have some classes that do not implement new custom interfaces. Interfaces are a tool. You're panicking as a carpenter would were they freaking out that they weren't using their ratchet wrench often enough. To which I can only say, WTF? Why don't you just learn what interfaces are and stop panicking? > I really need to review some of the fundamentals! But then I suppose > we've already established that over the last few days.... Interfaces are to specify and be clear what's supposed to happen. Consider the Java standard 'java.util.List<E>' interface. It promises certain methods, such as 'add(E element)', for example. It does not promise that the underlying implementation will have an array, or fast insertion, or any other particular about how it does the 'add()', only that it can and will do it. Implementations of 'List<E>' include 'ArrayList<E>' and 'TreeList<E>'. Why don't you take a break and read the Javadocs for these three types? >>> The resource bundles for each package are in separate packages that >>> have Resources as the last qualifier, e.g. >>> com.novice.common.utilities.Resources. I have the impression, perhaps >> >> The usual (but not universal) convention is to name packages in all >> lower-case with no underscores. That name looks like 'Resources' >> should be a type, not a package name element. >> > I'd like to clarify what you mean by "type". (And I'm not saying this is > a usage that you invented; I have seen it in other places.) I tend to > read "type" as a synonym for "class" but I'm getting the impression now > that you mean classes, enums, interfaces, etc. In other words, classes, > enums, and interfaces are _all_ types in the sense that you are using the > word. Is that right? First of all, enums *are* classes! Second, for God's sake, man! Use a search engine once in a while! <http://lmgtfy.com/?q=what+is+a+type+in+computer+programming> Types are anything that classify a variable to the compiler, so yes, interfaces and classes. Also primitive types. Also arrays. Any classification of a variable. This is a very fundamental concept to computer programming, and present in every computer language in one way or another. "Type" is right up there with "operator" and "variable", "literal", "integer". I really wish you'd read the tutorial: <http://docs.oracle.com/javase/tutorial/java/nutsandbolts/index.html> "... basic data types (primitive types, character strings, and arrays), ..." <http://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html> "The Java programming language is statically-typed, which means that all variables must first be declared before they can be used. This involves stating the variable's type and name, ..." > I've noticed that the Java Search in Eclipse lets you search for types, > packages, fields, methods and constructors but doesn't give you an option > for class (or enum). But if I select Type and look for a specific class > or enum or interface, it will find them. Because those are types, so your reasoning is sound to this degree. >> Putting resources in a different package from the consuming type makes >> it harder for the consumer to locate the resource, but it's not really >> wrong. >> > I have no objection to putting the resources in the same packages as the > classes they are supporting. As I said, I was just doing something that I > saw recommended somewhere. And I may just have misinterpreted the intent > of that suggestion as I have other things. If there's no good reason to > keep the resources separate, I'm inclined to move them into the packages > of the classes they support. If you saw a recommendation somewhere to jump off a bridge, would you "just do it"? >>> mistaken, that resource bundles are supposed to be in different >>> packages than the classes they support.I don't remember where I got >>> that; I think it was a newsgroup post a few years ago but it could >>> have been in one of the online magazines.... >> >> There's no real rule like that. You sure have a lot of vague, half- >> (not to say mis-) remembered rules you try to live by without >> understanding. >> >> Why don't you abandon all these rules and substitute thought about the >> consequences of choices, and whether those consequences suit your >> purpose? >> > That's an excellent suggestion and one I've been thinking of for some > time! It's just a matter of isolating which things need to be abandoned. > I don't want to throw out the baby with the bathwater.... Abandon all the rules. Well, abandon all the rules you don't completely understand. Do what makes your desired outcome happen. Rules exist to make that easier. Follow whatever rules make your desired outcome happen with the least hassle to your customer. >>> I have no idea if this is a reasonable approach. Maybe this should >>> all be >> >> You tell us. What are the consequences? Do you want those >> consequences? >> >> I can tell you one. If you use something like >> 'Class#getResource[asStream]()' you have to be more careful specifying >> the resource location with a resource in a different package from the >> class represented by the instance making the call. Not that that is >> bad, but it's a consequence. >> > That's hardly the end of the world. I think I can cope with that. I wish > I could recall where I got the suggestion in the first place and why it > was seen as a good thing to do but I just don't recall. Because you can't recall the source or rationale for the rule, don't understand the rule, and perhaps don't even recall the rule accurately, you should not follow that rule. The policy of following ritual mumbo-jumbo from half-remembered sources in a way not intended by the original promulgator of that ritual mumbo-jumbo is that old, surefire path to failure known as "cargo-cult programming". ... > As for the other packages in Common and CommonCandidate, I think the vast > majority are very soon going to be sitting in the same package, > com.novice.common since they are unrelated except that they are commonly > used. The vast majority are used independently, not together, so they > aren't really related. The few that are both related and common will get > their own packages. There! I've just put all the code in the Common > project into one big package. A small handful of types will get moved > again into separate packages as I figure out which ones really need that > treatment. That sounds valid. -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
[toc] | [prev] | [next] | [standalone]
| From | Novice <novice@example..com> |
|---|---|
| Date | 2012-02-27 22:50 +0000 |
| Message-ID | <XnsA006B6A5992DDjpnasty@94.75.214.39> |
| In reply to | #12446 |
Lew <noone@lewscanon.com> wrote in news:jigom7$e1d$1@news.albasani.net: > Novice wrote: >> Lew wrote: >>> The number isn't what's important. It's how related the types (not >>> just classes - you had better gosh-darned well have some interfaces >>> in there!) It's the relatedness of the types. Types in the same >>> package are closely related to each other. Those in different >>> packages aren't. It's how related the types should be that >>> determines the designer's choice of which package holds them. >>> >> Then I'm definitely bundling things incorrectly. The classes in my >> package are not typically closely related. As for interfaces, I do >> have > > If you have a package called "miscellaneous", the types are related by > virtue of having no relationship to each other or anything else. > "Related" is up to you to define. > >> some but now you've got me worried that I'm not using as many as I >> should. It's entirely possible that I write classes when I should be > > Relax. > >> writing interfaces. Another beginner mistake brought on by the >> helter- skelter way I've learned Java.... > > Relax. > > Interfaces are a promise. Classes are a way to keep that promise. > > It's entirely possible to write a program without creating any new > interfaces. > > It's likely that any program you write will have some classes that do > not implement new custom interfaces. > > Interfaces are a tool. You're panicking as a carpenter would were they > freaking out that they weren't using their ratchet wrench often > enough. > > To which I can only say, WTF? > > Why don't you just learn what interfaces are and stop panicking? > I wasn't panicking; I was just wondering if I needed to add that to my "to do" list of things to re-learn. Which is basically what you're suggesting I do. :-) >> I really need to review some of the fundamentals! But then I suppose >> we've already established that over the last few days.... > > Interfaces are to specify and be clear what's supposed to happen. > Consider the Java standard 'java.util.List<E>' interface. It promises > certain methods, such as 'add(E element)', for example. It does not > promise that the underlying implementation will have an array, or fast > insertion, or any other particular about how it does the 'add()', only > that it can and will do it. > > Implementations of 'List<E>' include 'ArrayList<E>' and 'TreeList<E>'. > Why don't you take a break and read the Javadocs for these three > types? > I've got interface List<E> and class ArrayList<E> (which implements List <E> among other interfaces) but I don't have TreeList<E>. I mostly still use the Java 1.6 API but even the Java 1.7 API doesn't have a TreeList. What did you mean to say? And what do you want me to learn? I'm guessing you want me to see how a class makes use of an Interface but possibly you have something more specific in mind? >>>> The resource bundles for each package are in separate packages that >>>> have Resources as the last qualifier, e.g. >>>> com.novice.common.utilities.Resources. I have the impression, >>>> perhaps >>> >>> The usual (but not universal) convention is to name packages in all >>> lower-case with no underscores. That name looks like 'Resources' >>> should be a type, not a package name element. >>> >> I'd like to clarify what you mean by "type". (And I'm not saying this >> is a usage that you invented; I have seen it in other places.) I tend >> to read "type" as a synonym for "class" but I'm getting the >> impression now that you mean classes, enums, interfaces, etc. In >> other words, classes, enums, and interfaces are _all_ types in the >> sense that you are using the word. Is that right? > > First of all, enums *are* classes! > Okay, I had forgotten that. Eclipse has a separate dialog for creating an enum so it makes it feel as if it ISN'T a class but a whole different animal. > Second, for God's sake, man! Use a search engine once in a while! > <http://lmgtfy.com/?q=what+is+a+type+in+computer+programming> > Sorry. I'm not as lazy as you think. It's just that I feel like we're having a conversation in (almost) real time. I wouldn't tell someone to go off to look something up in a dictionary in a real time conversation; I'd just ask them what they meant. It's now clear to me that you don't view it that way; more like a student coming to a lesson and being given homework. Okay, I can do that too. > Types are anything that classify a variable to the compiler, so yes, > interfaces and classes. Also primitive types. Also arrays. > > Any classification of a variable. This is a very fundamental concept > to computer programming, and present in every computer language in one > way or another. "Type" is right up there with "operator" and > "variable", "literal", "integer". > Java is something like my 10th programming language and I don't remember seeing 'type' as standard terminology in any of the others. Forgive my ignorance.... > I really wish you'd read the tutorial: > <http://docs.oracle.com/javase/tutorial/java/nutsandbolts/index.html> > "... basic data types (primitive types, character strings, and > arrays), ..." > > <http://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.htm > l> "The Java programming language is statically-typed, which means > that all variables must first be declared before they can be used. > This involves stating the variable's type and name, ..." > You've made your point, Again, sorry. >> I've noticed that the Java Search in Eclipse lets you search for >> types, packages, fields, methods and constructors but doesn't give >> you an option for class (or enum). But if I select Type and look for >> a specific class or enum or interface, it will find them. > > Because those are types, so your reasoning is sound to this degree. > >>> Putting resources in a different package from the consuming type >>> makes it harder for the consumer to locate the resource, but it's >>> not really wrong. >>> >> I have no objection to putting the resources in the same packages as >> the classes they are supporting. As I said, I was just doing >> something that I saw recommended somewhere. And I may just have >> misinterpreted the intent of that suggestion as I have other things. >> If there's no good reason to keep the resources separate, I'm >> inclined to move them into the packages of the classes they support. > > If you saw a recommendation somewhere to jump off a bridge, would you > "just do it"? > No, of course not. But if you're suggesting that I'm a little too quick to take advice without thinking through just whether it is the right thing to do, then yes, I'm probably guilty of that sometimes. I will work on that. >>>> mistaken, that resource bundles are supposed to be in different >>>> packages than the classes they support.I don't remember where I got >>>> that; I think it was a newsgroup post a few years ago but it could >>>> have been in one of the online magazines.... >>> >>> There's no real rule like that. You sure have a lot of vague, half- >>> (not to say mis-) remembered rules you try to live by without >>> understanding. >>> >>> Why don't you abandon all these rules and substitute thought about >>> the consequences of choices, and whether those consequences suit >>> your purpose? >>> >> That's an excellent suggestion and one I've been thinking of for some >> time! It's just a matter of isolating which things need to be >> abandoned. I don't want to throw out the baby with the bathwater.... > > Abandon all the rules. Well, abandon all the rules you don't > completely understand. > > Do what makes your desired outcome happen. Rules exist to make that > easier. Follow whatever rules make your desired outcome happen with > the least hassle to your customer. > >>>> I have no idea if this is a reasonable approach. Maybe this should >>>> all be >>> >>> You tell us. What are the consequences? Do you want those >>> consequences? >>> >>> I can tell you one. If you use something like >>> 'Class#getResource[asStream]()' you have to be more careful >>> specifying the resource location with a resource in a different >>> package from the class represented by the instance making the call. >>> Not that that is bad, but it's a consequence. >>> >> That's hardly the end of the world. I think I can cope with that. I >> wish I could recall where I got the suggestion in the first place and >> why it was seen as a good thing to do but I just don't recall. > > Because you can't recall the source or rationale for the rule, don't > understand the rule, and perhaps don't even recall the rule > accurately, you should not follow that rule. The policy of following > ritual mumbo-jumbo from half-remembered sources in a way not intended > by the original promulgator of that ritual mumbo-jumbo is that old, > surefire path to failure known as "cargo-cult programming". > Agreed. Which is the why I'm asking some of these questions now. > ... >> As for the other packages in Common and CommonCandidate, I think the >> vast majority are very soon going to be sitting in the same package, >> com.novice.common since they are unrelated except that they are >> commonly used. The vast majority are used independently, not >> together, so they aren't really related. The few that are both >> related and common will get their own packages. There! I've just put >> all the code in the Common project into one big package. A small >> handful of types will get moved again into separate packages as I >> figure out which ones really need that treatment. > > > That sounds valid. > -- Novice
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-02-27 17:24 -0800 |
| Message-ID | <jihabg$3oo$1@news.albasani.net> |
| In reply to | #12453 |
On 02/27/2012 02:50 PM, Novice wrote: >> Implementations of 'List<E>' include 'ArrayList<E>' and 'TreeList<E>'. Oops, I got the standard API and the Apache Commons Collections API mixed up. Sorry. >> Why don't you take a break and read the Javadocs for these three >> types? >> > I've got interface List<E> and class ArrayList<E> (which implements List > <E> among other interfaces) but I don't have TreeList<E>. I mostly still > use the Java 1.6 API but even the Java 1.7 API doesn't have a TreeList. > What did you mean to say? And what do you want me to learn? I'm guessing > you want me to see how a class makes use of an Interface but possibly you > have something more specific in mind? No, I made a mistake. There is such a thing but I didn't really mean to recommend something outside the standard API. But if you ever do want 'TreeList', here's what I was misremembering: <http://commons.apache.org/collections/api-release/org/apache/commons/collections/list/TreeList.html> Commons Collections is a very popular package that aims to expand and augment the standard Collections API. -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
[toc] | [prev] | [next] | [standalone]
| From | Novice <novice@example..com> |
|---|---|
| Date | 2012-02-29 15:00 +0000 |
| Message-ID | <XnsA008660779DFEjpnasty@94.75.214.39> |
| In reply to | #12459 |
Lew <noone@lewscanon.com> wrote in news:jihabg$3oo$1@news.albasani.net: > On 02/27/2012 02:50 PM, Novice wrote: >>> Implementations of 'List<E>' include 'ArrayList<E>' and >>> 'TreeList<E>'. > > Oops, I got the standard API and the Apache Commons Collections API > mixed up. Sorry. > >>> Why don't you take a break and read the Javadocs for these three >>> types? >>> >> I've got interface List<E> and class ArrayList<E> (which implements >> List <E> among other interfaces) but I don't have TreeList<E>. I >> mostly still use the Java 1.6 API but even the Java 1.7 API doesn't >> have a TreeList. What did you mean to say? And what do you want me to >> learn? I'm guessing you want me to see how a class makes use of an >> Interface but possibly you have something more specific in mind? > > No, I made a mistake. There is such a thing but I didn't really mean > to recommend something outside the standard API. > No worries! > But if you ever do want 'TreeList', here's what I was misremembering: > <http://commons.apache.org/collections/api-release/org/apache/commons/c > ollections/list/TreeList.html> > > Commons Collections is a very popular package that aims to expand and > augment the standard Collections API. > I'm already a fan of the Collections classes in regular Java and use them eagerly. I must have a look at Commons Collections now.... And I need to look at List and ArrayList in more detail too. I've already glanced at them and expect to start a thread on Interfaces soon so that I can hash out some of my conceptions and misconceptions about interfaces vs. classes. It might take a couple of days because I've got some other things that I need to do first.... -- Novice
[toc] | [prev] | [next] | [standalone]
| From | Daniel Pitts <newsgroup.nospam@virtualinfinity.net> |
|---|---|
| Date | 2012-02-29 09:14 -0800 |
| Message-ID | <u1t3r.2732$HX7.1903@newsfe11.iad> |
| In reply to | #12528 |
On 2/29/12 7:00 AM, Novice wrote: > Lew<noone@lewscanon.com> wrote in news:jihabg$3oo$1@news.albasani.net: > >> On 02/27/2012 02:50 PM, Novice wrote: >>>> Implementations of 'List<E>' include 'ArrayList<E>' and >>>> 'TreeList<E>'. >> >> Oops, I got the standard API and the Apache Commons Collections API >> mixed up. Sorry. >> >>>> Why don't you take a break and read the Javadocs for these three >>>> types? >>>> >>> I've got interface List<E> and class ArrayList<E> (which implements >>> List<E> among other interfaces) but I don't have TreeList<E>. I >>> mostly still use the Java 1.6 API but even the Java 1.7 API doesn't >>> have a TreeList. What did you mean to say? And what do you want me to >>> learn? I'm guessing you want me to see how a class makes use of an >>> Interface but possibly you have something more specific in mind? >> >> No, I made a mistake. There is such a thing but I didn't really mean >> to recommend something outside the standard API. >> > No worries! > >> But if you ever do want 'TreeList', here's what I was misremembering: >> <http://commons.apache.org/collections/api-release/org/apache/commons/c >> ollections/list/TreeList.html> >> >> Commons Collections is a very popular package that aims to expand and >> augment the standard Collections API. >> > > I'm already a fan of the Collections classes in regular Java and use them > eagerly. I must have a look at Commons Collections now.... Apache commons has a lot of useful libraries that are missing from core Java. The StringUtils are very useful as well.
[toc] | [prev] | [next] | [standalone]
| From | Lew <noone@lewscanon.com> |
|---|---|
| Date | 2012-02-29 09:55 -0800 |
| Message-ID | <jilopr$lof$1@news.albasani.net> |
| In reply to | #12528 |
Novice wrote:
> And I need to look at List
<E>
> and ArrayList
<E>
> in more detail too. I've already
> glanced at them and expect to start a thread on Interfaces [sic] soon so that I
> can hash out some of my conceptions and misconceptions about interfaces
> vs. classes. It might take a couple of days because I've got some other
> things that I need to do first....
I favor a style of programming I call "type-based programming" that relies on
interfaces and generics.
Since you say you write comments first, this should be natural for you.
An interface is like a compilable comment that specifies what classes are
supposed to accomplish. Classes are specific implementations of what their
interfaces promise.
In general, per the advice of /Effective Java/ (2nd ed.) by Joshua Bloch* and
other wise people, you should declare variables, return types, etc., as the
most general (closest to interface) type that promises what you need.
If all your list needs is what's promised by 'List<E>', you declare the type
as the interface type. If it needs additional methods or attributes declared
by 'ArrayList<E>' but not in the interface, you use the more specific type. If
you don't even need the "listiness" but just that it's a collection, declare
the type 'Collection<E>'.
When you design a program, design it in terms of interfaces. Defer
implementations as far as makes sense. This lets you focus on _what_ the
program should do rather than _how_.
I frequently write interfaces even when I'm only writing one implementing class.
So taking lists as the example:
List<String> options = new ArrayList<>();
I declared the 'options' variable as a 'List<String>', not as an
'ArrayList<String>'. If I discover that the array-backed list wasn't giving me
the performance or other implementation-specific behavior I need, but a linked
list does, I can refactor more easily:
List<String> options = new LinkedList<>();
The rest of the program, depending only on the "list"ness and not the
"array"ness, is unharmed.
(What performance differences are there? Excellent question! Pop quiz - please
answer this post with your answer - where would you find out about performance
characteristics of 'ArrayList<E>' and 'LinkedList<E>'?)
Summary:
Interface: what to do
Class: how to do it
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
[toc] | [prev] | [next] | [standalone]
| From | Novice <novice@example..com> |
|---|---|
| Date | 2012-02-29 21:31 +0000 |
| Message-ID | <XnsA008A84123C55jpnasty@94.75.214.39> |
| In reply to | #12540 |
Lew <noone@lewscanon.com> wrote in news:jilopr$lof$1@news.albasani.net: > Novice wrote: >> And I need to look at List > <E> >> and ArrayList > <E> >> in more detail too. I've already >> glanced at them and expect to start a thread on Interfaces [sic] soon >> so that I can hash out some of my conceptions and misconceptions >> about interfaces vs. classes. It might take a couple of days because >> I've got some other things that I need to do first.... > > I favor a style of programming I call "type-based programming" that > relies on interfaces and generics. > > Since you say you write comments first, this should be natural for > you. > > An interface is like a compilable comment that specifies what classes > are supposed to accomplish. Classes are specific implementations of > what their interfaces promise. > > In general, per the advice of /Effective Java/ (2nd ed.) by Joshua > Bloch* and other wise people, you should declare variables, return > types, etc., as the most general (closest to interface) type that > promises what you need. > > If all your list needs is what's promised by 'List<E>', you declare > the type as the interface type. If it needs additional methods or > attributes declared by 'ArrayList<E>' but not in the interface, you > use the more specific type. If you don't even need the "listiness" but > just that it's a collection, declare the type 'Collection<E>'. > > When you design a program, design it in terms of interfaces. Defer > implementations as far as makes sense. This lets you focus on _what_ > the program should do rather than _how_. > > I frequently write interfaces even when I'm only writing one > implementing class. > > So taking lists as the example: > > List<String> options = new ArrayList<>(); > > I declared the 'options' variable as a 'List<String>', not as an > 'ArrayList<String>'. If I discover that the array-backed list wasn't > giving me the performance or other implementation-specific behavior I > need, but a linked list does, I can refactor more easily: > > List<String> options = new LinkedList<>(); > > The rest of the program, depending only on the "list"ness and not the > "array"ness, is unharmed. > > (What performance differences are there? Excellent question! Pop quiz > - please answer this post with your answer - where would you find out > about performance characteristics of 'ArrayList<E>' and > 'LinkedList<E>'?) > > Summary: > Interface: what to do > Class: how to do it > I need to understand what you've said a bit better before I try the pop quiz ;-) It makes perfect sense to me to figure out what a program needs to do before you worry about how it gets done. You've got to design a house - how many bedrooms, how many bathrooms, what style of house (ranch or bungalow or apartment building), etc. etc. - before you choose the exact fixtures. But when you talked about designing interfaces, I assumed you meant NEW interfaces. Your examples seem to be about selecting which of the existing interfaces - which kind of lists - you wanted. But those kinds already exist so you're really just choosing them, not inventing new ones to do new things. It would be helpful to me if you also talked about new interfaces and how those come about at design time. By the way, I completely see your point in the examples. I have already benefited from the same by using Collections. I use more Sets than Lists and I will often start with a HashSet but if I start using it and find it doesn't have things in the order I wanted, it's a trivial thing to change it to another ordering by choosing a TreeSet or LinkedHashSet. That is REALLY convenient. Now that I think about it, I suppose I know enough to tackle the pop quiz after all. I have the feeling that I'm supposed to answer with something like "the API" or maybe based on something you said in one of your posts. Well, I'm going to "over-answer" the question and say this: I know that the API or the various Java Tutorials (like the one on Collections) often gives clues about performance and tells you explicitly, for example, that a HashSet normally performs best and a TreeSet worst with a LinkedHashSet typically performing almost as well as a HashSet. So that's obviously a good place to start. But you can obviously go a lot further. Various options come to mind: - Simply try executing a few different implementations. This is worthwhile especially if it is a matter of changing just one line of code to get an alternate implementation. It might be completely impractical if we're talking about developing hundreds or thousands of lines of code to get another implementation. - Ask other people. If you have doubts about a given approach, ask on newsgroups like this one what their experience has been. The veterans here can probably tell you from personal experience that Approach A is awful and Approach B is much better and Approach C is even better. - Fire up your debugger and try tracing through your implementation to see how efficient it seems. You can sometimes find bottlenecks that way that convince you to try a different approach. - Performance tools. I have very little experience with these but I've heard whispers that there are tools you can apply to get real numbers as your program runs so that you can see if it is a pig. I expect the better tools in this category will even suggest changes to your code (or environment) to improve performance and maybe even make those changes for you. - Benchmarking. Set up your own benchmark to compare different implementations that solve a problem. Potentially lots of work involved but might be necessary if all else fails. Okay, back to you.... ;-) -- Novice
[toc] | [prev] | [next] | [standalone]
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.java.programmer
csiph-web