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