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 <ch...@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
>>>>> <lemesmach...@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-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: dev-h...@tomcat.apache.org
>>
>>
>
signature.asc
Description: OpenPGP digital signature
