Hello everyone. Analyzing the points of our discussion, I have realized that the most critical problem is the dependence these classes may have on other classes.
With that in mind I recommend a gradual refactoring that works as follows: First, we mark the methods we want to extract as depreciated. Then, we copy those methods to a new class. So we will keep the methods in the original class for some time so that developers who have some assumption about the class can adapt. For example, the Javadoc has 114 methods, of which 64 are get () and set () methods. We could mark these methods as deprecated and copy them to a new class: JavadocConfig, but we would leave them in the Javadoc class, and they would be removed gradually. Those parameters and methods would be accessed by an instance variable in Javadoc. However, when choosing the methods we could analyze their complexity. If it is a simple set () or get () that only sets or returns a value it would be prioritized. Methods that have a greater complexity, or that make calls to other methods would not be extracted at first. What do you think about this strategy? 2017-07-22 8:13 GMT-03:00 Stefan Bodewig <bode...@apache.org>: > On 2017-07-21, João Paulo Lemes Machado wrote: > > > Hi everyone. I will prepare the suggestions for changes. Regarding the > > discussion above, the following classes are the best choices: > > > Javadoc, > > FTPTask, > > FileUtils > > > ok? > > sounds right. > > Stefan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > >
