-----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
