tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Opportunities for cohesion improvement and refatoring
Date Wed, 02 Aug 2017 20:41:00 GMT
-----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
>> <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 <markt@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


Mime
View raw message