Hello everyone. I was analyzing the modularization of some classes, and I identified that the class Project has an opportunity for cohesion improvement. The class BaseResourceCollectionWrapper was in the same situation and the problem was solved as follows: The AbstractResourceCollectionWrapper class was created, and several get() and set() methods that were used only to configure the class parameters were moved from BaseResourceCollectionWrapper to AbstractResourceCollectionWrapper. The new class was then accessed through an instance variable in BaseResourceCollectionWrapper. This strategy has cleaned and improved BaseResourceCollectionWrapper cohesion. With this in mind, I would recommend creating a new class: ProjectConfig , and moving the following methods: setPropertyInternal setInheritedProperty getUserProperty getCopyOfDataTypeDefinitions setKeepGoingMode getProject setJavaVersionProperty setInputHandler getName getProperties setSystemProperties getProperty getCopyOfTargets getExecutor setName getDescription getCoreLoader getFilters getResource getCopyOfReferences setUserProperty setProjectReference setDefaultInputStream getCopyOfTaskDefinitions getReferences setExecutor getDataTypeDefinitions setCoreLoader getJavaVersion setNewProperty getElementName setFileLastModified getInheritedProperties getBuildListeners getThreadTask setBasedir getUserProperties getGlobalFilterSet getDefaultInputStream getTargets getBaseDir setAntLib setDescription setDefaultTarget setProperty setDefault getReference getTaskDefinitions getDefaultTarget getInputHandler from the Project. Those parameters accessed by an instance variable in the Project. Moreover, the orthogonality is the design would be enhanced. What do you think about that?
I'm sure your changes would improve the quality of the Project class but at the same time it scares me. Project is a central class and we know there exist subclasses that are out of our control. AFAIK the components that integrate Ant into IDEs use subclasses of Project. We don't really know what those subclasses do. As long as they only override some methods your refactoring wouldn't break them, but they may rely upon a certain method calling another method, for example. Sometime last year I made an attribute final and promptly broke Eclipse's Ant integration - see bug 60582 I guess what I'm trying to say is be extra careful with this class and ensure the refactoring doesn't break any assumption anybody who knows the current code may have about the inner workings of the class. In the end this may mean you can't make all the changes that would improve the code.
Hi Stefan, thanks for the comment. I've also found refactoring opportunities in other classes. Would you mind if I created other issues to discuss about them? The recommendation will be very similar, changing the list of methods and class names.
Many, many thanks for your interest. Actually, I'd rather invite you over to the dev mailing list and discuss the opportunities there rather than inside the issue tracker. Once we've agreed on what would be good candidates to refactor, opening issues for each candidate would be fine.
I totally agree. Discuss the refactoring opportunities would be great. Thank you.
Hi Stefan, I send the list of opportunities to the dev mailing list. Can you tell me if it was received?
yes, it has been received. But you really should subscribe to the dev list or you might miss responses.
Thank you Stefan, I already subscribed.