Packet Desing and Bock recommendation

[Christian]

Hello

2 things..


1. Are there any desing patterns that should be followed or
recommendations how to divide my classfiles into packages?
Any Pointer for me?


2. I recently wanted to buy me abook to learn a bit more about
concurrency since most of my applications are very concurrent..


I found two books that were recommendet and I can't decide:

Concurrent Programming in Java(TM): Design Principles and Pattern (2nd
Edition)

and

Java Concurrency in Practice


Does someone here have a favorite? Or a better recommendation?
I am asking because the amazon feedbacks are not so conclusive on those
books..


Christian

 

[Chris Uppal]

1. Are there any desing patterns that should be followed or
recommendations how to divide my classfiles into packages?

You might find Ed Kirwan's thoughts illuminating:
http://www.edkirwan.kgbinternet.com/fracdoc/frac-page10.html


One thought of my own that I haven't seen stated elsewhere in the same form
(though, of course, it may be common in material I haven't read), is that the
primary aspect of package design is the distinction between what I call
"published" and non-published items. A published item (method, class,
interface, ...) is something that you have advertised to client code, and which
you (therefore) have committed yourself to maintaining in essentially the same
form in all future revisions of the software. "Unpublished" stuff is anything
else. In Java that distinction maps fairly well onto public and protected
access for published classes and members, and private or "package private" for
unpublished ones.

The mapping is a bit loose, because:

(a) a public member of an non-published class is not published itself
(obviously).

(b) sometimes it is necessary to make things public for technical reasons,
even though you have no intention of publishing them (in my sense).

(c) sometimes it is necessary to deprecate, and later withdraw, published
items.

(d) Java has no way of saying "this entire package should be treated as
private".

(b) and (d) can only be handled (in Java) by documentation (as for instance in
the JRE where there are a lot of public classes which Sun regard as private and
have explicitly not committed themselves to maintaining over time.

With those niggles understood, one way of thinking about package design is that
it is all about deciding what you (as the designer of one chunk of software)
are willing to commit to supporting regardless (almost) of any changes to the
system (internally or externally to that code).

Packages are units of publication. When you establish a package boundary, you
are signing a binding contract with the future.

I found two books that were recommendet and I can't decide:

Concurrent Programming in Java(TM): Design Principles and Pattern (2nd
Edition)

and

Java Concurrency in Practice

I have never read the second of those, but I have both editions of the first
(and intend to get the third edition too) -- it is /excellent/.

-- chris

 

[julien.robinson2]

You might find Ed Kirwan's thoughts illuminating:
http://www.edkirwan.kgbinternet.com/fracdoc/frac-page10.html

Sorry, I just had to barge in on this one...

This is totally it! Wow! Thanks a bunch for that link!

I've been programming for some time now in Java, this fractal stuff is
very good, mostly in that, like he himself says, there's a lot of old
stuff but very well explained. This guy is clear.

And he makes it clear what classes are good for, and how a design is
not good at one point in time: it's going to evolve no matter what,
it's good in that it may evolve later. Like amphibians.

And then there's a tool, too! Like most programmers (and most car
drivers, ha ha), I think I'm naturally good and the others are making
all the mistakes so I was flattered when it told me my design was
ok (around 0.8). But not perfect, argh. And it suggests improvement.
Wow.

The only thing I really don't like in this fractal stuff is the "ir1"
packages. I like to have package names that speak for themselves. And
I don't like the current tendency of systematically declaring
interfaces for anything. Of course, that's where my design is bad
according to fractal.

 

[Christian]

Sorry, I just had to barge in on this one...

This is totally it! Wow! Thanks a bunch for that link!

I can second that.. this is exactly what I was looking for
thank you very much.

so I was flattered when it told me my design was
ok (around 0.8).

0.76 was mine (less IPenis ;-))
though I am happy, I thought my packet structure was a complete loss...
and the tool showed me exactly the 2 packages that always felt wrong as
the ones breaking fractality principle most.

Christian