Opportunities for cohesion improvement and refatoring.

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Opportunities for cohesion improvement and refatoring.

João Paulo Lemes Machado
Hello everyone.

My name is João Paulo, I am a graduate student the Federal University of
Uberlandia, Brazil.

I was analyzing the modularization of some classes of Ant, and  I
identified some opportunities for cohesion improvement in the following
classes:

Javac
Javadoc
FTPTask
FileUtils
AbstractFileSet
TarEntry


Could you please take a look and tell me if it's viable?

Maybe some of these classes could benefit from some kind of refactoring
that we can discuss.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Opportunities for cohesion improvement and refatoring.

Stefan Bodewig
Welcome João Paulo

On 2017-07-20, João Paulo Lemes Machado wrote:

> I was analyzing the modularization of some classes of Ant, and  I
> identified some opportunities for cohesion improvement in the following
> classes:

> Javac
> Javadoc
> FTPTask
> FileUtils
> AbstractFileSet

Similar to what I said about Project in the bugzilla issue you created
all these classes are part of Ant's public API and need to be treated
with care.

Ant has been around for more than fifteen years and an eco system of
extensions has ground around it. This is something that forces us to
be extra careful with refactoring.

Of the classes listed above Javadoc and FTPTask are unlikely to have
seen subclasses, Javac may have. FileUtils is unlikely to have seen
subclasses as a lot of its code is inside static methods or is
accessed via a quasi-singleton.

Still, when refactoring non-static public/protected methods you really
have to ensure you keep the existing who calls which method semantics
that subclasses may rely on. AbstractFileSet is an extremely dangerous
one, as it has certainly seen a lot of extensions outside of our
control.

> TarEntry

Is a special case to me. Ant's tar, zip and bzip2 packages have seeded
Commons Compress and from time to time I try to backport changes from
Compress to Ant - usually only the bugfixes. This may become more
difficult when the code bases start to deviate.

I'd be interested in hearing what kind of changes you'd like to make,
but please take a look at
https://git-wip-us.apache.org/repos/asf?p=commons-compress.git;a=blob;f=src/main/java/org/apache/commons/compress/archivers/tar/TarArchiveEntry.java
?

The class has undergone several changes that haven't been reflected
back, maybe it is mostly an issue of backporting those changes?

Cheers

        Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Opportunities for cohesion improvement and refatoring.

Gintautas Grigelionis
I looked at Project proposal [1].
I would suggest running the refactored Ant through japicmp [2] or revapi
[3] and examining the binary incompatibilities.

Gintas

[1] https://bz.apache.org/bugzilla/show_bug.cgi?id=61305
[2] http://siom79.github.io/japicmp/
[3] http://revapi.org/

2017-07-20 16:41 GMT+02:00 Stefan Bodewig <[hidden email]>:

> Welcome João Paulo
>
> On 2017-07-20, João Paulo Lemes Machado wrote:
>
> > I was analyzing the modularization of some classes of Ant, and  I
> > identified some opportunities for cohesion improvement in the following
> > classes:
>
> > Javac
> > Javadoc
> > FTPTask
> > FileUtils
> > AbstractFileSet
>
> Similar to what I said about Project in the bugzilla issue you created
> all these classes are part of Ant's public API and need to be treated
> with care.
>
> Ant has been around for more than fifteen years and an eco system of
> extensions has ground around it. This is something that forces us to
> be extra careful with refactoring.
>
> Of the classes listed above Javadoc and FTPTask are unlikely to have
> seen subclasses, Javac may have. FileUtils is unlikely to have seen
> subclasses as a lot of its code is inside static methods or is
> accessed via a quasi-singleton.
>
> Still, when refactoring non-static public/protected methods you really
> have to ensure you keep the existing who calls which method semantics
> that subclasses may rely on. AbstractFileSet is an extremely dangerous
> one, as it has certainly seen a lot of extensions outside of our
> control.
>
> > TarEntry
>
> Is a special case to me. Ant's tar, zip and bzip2 packages have seeded
> Commons Compress and from time to time I try to backport changes from
> Compress to Ant - usually only the bugfixes. This may become more
> difficult when the code bases start to deviate.
>
> I'd be interested in hearing what kind of changes you'd like to make,
> but please take a look at
> https://git-wip-us.apache.org/repos/asf?p=commons-compress.
> git;a=blob;f=src/main/java/org/apache/commons/compress/
> archivers/tar/TarArchiveEntry.java
> ?
>
> The class has undergone several changes that haven't been reflected
> back, maybe it is mostly an issue of backporting those changes?
>
> Cheers
>
>         Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Opportunities for cohesion improvement and refatoring.

Stefan Bodewig
Hi

thank you, Gintautas.

Yes, using a tool to verify the API hasn't changed will probably
help. Over in Commons we run this as a regular part of the release
process - it is even more important for things that are meant to be
re-usable components, of course.

I'm afraid that won't be enough, though.

Let me pick a silly example

in Project we currently have

    public Project createSubProject() {
        Project subProject = null;
        try {
            subProject = (getClass().newInstance());
        } catch (final Exception e) {
            subProject = new Project();
        }
        initSubProject(subProject);
        return subProject;
    }

and initSubProject is public as well.

A subclass may override initSubProject and rely on the method being
called by createSubProject. If you refactor createSubProject in a way
that it no longer calls initSubProject you are going to break the
subclass. And I don't think the tools are going to tell you as long as
you keep all existing methods.

This is what I meant with "have to ensure you keep the existing who
calls which method semantics".

Cheers

        Stefan


On 2017-07-20, Gintautas Grigelionis wrote:

> I looked at Project proposal [1].
> I would suggest running the refactored Ant through japicmp [2] or revapi
> [3] and examining the binary incompatibilities.

> Gintas

> [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=61305
> [2] http://siom79.github.io/japicmp/
> [3] http://revapi.org/

> 2017-07-20 16:41 GMT+02:00 Stefan Bodewig <[hidden email]>:

>> Welcome João Paulo

>> On 2017-07-20, João Paulo Lemes Machado wrote:

>>> I was analyzing the modularization of some classes of Ant, and  I
>>> identified some opportunities for cohesion improvement in the following
>>> classes:

>>> Javac
>>> Javadoc
>>> FTPTask
>>> FileUtils
>>> AbstractFileSet

>> Similar to what I said about Project in the bugzilla issue you created
>> all these classes are part of Ant's public API and need to be treated
>> with care.

>> Ant has been around for more than fifteen years and an eco system of
>> extensions has ground around it. This is something that forces us to
>> be extra careful with refactoring.

>> Of the classes listed above Javadoc and FTPTask are unlikely to have
>> seen subclasses, Javac may have. FileUtils is unlikely to have seen
>> subclasses as a lot of its code is inside static methods or is
>> accessed via a quasi-singleton.

>> Still, when refactoring non-static public/protected methods you really
>> have to ensure you keep the existing who calls which method semantics
>> that subclasses may rely on. AbstractFileSet is an extremely dangerous
>> one, as it has certainly seen a lot of extensions outside of our
>> control.

>>> TarEntry

>> Is a special case to me. Ant's tar, zip and bzip2 packages have seeded
>> Commons Compress and from time to time I try to backport changes from
>> Compress to Ant - usually only the bugfixes. This may become more
>> difficult when the code bases start to deviate.

>> I'd be interested in hearing what kind of changes you'd like to make,
>> but please take a look at
>> https://git-wip-us.apache.org/repos/asf?p=commons-compress.
>> git;a=blob;f=src/main/java/org/apache/commons/compress/
>> archivers/tar/TarArchiveEntry.java
>> ?

>> The class has undergone several changes that haven't been reflected
>> back, maybe it is mostly an issue of backporting those changes?

>> Cheers

>>         Stefan

>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Opportunities for cohesion improvement and refatoring.

Gintautas Grigelionis
Thanks, Stefan. You're right about the semantics; I did not mean the API
compatibility analysis to give a complete answer,
rather a hint about the amount of (potential) breakage. Based on that, a
decision can be taken whether it can be accepted,
mitigated or a completely new version is a must. If the latter is the case,
then one may decide it's not worth the while because of the cost of
adoption.

Gintas

2017-07-21 11:40 GMT+02:00 Stefan Bodewig <[hidden email]>:

> Hi
>
> thank you, Gintautas.
>
> Yes, using a tool to verify the API hasn't changed will probably
> help. Over in Commons we run this as a regular part of the release
> process - it is even more important for things that are meant to be
> re-usable components, of course.
>
> I'm afraid that won't be enough, though.
>
> Let me pick a silly example
>
> in Project we currently have
>
>     public Project createSubProject() {
>         Project subProject = null;
>         try {
>             subProject = (getClass().newInstance());
>         } catch (final Exception e) {
>             subProject = new Project();
>         }
>         initSubProject(subProject);
>         return subProject;
>     }
>
> and initSubProject is public as well.
>
> A subclass may override initSubProject and rely on the method being
> called by createSubProject. If you refactor createSubProject in a way
> that it no longer calls initSubProject you are going to break the
> subclass. And I don't think the tools are going to tell you as long as
> you keep all existing methods.
>
> This is what I meant with "have to ensure you keep the existing who
> calls which method semantics".
>
> Cheers
>
>         Stefan
>
>
> On 2017-07-20, Gintautas Grigelionis wrote:
>
> > I looked at Project proposal [1].
> > I would suggest running the refactored Ant through japicmp [2] or revapi
> > [3] and examining the binary incompatibilities.
>
> > Gintas
>
> > [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=61305
> > [2] http://siom79.github.io/japicmp/
> > [3] http://revapi.org/
>
> > 2017-07-20 16:41 GMT+02:00 Stefan Bodewig <[hidden email]>:
>
> >> Welcome João Paulo
>
> >> On 2017-07-20, João Paulo Lemes Machado wrote:
>
> >>> I was analyzing the modularization of some classes of Ant, and  I
> >>> identified some opportunities for cohesion improvement in the following
> >>> classes:
>
> >>> Javac
> >>> Javadoc
> >>> FTPTask
> >>> FileUtils
> >>> AbstractFileSet
>
> >> Similar to what I said about Project in the bugzilla issue you created
> >> all these classes are part of Ant's public API and need to be treated
> >> with care.
>
> >> Ant has been around for more than fifteen years and an eco system of
> >> extensions has ground around it. This is something that forces us to
> >> be extra careful with refactoring.
>
> >> Of the classes listed above Javadoc and FTPTask are unlikely to have
> >> seen subclasses, Javac may have. FileUtils is unlikely to have seen
> >> subclasses as a lot of its code is inside static methods or is
> >> accessed via a quasi-singleton.
>
> >> Still, when refactoring non-static public/protected methods you really
> >> have to ensure you keep the existing who calls which method semantics
> >> that subclasses may rely on. AbstractFileSet is an extremely dangerous
> >> one, as it has certainly seen a lot of extensions outside of our
> >> control.
>
> >>> TarEntry
>
> >> Is a special case to me. Ant's tar, zip and bzip2 packages have seeded
> >> Commons Compress and from time to time I try to backport changes from
> >> Compress to Ant - usually only the bugfixes. This may become more
> >> difficult when the code bases start to deviate.
>
> >> I'd be interested in hearing what kind of changes you'd like to make,
> >> but please take a look at
> >> https://git-wip-us.apache.org/repos/asf?p=commons-compress.
> >> git;a=blob;f=src/main/java/org/apache/commons/compress/
> >> archivers/tar/TarArchiveEntry.java
> >> ?
>
> >> The class has undergone several changes that haven't been reflected
> >> back, maybe it is mostly an issue of backporting those changes?
>
> >> Cheers
>
> >>         Stefan
>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Opportunities for cohesion improvement and refatoring.

Stefan Bodewig
Yes, using the tool might be a good first indicator.

I didn't mean to imply you called the tools a complete answer, just
wanted to clarify my own words :-)

Stefan

On 2017-07-21, Gintautas Grigelionis wrote:

> Thanks, Stefan. You're right about the semantics; I did not mean the API
> compatibility analysis to give a complete answer,
> rather a hint about the amount of (potential) breakage. Based on that, a
> decision can be taken whether it can be accepted,
> mitigated or a completely new version is a must. If the latter is the case,
> then one may decide it's not worth the while because of the cost of
> adoption.

> Gintas

> 2017-07-21 11:40 GMT+02:00 Stefan Bodewig <[hidden email]>:

>> Hi

>> thank you, Gintautas.

>> Yes, using a tool to verify the API hasn't changed will probably
>> help. Over in Commons we run this as a regular part of the release
>> process - it is even more important for things that are meant to be
>> re-usable components, of course.

>> I'm afraid that won't be enough, though.

>> Let me pick a silly example

>> in Project we currently have

>>     public Project createSubProject() {
>>         Project subProject = null;
>>         try {
>>             subProject = (getClass().newInstance());
>>         } catch (final Exception e) {
>>             subProject = new Project();
>>         }
>>         initSubProject(subProject);
>>         return subProject;
>>     }

>> and initSubProject is public as well.

>> A subclass may override initSubProject and rely on the method being
>> called by createSubProject. If you refactor createSubProject in a way
>> that it no longer calls initSubProject you are going to break the
>> subclass. And I don't think the tools are going to tell you as long as
>> you keep all existing methods.

>> This is what I meant with "have to ensure you keep the existing who
>> calls which method semantics".

>> Cheers

>>         Stefan


>> On 2017-07-20, Gintautas Grigelionis wrote:

>>> I looked at Project proposal [1].
>>> I would suggest running the refactored Ant through japicmp [2] or revapi
>>> [3] and examining the binary incompatibilities.

>>> Gintas

>>> [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=61305
>>> [2] http://siom79.github.io/japicmp/
>>> [3] http://revapi.org/

>>> 2017-07-20 16:41 GMT+02:00 Stefan Bodewig <[hidden email]>:

>>>> Welcome João Paulo

>>>> On 2017-07-20, João Paulo Lemes Machado wrote:

>>>>> I was analyzing the modularization of some classes of Ant, and  I
>>>>> identified some opportunities for cohesion improvement in the following
>>>>> classes:

>>>>> Javac
>>>>> Javadoc
>>>>> FTPTask
>>>>> FileUtils
>>>>> AbstractFileSet

>>>> Similar to what I said about Project in the bugzilla issue you created
>>>> all these classes are part of Ant's public API and need to be treated
>>>> with care.

>>>> Ant has been around for more than fifteen years and an eco system of
>>>> extensions has ground around it. This is something that forces us to
>>>> be extra careful with refactoring.

>>>> Of the classes listed above Javadoc and FTPTask are unlikely to have
>>>> seen subclasses, Javac may have. FileUtils is unlikely to have seen
>>>> subclasses as a lot of its code is inside static methods or is
>>>> accessed via a quasi-singleton.

>>>> Still, when refactoring non-static public/protected methods you really
>>>> have to ensure you keep the existing who calls which method semantics
>>>> that subclasses may rely on. AbstractFileSet is an extremely dangerous
>>>> one, as it has certainly seen a lot of extensions outside of our
>>>> control.

>>>>> TarEntry

>>>> Is a special case to me. Ant's tar, zip and bzip2 packages have seeded
>>>> Commons Compress and from time to time I try to backport changes from
>>>> Compress to Ant - usually only the bugfixes. This may become more
>>>> difficult when the code bases start to deviate.

>>>> I'd be interested in hearing what kind of changes you'd like to make,
>>>> but please take a look at
>>>> https://git-wip-us.apache.org/repos/asf?p=commons-compress.
>>>> git;a=blob;f=src/main/java/org/apache/commons/compress/
>>>> archivers/tar/TarArchiveEntry.java
>>>> ?

>>>> The class has undergone several changes that haven't been reflected
>>>> back, maybe it is mostly an issue of backporting those changes?

>>>> Cheers

>>>>         Stefan

>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]



>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Opportunities for cohesion improvement and refatoring.

João Paulo Lemes Machado
Hi everyone. I will prepare the suggestions for changes. Regarding the
discussion above, the following classes are the best choices:

Javadoc,
FTPTask,
 FileUtils

ok?





2017-07-21 12:10 GMT-03:00 Stefan Bodewig <[hidden email]>:

> Yes, using the tool might be a good first indicator.
>
> I didn't mean to imply you called the tools a complete answer, just
> wanted to clarify my own words :-)
>
> Stefan
>
> On 2017-07-21, Gintautas Grigelionis wrote:
>
> > Thanks, Stefan. You're right about the semantics; I did not mean the API
> > compatibility analysis to give a complete answer,
> > rather a hint about the amount of (potential) breakage. Based on that, a
> > decision can be taken whether it can be accepted,
> > mitigated or a completely new version is a must. If the latter is the
> case,
> > then one may decide it's not worth the while because of the cost of
> > adoption.
>
> > Gintas
>
> > 2017-07-21 11:40 GMT+02:00 Stefan Bodewig <[hidden email]>:
>
> >> Hi
>
> >> thank you, Gintautas.
>
> >> Yes, using a tool to verify the API hasn't changed will probably
> >> help. Over in Commons we run this as a regular part of the release
> >> process - it is even more important for things that are meant to be
> >> re-usable components, of course.
>
> >> I'm afraid that won't be enough, though.
>
> >> Let me pick a silly example
>
> >> in Project we currently have
>
> >>     public Project createSubProject() {
> >>         Project subProject = null;
> >>         try {
> >>             subProject = (getClass().newInstance());
> >>         } catch (final Exception e) {
> >>             subProject = new Project();
> >>         }
> >>         initSubProject(subProject);
> >>         return subProject;
> >>     }
>
> >> and initSubProject is public as well.
>
> >> A subclass may override initSubProject and rely on the method being
> >> called by createSubProject. If you refactor createSubProject in a way
> >> that it no longer calls initSubProject you are going to break the
> >> subclass. And I don't think the tools are going to tell you as long as
> >> you keep all existing methods.
>
> >> This is what I meant with "have to ensure you keep the existing who
> >> calls which method semantics".
>
> >> Cheers
>
> >>         Stefan
>
>
> >> On 2017-07-20, Gintautas Grigelionis wrote:
>
> >>> I looked at Project proposal [1].
> >>> I would suggest running the refactored Ant through japicmp [2] or
> revapi
> >>> [3] and examining the binary incompatibilities.
>
> >>> Gintas
>
> >>> [1] https://bz.apache.org/bugzilla/show_bug.cgi?id=61305
> >>> [2] http://siom79.github.io/japicmp/
> >>> [3] http://revapi.org/
>
> >>> 2017-07-20 16:41 GMT+02:00 Stefan Bodewig <[hidden email]>:
>
> >>>> Welcome João Paulo
>
> >>>> On 2017-07-20, João Paulo Lemes Machado wrote:
>
> >>>>> I was analyzing the modularization of some classes of Ant, and  I
> >>>>> identified some opportunities for cohesion improvement in the
> following
> >>>>> classes:
>
> >>>>> Javac
> >>>>> Javadoc
> >>>>> FTPTask
> >>>>> FileUtils
> >>>>> AbstractFileSet
>
> >>>> Similar to what I said about Project in the bugzilla issue you created
> >>>> all these classes are part of Ant's public API and need to be treated
> >>>> with care.
>
> >>>> Ant has been around for more than fifteen years and an eco system of
> >>>> extensions has ground around it. This is something that forces us to
> >>>> be extra careful with refactoring.
>
> >>>> Of the classes listed above Javadoc and FTPTask are unlikely to have
> >>>> seen subclasses, Javac may have. FileUtils is unlikely to have seen
> >>>> subclasses as a lot of its code is inside static methods or is
> >>>> accessed via a quasi-singleton.
>
> >>>> Still, when refactoring non-static public/protected methods you really
> >>>> have to ensure you keep the existing who calls which method semantics
> >>>> that subclasses may rely on. AbstractFileSet is an extremely dangerous
> >>>> one, as it has certainly seen a lot of extensions outside of our
> >>>> control.
>
> >>>>> TarEntry
>
> >>>> Is a special case to me. Ant's tar, zip and bzip2 packages have seeded
> >>>> Commons Compress and from time to time I try to backport changes from
> >>>> Compress to Ant - usually only the bugfixes. This may become more
> >>>> difficult when the code bases start to deviate.
>
> >>>> I'd be interested in hearing what kind of changes you'd like to make,
> >>>> but please take a look at
> >>>> https://git-wip-us.apache.org/repos/asf?p=commons-compress.
> >>>> git;a=blob;f=src/main/java/org/apache/commons/compress/
> >>>> archivers/tar/TarArchiveEntry.java
> >>>> ?
>
> >>>> The class has undergone several changes that haven't been reflected
> >>>> back, maybe it is mostly an issue of backporting those changes?
>
> >>>> Cheers
>
> >>>>         Stefan
>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: [hidden email]
> >>>> For additional commands, e-mail: [hidden email]
>
>
>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: [hidden email]
> >> For additional commands, e-mail: [hidden email]
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Opportunities for cohesion improvement and refatoring.

Stefan Bodewig
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Opportunities for cohesion improvement and refatoring.

João Paulo Lemes Machado
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 <[hidden email]>:

> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Opportunities for cohesion improvement and refatoring.

Stefan Bodewig
On 2017-07-23, João Paulo Lemes Machado wrote:

> 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?

This strategy is a sound strategy if you expect users of your API to
follow releases closely. Unfortunately this is not what we see with Ant.

Right now we are fielding a bug reported by somebody who is migrating
from Ant 1.6.2 to 1.10.1 - 1.6.2 has been superseeded by 1.6.3 in
2005. This is not uncommon.

People are using additional libraries like ant-contrib. ant-contrib has
seen its last release in 2010 and it's development has stalled
completely. We cannot remove any method used by it at all without
breaking build files of people who rely on ant-contrib. Unfortunately
ant-contrib is not the only example.

This has led to us never removing any methods at all, no matter how long
it has been deprecated. I'm not sure this is a good idea and not saying
it has to stay that way, but the above has been the rationale for it.

To be honest, I am one of the people who've upheld the "backwards
compatible at all cost" mantra. Part of this may be due to the pain of
"every release of Ant breaks my builds" threads around the release of
Ant 1.2 (almost 17 years and I still recall it like yesterday, strange).

If others feel it is time to revisit our extremely strong and at the
same time limiting stance on backwards compatibility, I'll be listening
to them.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Opportunities for cohesion improvement and refatoring.

João Paulo Lemes Machado
Thank you Stefan.
I did not know that the issue of break of build was so serious.

However, I still think that creating a class for the configuration methods
can help prevent these classes from growing even more.

For example if someone wants to create a new get () or set () method for
the Javadoc class, he might consider creating it directly in the
JavadocConfig class, avoiding putting more methods into the Javadoc class.
And perhaps this strategy can be adopted for the creation of new classes in
the future.

For example, if you are going to create a new class that has a considerable
amount of gets () and sets () like Javadoc, you might consider creating a
configuration class for these methods.

I think if it is very difficult to correct what has already been done,
maybe we can avoid these problems in the future by adopting new practices
and strategies.

What do you think?

2017-07-23 7:47 GMT-03:00 Stefan Bodewig <[hidden email]>:

> On 2017-07-23, João Paulo Lemes Machado wrote:
>
> > 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?
>
> This strategy is a sound strategy if you expect users of your API to
> follow releases closely. Unfortunately this is not what we see with Ant.
>
> Right now we are fielding a bug reported by somebody who is migrating
> from Ant 1.6.2 to 1.10.1 - 1.6.2 has been superseeded by 1.6.3 in
> 2005. This is not uncommon.
>
> People are using additional libraries like ant-contrib. ant-contrib has
> seen its last release in 2010 and it's development has stalled
> completely. We cannot remove any method used by it at all without
> breaking build files of people who rely on ant-contrib. Unfortunately
> ant-contrib is not the only example.
>
> This has led to us never removing any methods at all, no matter how long
> it has been deprecated. I'm not sure this is a good idea and not saying
> it has to stay that way, but the above has been the rationale for it.
>
> To be honest, I am one of the people who've upheld the "backwards
> compatible at all cost" mantra. Part of this may be due to the pain of
> "every release of Ant breaks my builds" threads around the release of
> Ant 1.2 (almost 17 years and I still recall it like yesterday, strange).
>
> If others feel it is time to revisit our extremely strong and at the
> same time limiting stance on backwards compatibility, I'll be listening
> to them.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Opportunities for cohesion improvement and refatoring.

Stefan Bodewig
On 2017-07-23, João Paulo Lemes Machado wrote:

> Thank you Stefan.
> I did not know that the issue of break of build was so serious.

> However, I still think that creating a class for the configuration methods
> can help prevent these classes from growing even more.

Absolutely.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Loading...