You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by João Paulo Lemes Machado <le...@gmail.com> on 2017/07/25 12:55:18 UTC
Opportunities for cohesion improvement and refatoring
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 Tomcat, and I
identified some opportunities for cohesion improvement in the following
classes:
DataSourceProxy
ConnectionPool
BasicDataSource
DelegatingCallableStatement
PoolProperties
PoolConfiguration
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.
Re: Opportunities for cohesion improvement and refatoring
Posted by Mark Thomas <ma...@apache.org>.
On 02/08/17 20:18, João Paulo Lemes Machado wrote:
> When you talk about the cost, do you mean backward compatibility?
The time taken to do it, the duplicated code until the deprecated code
can be removed, the cost of downstream users updating their code.
All for a minimal maintenance benefit.
Overall, that isn't something I'm interested in pursuing. That doesn't
mean someone else won't be interested. Just that I'm not.
Mark
>
>
> 2017-08-02 4:38 GMT-03:00 Mark Thomas <ma...@apache.org>:
>
>> On 02/08/2017 00:02, João Paulo Lemes Machado wrote:
>>> Hi Mark.
>>>
>>> Did you take a look at my suggestion?
>>
>> Yes. I don't think the cost is worth the benefit.
>>
>> Mark
>>
>>
>>>
>>> 2017-07-25 15:33 GMT-03:00 João Paulo Lemes Machado <
>> lemesmachado@gmail.com>
>>> :
>>>
>>>> Hi Mark, tanks for the comment.
>>>>
>>>> Let me take the DataSourceProxy as example.
>>>>
>>>> This class has 142 methods of which 112 are get () and set () methods.
>>>> We could mark these methods as deprecated and copy them to a new class:
>>>> DataSourceProxyConfig, but we would leave them in the DataSourceProxy
>> class,
>>>> and they would be removed gradually.
>>>>
>>>> Those parameters and methods would be accessed by an instance variable
>> of
>>>> DataSourceProxyConfig in DataSourceProxy.
>>>>
>>>> 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.
>>>>
>>>> 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.
>>>>
>>>>
>>>> And if for some reason we can not make these changes (remove the
>> methods),
>>>> this strategy can be adopted to prevent these classes from growing even
>>>> more. It can also be adopted as a new practice for creating new classes
>> in
>>>> the future.
>>>>
>>>>
>>>> What do you think?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 2017-07-25 10:40 GMT-03:00 Mark Thomas <ma...@apache.org>:
>>>>
>>>>> On 25/07/17 13:55, João Paulo Lemes Machado wrote:
>>>>>> 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 Tomcat, and I
>>>>>> identified some opportunities for cohesion improvement in the
>> following
>>>>>> classes:
>>>>>>
>>>>>> DataSourceProxy
>>>>>> ConnectionPool
>>>>>> BasicDataSource
>>>>>> DelegatingCallableStatement
>>>>>> PoolProperties
>>>>>> PoolConfiguration
>>>>>
>>>>> Those look to be from a mix of implementations (Commons DBCP and
>>>>> Tomcat's jdbc-pool).
>>>>>
>>>>> This is the place to discuss changes to Tomcat's jdbc-pool. DBCP
>> changes
>>>>> should be discussed on the Apache Commons dev mailing list.
>>>>>
>>>>>> Could you please take a look and tell me if it's viable?
>>>>>
>>>>> Hard to comment without a concrete example.
>>>>>
>>>>>> Maybe some of these classes could benefit from some kind of
>> refactoring
>>>>>> that we can discuss.
>>>>>
>>>>> Maybe. What did you have in mind?
>>>>>
>>>>> Mark
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Opportunities for cohesion improvement and refatoring
Posted by João Paulo Lemes Machado <le...@gmail.com>.
When you talk about the cost, do you mean backward compatibility?
2017-08-02 4:38 GMT-03:00 Mark Thomas <ma...@apache.org>:
> On 02/08/2017 00:02, João Paulo Lemes Machado wrote:
> > Hi Mark.
> >
> > Did you take a look at my suggestion?
>
> Yes. I don't think the cost is worth the benefit.
>
> Mark
>
>
> >
> > 2017-07-25 15:33 GMT-03:00 João Paulo Lemes Machado <
> lemesmachado@gmail.com>
> > :
> >
> >> Hi Mark, tanks for the comment.
> >>
> >> Let me take the DataSourceProxy as example.
> >>
> >> This class has 142 methods of which 112 are get () and set () methods.
> >> We could mark these methods as deprecated and copy them to a new class:
> >> DataSourceProxyConfig, but we would leave them in the DataSourceProxy
> class,
> >> and they would be removed gradually.
> >>
> >> Those parameters and methods would be accessed by an instance variable
> of
> >> DataSourceProxyConfig in DataSourceProxy.
> >>
> >> 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.
> >>
> >> 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.
> >>
> >>
> >> And if for some reason we can not make these changes (remove the
> methods),
> >> this strategy can be adopted to prevent these classes from growing even
> >> more. It can also be adopted as a new practice for creating new classes
> in
> >> the future.
> >>
> >>
> >> What do you think?
> >>
> >>
> >>
> >>
> >>
> >> 2017-07-25 10:40 GMT-03:00 Mark Thomas <ma...@apache.org>:
> >>
> >>> On 25/07/17 13:55, João Paulo Lemes Machado wrote:
> >>>> 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 Tomcat, and I
> >>>> identified some opportunities for cohesion improvement in the
> following
> >>>> classes:
> >>>>
> >>>> DataSourceProxy
> >>>> ConnectionPool
> >>>> BasicDataSource
> >>>> DelegatingCallableStatement
> >>>> PoolProperties
> >>>> PoolConfiguration
> >>>
> >>> Those look to be from a mix of implementations (Commons DBCP and
> >>> Tomcat's jdbc-pool).
> >>>
> >>> This is the place to discuss changes to Tomcat's jdbc-pool. DBCP
> changes
> >>> should be discussed on the Apache Commons dev mailing list.
> >>>
> >>>> Could you please take a look and tell me if it's viable?
> >>>
> >>> Hard to comment without a concrete example.
> >>>
> >>>> Maybe some of these classes could benefit from some kind of
> refactoring
> >>>> that we can discuss.
> >>>
> >>> Maybe. What did you have in mind?
> >>>
> >>> Mark
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >>> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>>
> >>>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Opportunities for cohesion improvement and refatoring
Posted by Christopher Schultz <ch...@christopherschultz.net>.
João Paulo,
On 8/4/17 1:52 PM, João Paulo Lemes Machado wrote:
> 2017-08-02 17:41 GMT-03:00 Christopher Schultz <chris@christopherschultz.net
>> :
>
> Mark and João,
>
> On 8/2/17 3:38 AM, Mark Thomas wrote:
>>>> On 02/08/2017 00:02, João Paulo Lemes Machado wrote:
>>>>> Hi Mark.
>>>>>
>>>>> Did you take a look at my suggestion?
>>>>
>>>> Yes. I don't think the cost is worth the benefit.
>>
>> +1
>>
>> So what if the class has 61 properties? If you divide it into a "doer"
>> class and a "configurator" class, you'll have two classes, one of
>> which has 61 properties and the other of which can't do anything
>> without /yet another/ object being available to configure it.
>>
>> Then again, you're talking to someone who thinks Fluent is an
>> abomination.
>
> Hi Christopher thank you for the comment.
>
> Sorry I did not understand. What do you mean by Fluent?
Fluent f = BuilderObjects.which(create())
.objectsWith(complicated.naturalLanguageSoundingNames())
.and(runOnSentences())
.resultingIn(multiline.spaghettiCode())
.with(not(comprehensible().objectStructure()))
;
https://en.wikipedia.org/wiki/Fluent_interface
For an excellent example, see the EasyMock Java mock-object API.
-chris
>>>>> 2017-07-25 15:33 GMT-03:00 João Paulo Lemes Machado
>>>>> <le...@gmail.com> :
>>>>>
>>>>>> Hi Mark, tanks for the comment.
>>>>>>
>>>>>> Let me take the DataSourceProxy as example.
>>>>>>
>>>>>> This class has 142 methods of which 112 are get () and set ()
>>>>>> methods. We could mark these methods as deprecated and copy
>>>>>> them to a new class: DataSourceProxyConfig, but we would leave
>>>>>> them in the DataSourceProxy class, and they would be removed
>>>>>> gradually.
>>>>>>
>>>>>> Those parameters and methods would be accessed by an instance
>>>>>> variable of DataSourceProxyConfig in DataSourceProxy.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>
>>>>>> And if for some reason we can not make these changes (remove
>>>>>> the methods), this strategy can be adopted to prevent these
>>>>>> classes from growing even more. It can also be adopted as a new
>>>>>> practice for creating new classes in the future.
>>>>>>
>>>>>>
>>>>>> What do you think?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2017-07-25 10:40 GMT-03:00 Mark Thomas <ma...@apache.org>:
>>>>>>
>>>>>>> On 25/07/17 13:55, João Paulo Lemes Machado wrote:
>>>>>>>> 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
>>>>>>>> Tomcat, and I identified some opportunities for cohesion
>>>>>>>> improvement in the following classes:
>>>>>>>>
>>>>>>>> DataSourceProxy ConnectionPool BasicDataSource
>>>>>>>> DelegatingCallableStatement PoolProperties
>>>>>>>> PoolConfiguration
>>>>>>>
>>>>>>> Those look to be from a mix of implementations (Commons DBCP
>>>>>>> and Tomcat's jdbc-pool).
>>>>>>>
>>>>>>> This is the place to discuss changes to Tomcat's jdbc-pool.
>>>>>>> DBCP changes should be discussed on the Apache Commons dev
>>>>>>> mailing list.
>>>>>>>
>>>>>>>> Could you please take a look and tell me if it's viable?
>>>>>>>
>>>>>>> Hard to comment without a concrete example.
>>>>>>>
>>>>>>>> Maybe some of these classes could benefit from some kind of
>>>>>>>> refactoring that we can discuss.
>>>>>>>
>>>>>>> Maybe. What did you have in mind?
>>>>>>>
>>>>>>> Mark
>>>>>>>
>>>>>>> -------------------------------------------------------------------
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
Re: Opportunities for cohesion improvement and refatoring
Posted by João Paulo Lemes Machado <le...@gmail.com>.
Hi Christopher thank you for the comment.
Sorry I did not understand. What do you mean by Fluent?
2017-08-02 17:41 GMT-03:00 Christopher Schultz <chris@christopherschultz.net
>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Mark and João,
>
> On 8/2/17 3:38 AM, Mark Thomas wrote:
> > On 02/08/2017 00:02, João Paulo Lemes Machado wrote:
> >> Hi Mark.
> >>
> >> Did you take a look at my suggestion?
> >
> > Yes. I don't think the cost is worth the benefit.
>
> +1
>
> So what if the class has 61 properties? If you divide it into a "doer"
> class and a "configurator" class, you'll have two classes, one of
> which has 61 properties and the other of which can't do anything
> without /yet another/ object being available to configure it.
>
> Then again, you're talking to someone who thinks Fluent is an abominatio
> n.
>
> - -chris
>
> >> 2017-07-25 15:33 GMT-03:00 João Paulo Lemes Machado
> >> <le...@gmail.com> :
> >>
> >>> Hi Mark, tanks for the comment.
> >>>
> >>> Let me take the DataSourceProxy as example.
> >>>
> >>> This class has 142 methods of which 112 are get () and set ()
> >>> methods. We could mark these methods as deprecated and copy
> >>> them to a new class: DataSourceProxyConfig, but we would leave
> >>> them in the DataSourceProxy class, and they would be removed
> >>> gradually.
> >>>
> >>> Those parameters and methods would be accessed by an instance
> >>> variable of DataSourceProxyConfig in DataSourceProxy.
> >>>
> >>> 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.
> >>>
> >>> 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.
> >>>
> >>>
> >>> And if for some reason we can not make these changes (remove
> >>> the methods), this strategy can be adopted to prevent these
> >>> classes from growing even more. It can also be adopted as a new
> >>> practice for creating new classes in the future.
> >>>
> >>>
> >>> What do you think?
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> 2017-07-25 10:40 GMT-03:00 Mark Thomas <ma...@apache.org>:
> >>>
> >>>> On 25/07/17 13:55, João Paulo Lemes Machado wrote:
> >>>>> 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
> >>>>> Tomcat, and I identified some opportunities for cohesion
> >>>>> improvement in the following classes:
> >>>>>
> >>>>> DataSourceProxy ConnectionPool BasicDataSource
> >>>>> DelegatingCallableStatement PoolProperties
> >>>>> PoolConfiguration
> >>>>
> >>>> Those look to be from a mix of implementations (Commons DBCP
> >>>> and Tomcat's jdbc-pool).
> >>>>
> >>>> This is the place to discuss changes to Tomcat's jdbc-pool.
> >>>> DBCP changes should be discussed on the Apache Commons dev
> >>>> mailing list.
> >>>>
> >>>>> Could you please take a look and tell me if it's viable?
> >>>>
> >>>> Hard to comment without a concrete example.
> >>>>
> >>>>> Maybe some of these classes could benefit from some kind of
> >>>>> refactoring that we can discuss.
> >>>>
> >>>> Maybe. What did you have in mind?
> >>>>
> >>>> Mark
> >>>>
> >>>> -------------------------------------------------------------------
> - --
> >>>>
> >>>>
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> >>>> For additional commands, e-mail: dev-help@tomcat.apache.org
> >>>>
> >>>>
> >>>
> >>
> >
> >
> > ---------------------------------------------------------------------
> >
> >
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJZgjjcAAoJEBzwKT+lPKRYtxEQAMBZIOujH7GHCP77aOe+D9cY
> zHmTKfeppTzxD6fCpXFmfnhMLZg7aCf7zHXR/PtMcrwZvyqJdRSOqlBr2LpENx7a
> xpJfNUnGZ2FPdfkxXsC12ZO0fs/jya+rIrQRo9F0uVJ6AY11gN9y1piuyZv07A/1
> oct/MwXasapAU3OgiDW02HIGYgTHScKrY4GflgbQHH85JnyMJw094y3TX5zxX3M+
> er700ht4EL4+W3hZKmS/sE8gss1BCjvV1mzzq0Gs09YFNBaaoM4WWwKks4Euf0pX
> saJQY5q/UjJNqE97utUS00qXtVLUeW6h6DMn7Yup/QvX7iRzkR411hHvhvdulM1E
> cKH1U3uCqZsV3O3db/9DExzpZGRSoDEPrAc1rRl7zkJW8uj8bXFhYxaeoXvhajQ8
> 27FuT8ikJe1CGQTw48hXrHRrBBXq4M7j5OkB6b6TFk2tTiI+1m3jtOhZj360lt2H
> c6nJYo8tFoBPmOp3APgPa0lTpNoaV9oT1/GQx+/qAm6CwUBOxekzTT8cJ+ZhvZm1
> WLY3W1tFvQo+Jw5fYCRjPgres5EUMKzZgCr8Stqtl0oTx5RwnaxJDMbZikdtWp2D
> 0dga4ezp/D1SrgmVkzUt0ihP9olNa1wkBhkwxsDWPUPlnlfXuRU8dP1CPsIw91rY
> j5asNhZy8x6PgLNUzHfT
> =Ar0Z
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Opportunities for cohesion improvement and refatoring
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark and João,
On 8/2/17 3:38 AM, Mark Thomas wrote:
> On 02/08/2017 00:02, João Paulo Lemes Machado wrote:
>> Hi Mark.
>>
>> Did you take a look at my suggestion?
>
> Yes. I don't think the cost is worth the benefit.
+1
So what if the class has 61 properties? If you divide it into a "doer"
class and a "configurator" class, you'll have two classes, one of
which has 61 properties and the other of which can't do anything
without /yet another/ object being available to configure it.
Then again, you're talking to someone who thinks Fluent is an abominatio
n.
- -chris
>> 2017-07-25 15:33 GMT-03:00 João Paulo Lemes Machado
>> <le...@gmail.com> :
>>
>>> Hi Mark, tanks for the comment.
>>>
>>> Let me take the DataSourceProxy as example.
>>>
>>> This class has 142 methods of which 112 are get () and set ()
>>> methods. We could mark these methods as deprecated and copy
>>> them to a new class: DataSourceProxyConfig, but we would leave
>>> them in the DataSourceProxy class, and they would be removed
>>> gradually.
>>>
>>> Those parameters and methods would be accessed by an instance
>>> variable of DataSourceProxyConfig in DataSourceProxy.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>>
>>> And if for some reason we can not make these changes (remove
>>> the methods), this strategy can be adopted to prevent these
>>> classes from growing even more. It can also be adopted as a new
>>> practice for creating new classes in the future.
>>>
>>>
>>> What do you think?
>>>
>>>
>>>
>>>
>>>
>>> 2017-07-25 10:40 GMT-03:00 Mark Thomas <ma...@apache.org>:
>>>
>>>> On 25/07/17 13:55, João Paulo Lemes Machado wrote:
>>>>> 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
>>>>> Tomcat, and I identified some opportunities for cohesion
>>>>> improvement in the following classes:
>>>>>
>>>>> DataSourceProxy ConnectionPool BasicDataSource
>>>>> DelegatingCallableStatement PoolProperties
>>>>> PoolConfiguration
>>>>
>>>> Those look to be from a mix of implementations (Commons DBCP
>>>> and Tomcat's jdbc-pool).
>>>>
>>>> This is the place to discuss changes to Tomcat's jdbc-pool.
>>>> DBCP changes should be discussed on the Apache Commons dev
>>>> mailing list.
>>>>
>>>>> Could you please take a look and tell me if it's viable?
>>>>
>>>> Hard to comment without a concrete example.
>>>>
>>>>> Maybe some of these classes could benefit from some kind of
>>>>> refactoring that we can discuss.
>>>>
>>>> Maybe. What did you have in mind?
>>>>
>>>> Mark
>>>>
>>>> -------------------------------------------------------------------
- --
>>>>
>>>>
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>>
>>>>
>>>
>>
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJZgjjcAAoJEBzwKT+lPKRYtxEQAMBZIOujH7GHCP77aOe+D9cY
zHmTKfeppTzxD6fCpXFmfnhMLZg7aCf7zHXR/PtMcrwZvyqJdRSOqlBr2LpENx7a
xpJfNUnGZ2FPdfkxXsC12ZO0fs/jya+rIrQRo9F0uVJ6AY11gN9y1piuyZv07A/1
oct/MwXasapAU3OgiDW02HIGYgTHScKrY4GflgbQHH85JnyMJw094y3TX5zxX3M+
er700ht4EL4+W3hZKmS/sE8gss1BCjvV1mzzq0Gs09YFNBaaoM4WWwKks4Euf0pX
saJQY5q/UjJNqE97utUS00qXtVLUeW6h6DMn7Yup/QvX7iRzkR411hHvhvdulM1E
cKH1U3uCqZsV3O3db/9DExzpZGRSoDEPrAc1rRl7zkJW8uj8bXFhYxaeoXvhajQ8
27FuT8ikJe1CGQTw48hXrHRrBBXq4M7j5OkB6b6TFk2tTiI+1m3jtOhZj360lt2H
c6nJYo8tFoBPmOp3APgPa0lTpNoaV9oT1/GQx+/qAm6CwUBOxekzTT8cJ+ZhvZm1
WLY3W1tFvQo+Jw5fYCRjPgres5EUMKzZgCr8Stqtl0oTx5RwnaxJDMbZikdtWp2D
0dga4ezp/D1SrgmVkzUt0ihP9olNa1wkBhkwxsDWPUPlnlfXuRU8dP1CPsIw91rY
j5asNhZy8x6PgLNUzHfT
=Ar0Z
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Opportunities for cohesion improvement and refatoring
Posted by Mark Thomas <ma...@apache.org>.
On 02/08/2017 00:02, João Paulo Lemes Machado wrote:
> Hi Mark.
>
> Did you take a look at my suggestion?
Yes. I don't think the cost is worth the benefit.
Mark
>
> 2017-07-25 15:33 GMT-03:00 João Paulo Lemes Machado <le...@gmail.com>
> :
>
>> Hi Mark, tanks for the comment.
>>
>> Let me take the DataSourceProxy as example.
>>
>> This class has 142 methods of which 112 are get () and set () methods.
>> We could mark these methods as deprecated and copy them to a new class:
>> DataSourceProxyConfig, but we would leave them in the DataSourceProxy class,
>> and they would be removed gradually.
>>
>> Those parameters and methods would be accessed by an instance variable of
>> DataSourceProxyConfig in DataSourceProxy.
>>
>> 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.
>>
>> 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.
>>
>>
>> And if for some reason we can not make these changes (remove the methods),
>> this strategy can be adopted to prevent these classes from growing even
>> more. It can also be adopted as a new practice for creating new classes in
>> the future.
>>
>>
>> What do you think?
>>
>>
>>
>>
>>
>> 2017-07-25 10:40 GMT-03:00 Mark Thomas <ma...@apache.org>:
>>
>>> On 25/07/17 13:55, João Paulo Lemes Machado wrote:
>>>> 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 Tomcat, and I
>>>> identified some opportunities for cohesion improvement in the following
>>>> classes:
>>>>
>>>> DataSourceProxy
>>>> ConnectionPool
>>>> BasicDataSource
>>>> DelegatingCallableStatement
>>>> PoolProperties
>>>> PoolConfiguration
>>>
>>> Those look to be from a mix of implementations (Commons DBCP and
>>> Tomcat's jdbc-pool).
>>>
>>> This is the place to discuss changes to Tomcat's jdbc-pool. DBCP changes
>>> should be discussed on the Apache Commons dev mailing list.
>>>
>>>> Could you please take a look and tell me if it's viable?
>>>
>>> Hard to comment without a concrete example.
>>>
>>>> Maybe some of these classes could benefit from some kind of refactoring
>>>> that we can discuss.
>>>
>>> Maybe. What did you have in mind?
>>>
>>> Mark
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Opportunities for cohesion improvement and refatoring
Posted by João Paulo Lemes Machado <le...@gmail.com>.
Hi Mark.
Did you take a look at my suggestion?
2017-07-25 15:33 GMT-03:00 João Paulo Lemes Machado <le...@gmail.com>
:
> Hi Mark, tanks for the comment.
>
> Let me take the DataSourceProxy as example.
>
> This class has 142 methods of which 112 are get () and set () methods.
> We could mark these methods as deprecated and copy them to a new class:
> DataSourceProxyConfig, but we would leave them in the DataSourceProxy class,
> and they would be removed gradually.
>
> Those parameters and methods would be accessed by an instance variable of
> DataSourceProxyConfig in DataSourceProxy.
>
> 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.
>
> 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.
>
>
> And if for some reason we can not make these changes (remove the methods),
> this strategy can be adopted to prevent these classes from growing even
> more. It can also be adopted as a new practice for creating new classes in
> the future.
>
>
> What do you think?
>
>
>
>
>
> 2017-07-25 10:40 GMT-03:00 Mark Thomas <ma...@apache.org>:
>
>> On 25/07/17 13:55, João Paulo Lemes Machado wrote:
>> > 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 Tomcat, and I
>> > identified some opportunities for cohesion improvement in the following
>> > classes:
>> >
>> > DataSourceProxy
>> > ConnectionPool
>> > BasicDataSource
>> > DelegatingCallableStatement
>> > PoolProperties
>> > PoolConfiguration
>>
>> Those look to be from a mix of implementations (Commons DBCP and
>> Tomcat's jdbc-pool).
>>
>> This is the place to discuss changes to Tomcat's jdbc-pool. DBCP changes
>> should be discussed on the Apache Commons dev mailing list.
>>
>> > Could you please take a look and tell me if it's viable?
>>
>> Hard to comment without a concrete example.
>>
>> > Maybe some of these classes could benefit from some kind of refactoring
>> > that we can discuss.
>>
>> Maybe. What did you have in mind?
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
Re: Opportunities for cohesion improvement and refatoring
Posted by João Paulo Lemes Machado <le...@gmail.com>.
Hi Mark, tanks for the comment.
Let me take the DataSourceProxy as example.
This class has 142 methods of which 112 are get () and set () methods.
We could mark these methods as deprecated and copy them to a new class:
DataSourceProxyConfig, but we would leave them in the DataSourceProxy class,
and they would be removed gradually.
Those parameters and methods would be accessed by an instance variable of
DataSourceProxyConfig in DataSourceProxy.
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.
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.
And if for some reason we can not make these changes (remove the methods),
this strategy can be adopted to prevent these classes from growing even
more. It can also be adopted as a new practice for creating new classes in
the future.
What do you think?
2017-07-25 10:40 GMT-03:00 Mark Thomas <ma...@apache.org>:
> On 25/07/17 13:55, João Paulo Lemes Machado wrote:
> > 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 Tomcat, and I
> > identified some opportunities for cohesion improvement in the following
> > classes:
> >
> > DataSourceProxy
> > ConnectionPool
> > BasicDataSource
> > DelegatingCallableStatement
> > PoolProperties
> > PoolConfiguration
>
> Those look to be from a mix of implementations (Commons DBCP and
> Tomcat's jdbc-pool).
>
> This is the place to discuss changes to Tomcat's jdbc-pool. DBCP changes
> should be discussed on the Apache Commons dev mailing list.
>
> > Could you please take a look and tell me if it's viable?
>
> Hard to comment without a concrete example.
>
> > Maybe some of these classes could benefit from some kind of refactoring
> > that we can discuss.
>
> Maybe. What did you have in mind?
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Opportunities for cohesion improvement and refatoring
Posted by Mark Thomas <ma...@apache.org>.
On 25/07/17 13:55, João Paulo Lemes Machado wrote:
> 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 Tomcat, and I
> identified some opportunities for cohesion improvement in the following
> classes:
>
> DataSourceProxy
> ConnectionPool
> BasicDataSource
> DelegatingCallableStatement
> PoolProperties
> PoolConfiguration
Those look to be from a mix of implementations (Commons DBCP and
Tomcat's jdbc-pool).
This is the place to discuss changes to Tomcat's jdbc-pool. DBCP changes
should be discussed on the Apache Commons dev mailing list.
> Could you please take a look and tell me if it's viable?
Hard to comment without a concrete example.
> Maybe some of these classes could benefit from some kind of refactoring
> that we can discuss.
Maybe. What did you have in mind?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org