Justin Deoliveira wrote:
Hello all,
I was just moving the new catalog in, and with the api / main
(interface / impl) split, I have run into a problem. Some of the
catalog "api" is abstract classes. I could stick them in api but all
of api is interfaces so I thought I should bring it up on the list.
Would people like to be able to :
1. Allow abstract classes as part of api, or
2. Force api to be only interfaces, and make people double up with
interface/ abstract class pairs.
Personally I like 2, having api be all interfaces. Anyone else have
any thoughts.
I don't much mind - I think someone (Martin Perhaps, needs to kick out
custom implementations of everything and may prefer interfaces).
On a pragmatic front abstract classes are easier when developing API
(client code does not have to go through method burn as often), and
interfaces are much nicer for others to perform integration with. Think
how easy it is with the JUMP feature model to support the Feature
interface and get a instant visualization of whatever biz object you are
playing with ....
Here are some links on the subject:
- http://www.artima.com/lejava/articles/designprinciples.html
If that was intereresting - here is a counter point:
- http://beust.com/weblog/archives/000291.html
- http://twasink.net/blog/archives/2005/06/interfaces_are.html
So you got your tradeoff to think of. What I would like to see is the
use of Abstract classes, right up until 2.2.0 release time (that way you
have the most time possible to smoothly adjust to peoples suggestions).
Jody
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc. Get Certified Today
Register for a JBoss Training Course. Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
