[Scaffoldhunter-devel] Package Structure and Modularization / Re: [Scaffoldhunter] Heatmaps and Dendrograms

[Till S. <til...@tu...>]

Hi, 
this mail contains some useful informations for all other developers that want to understand the package structure. 

Am Donnerstag, 15. Mai 2014, 00:26:38 schrieb Werner Sturm:
> - Maybe I will reuse the class ColorLegend located in 
> "edu.udo.scaffoldhunter.view.treemap.sidebar" as well. Should it be 
> placed in a more general package to avoid dependency on another view? I 
> do not know which package might be appropriate.
> 
> - To conform to the current package structure I should create the package
> "edu.udo.scaffoldhunter.view.heatmap" but it is not recommended that the 
> HeatMap package depends on several other views on the same package level.
Yes, all HeatMap specific code should go to that specific package. Everything else, that is reused by different views, should go to some common package and not depend on any of the views directly. That means it should not have any parameters, attributes, etc. of any class that is defined in the view package. If you need some concrete methods defined in the view package, define an interface for it in the common package and implement that interface by the specific view. 
One common package is the view.util package. However, as the name util suggests this is mainly for some small helpers such as the above mentioned color legend.  If you want to share larger parts (more that a single class) such as the complete dendrogram implementation, please create a new package view.components and a subpackage for the component (e.g. as dendrogram).

> 
> - I will also have to refactor/generalize some classes of DendrogramView 
> because they directly depend on DendrogramView (see 
> ClusteringController). 
Sounds reasonable. The ClusteringController is still not ideal in the above mentioned manner. This is a perfect example where we should create an interface, that provides the methods that always need to be present for the controller. For example the interface should contain a clusteringFinished(); method that can be called by the controller. This is similar to an listener / observer design pattern, but you have only a single observer which is passed to the controller in the constructor.
> Abstracting a view + state with clustering 
> functionality (ClusterController, StartClusteringPanel, etc.) might be a 
> solution.
i would not introduce some abstract "clustering view" class. Simply use the interface approach described above. Inheritance from a common superclass is always somewhat inflexible and i guess you cannot share much of functionality by doing so. Try to create small modules instead if you like to reuse functionality in different views.

> 
> - I might have to move classes located in the package 
> "edu.udo.scaffoldhunter.view.dendrogram" because I have to reuse several 
> classes (e.g., StartClusteringPanel, DendrogramEdge, DendrogramViewNode, 
> etc.). In this case DendrogramViewNode has to be renamed as well. 
> Creating a separate Dendrogram module would be nice but I think it takes 
> time which I need for other tasks till mid-term.
> Or maybe heatmap is a sub-package of dendrogram? (don't really like this 
> idea so far)
The ideal case is described above, but it could understand if you do not want to refactor the complete dendrogram view. This can take a reasonable amount of time. I would like to propose a golden middle way. Do not touch the dendrogram view where it  leads to heavy refactoring, but create / design your view in a manner, that you use reusable components, such as the dendrogram. This allows us to reuse your component later in the dendrogram view and the adaption of your components in the dendrogram view can be done by somebody else. This is still much less work for us than if we have to extract the component from two views which have them integrated without any component concept. 

> 
> I have not finished investigating these packages yet but these points 
> represent my current considerations and maybe you have a suggestion how 
> code should be organized to conform to current code structure.
> 
Looks good. The thought are going in the right direction. 

[1] https://en.wikipedia.org/wiki/Composition_over_inheritance


Greetings 
Till 
-- 
Dipl.-Inf. Till Schäfer
TU Dortmund University
Chair 11 - Algorithm Engineering
Otto-Hahn-Str. 14 / Room 237
44227 Dortmund, Germany

e-mail: til...@cs...
phone: +49(231)755-7706
fax: +49(231)755-7740
web: http://ls11-www.cs.uni-dortmund.de/staff/schaefer
pgp: https://keyserver2.pgp.com/vkd/SubmitSearch.event?&&SearchCriteria=0xD84DED79