|
From: Christoph W. <chr...@we...> - 2004-06-01 18:24:09
|
Hi, Be prepared this mail is quite extensive! Martin wrote: > I also noticed that we have dead sources, so we should > mark them as dead or remove them directly from the > repository. Kick bad source whenever encountered. We've CVS let's consult the attic = if we deleted anything useful. > I have made some work to determine where a piece of > source belongs, but it's not a final decision at > all. I don't want to separate the sources according > to MVC (model-view-controller), because it will be > difficult to follow the processes which a user > walks along and which we need to keep together to > work efficiently. > The MVC structure below exists ONLY to make some > helping subcategories. Creating packages accoring to MVC structure is evil and leads to a = couple of circular references (Controller, View as example), no self contained packages etc... > I await your comments, before I go ahead. Here it is! First I refactored subscriptions to channels so let's use the term = channel for both a subscription and an rss feed channel. In case this separation = is no longer present in code. Only one interface "Channel" exists. Let's first start from our "entity" interaces that build the gantry of RssView: * Node=20 - new interface to better manage Channel an RssGroupNodes in our model * CategoryNode=20 - derived from Node - represents a Node with children in our model * Channel * Article Let's augment this list by all classes that are directly used by these interfaces: Channel: * ChannelListener * ChannelHeader * Query If we could extract these classes to a package for example "core" and = add the classes that implement Node, CategoryNode , Channel and Article interfaces we get a perfect package. Imho we should not try to move our Listener/Event/EventSupport classes = to this package but give them a seperate "sub-packages" named event. We should not move any "reusable" UI Classes to specific packages. = Example: > - channel tree > ./src/de/cinek/rssview/ui/DnDSupportTree.java We could instead create a package for these self contained Classes named "widgets" or something similar. We use these classes like we would use = some third party component they don't depend on the rest of rssview. This is especially true for Sortable Table components. Well suitable canidats for this package are also: > ./src/de/cinek/rssview/RssSplashScreen.java > ./src/de/cinek/rssview/images/IconContainer.java > ./src/de/cinek/rssview/RssInfoDialog.java > ./src/de/cinek/rssview/ui/HighlightFilter.java Rename the "io" package to dataaccess. Move ampheta desk connectors to connectivity package and Ampheta Desk related events to connectivity.event package Now a proposal for the great package refactoring: Let's take some smaller steps to a better package structure. After every step let's test our refactoring using some metric toolkits like jdepend = to be sure that we're making things better not worse... My proposed package structure (de.cinek.rssview omitted): event dataaccess core widgets widgets.table widgets.dragdrop (perhaps if we find enough classes) connectivity connectivity.event Cheers Christoph PS: This mail was written using Outlook. All package names ment to be in lower case! Even if Outlook does not mean that. |