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 <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 > >> <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 > >>>> > >>>> > >>> > >> > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: dev-h...@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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
