Re: Opportunities for cohesion improvement and refatoring
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 > >>>> > >>>> &g
Re: Opportunities for cohesion improvement and refatoring
When you talk about the cost, do you mean backward compatibility? 2017-08-02 4:38 GMT-03:00 Mark Thomas <ma...@apache.org>: > 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. > > Mark > > > > > > 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 > >
Re: Opportunities for cohesion improvement and refatoring
Hi Mark. Did you take a look at my suggestion? 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 >> >> >
Re: Opportunities for cohesion improvement and refatoring
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 > >
Opportunities for cohesion improvement and refatoring
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 Could you please take a look and tell me if it's viable? Maybe some of these classes could benefit from some kind of refactoring that we can discuss.
