Packaging the Bridge Pattern

[Ken]

Hi. I'm implementing the bridge pattern in Java. I'm wondering if I
should put each side of the bridge in its own package, or if I should
put all the bridge classes in one package. I'm leaning toward the
former, so each side of the bridge will have its protected methods
encapsulated from the other side.

Any thoughts?


Thanks,

Ken

 

[Tov Are Jacobsen]

Den Fri, 06 Aug 2004 16:16:36 -0700, skrev Ken:

Hi. I'm implementing the bridge pattern in Java. I'm wondering if I
should put each side of the bridge in its own package, or if I should
put all the bridge classes in one package. I'm leaning toward the
former, so each side of the bridge will have its protected methods
encapsulated from the other side.

Any thoughts?

I don't think packages should be created on that basis, so by default I
would say: Don't create a seperate package. In most scenarious where
you would use a bridge pattern, seperate packages for the implementations
would feel very natural.

 

[kk_oop]

Den Fri, 06 Aug 2004 16:16:36 -0700, skrev Ken:




I don't think packages should be created on that basis

This surprises me. Since protected allows visibility based, in part, on package boundaries, why would you not take this into consideration? I would think that not doing so could easily lead to unintended coupling of classes in the package.

Ken

 

[Tov Are Jacobsen]

This surprises me. Since protected allows visibility based, in part, on
package boundaries, why would you not take this into consideration? I
would think that not doing so could easily lead to unintended coupling
of classes in the package.

Code comprehension is a bigger issue than having the the compiler spit
out a message if you yourself do something silly.

Thinking about cases of usage is a better starting point for code
organization and API exposure.

Feature implementations done by other developers, probably should be in a
different package, but that's also very intuitive.

Do you have a specific application in mind where you would use the Bridge
Pattern?

 

[kk_oop]

Den Sat, 07 Aug 2004 07:48:52 -0400, skrev kk_oop<no spam>:
[...]


Code comprehension is a bigger issue than having the the compiler spit
out a message if you yourself do something silly.

But it is my experience that if the compiler lets me do something silly,
my class will end up being too tightly coupled which will make the code
less comprehensible and harder to test and debug. This becomes an even
bigger issue if it is not me doing something silly, but a code
maintainer who is making updates in another state five years from now.
That's the classic way that big projects with a long lifeline snowball
into unmaintainable behemoths. I think the Java creators had that in
mind when they provided the various visibility keywords.

Do you have a specific application in mind where you would use the Bridge
Pattern?

Various Target abstractions are dependent upon various Missile
implementations.

I think your suggestion makes sense about putting each implementation in
its own package. In fact, I'm thinking of doing this now:

1- Put the Abstraction and the Implementor in one package (the top of
the bridge)
2- Put each Refined Abstraction into its own package
3- Put each Concrete Implementor in its own package

Step 1 I think is useful, since it means that the Implementor does not
have to have any public methods. So when a client includes this package
(which is the only bridge package the client should have to include), he
will only be able to get his hands on the abstractions public methods.
That will let the compiler enforce the code structure for years to come.

The one thing I'm not positive about is whether I should put all Refined
Abstractions in one package or to keep each seperate (like what step 2
says). Same question applies to step Concrete Implementors.

Any thoughts of pros/cons?

Thanks,

Ken