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 Mon, 14 Aug 2017 19:59:00 GMT
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
>>>>> <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
>>
>>
> 


Mime
View raw message