assosciation private and public

> If you mean which fields should be private or public,

> all fields should be private. This enforces

> encapsulation, which means later you can change the

> implementation without changing the interface.

Actually what i am looking for is from another perspective. Let me rephrase my question.

Are the private assosciation shown in the class diagrams? n what r the rules governing this phenemenon?

nome02a at 2007-7-8 >

> Methods and fields are the things that can be private

> or public. Associations are not private or public --

> they are relationships between objects. Could you give

> us more of a hint of what you mean by a "private

> association"? Even a Google search turned up nothing

> on "private association"!

lets consider two classes "Professor" and "Student". On drawing a class diagram we will have a birectional assosciation. 1 Professor teaches many students and 1 student is taught by many professor so a many to many relationship.

While encoding we would depict it by instantiaing an array of students in Professor class and vice versa. The access modifier in both the cases would be public.

However we sometimes come across an assosciation among classes while going through code where the access modifier is private. My question is while drawing a class diagram would such an assosciation be shown?

hope you get my point.

nome02a at 2007-7-8 >

Containment associations will most often be private.

Consider the following:

Class Node is to be kept in a list which Class A manages.

First example.

Class Node is defined as a private inner class of Class A. Class A keeps a list of Nodes using a private instantiation of the ArrayList class. Node is private. The ArrayList is private. So when diagramming it the association is certainly private.

Node is wholly owned and contained by A. If A is deleted then all Nodes are deleted.

In this case one might make the point that because this is entirely private that it implementation rather than design. So it shouldn't be diagrammed at all. But sometimes it is necessary to do this to show how it will meet the needs of the system (or because a junior programmer is doing the coding and you want it to be painfully obvious.)

Second example

Class Node is a public class (not part of Class A.) Class A keeps a list of Nodes using a private instantiation of the ArrayList class. So when diagramming it the association is certainly private.

Again in this case A owns all of the Nodes.

Again the association could be consider an implementation detail (diagram is not necessary.) But because there are now external users, it might be more relevant to detail explicitly that a list of these is being kept.

For the above two examples 'private' might also serve the need of the code generation capability of the two. Neither of the above associations should ever be implemented publicly.

Third example

A variation of the examples above is where the association is to be managed by one or more external systems. If there is one external system then it can own it. But if there is more than one, then the assocation must be public.

In this case it is certainly possible (and likely) that A does not own the Nodes that it is associated with.

Fourth example

If the relationship between A to Node is many to many than the association is always external to A and Node. So unless it is explicitly owned by a single external system it must be public. Never make the mistake of trying to have either class try to own it.

In this case A never owns the Nodes that it is assocated with.

jschella at 2007-7-8 >