Application from a ConnectionPool implementation Design Pattern (4)
Ok, classmates, have you had any results for the "Li Si I'm thinking" on the last time?
Is our slogan? . . . . . .
"No tooth"!
NO! Is "user-supreme"!
Since the user has the possibility of forgetting, then our work is not doing well. Why do we do what they do not do or make mistakes?
Ok, let us know the wrong:
Public Interface Connectionman Extends PooledConnection.pool {
// In this interface, we no longer ask the programmer to package the Connection, they only need to return directly to the Connection object. In fact, programmers can completely forget to encapsulate this code.
/ / We will package the returned object.
Connection getConnection () throws SqlexCeption;
Void clear ();
Void CloseConnection (Connection CONN);
}
// Then, we use the Decorator class to encapsulate the return value.
Public Class Connectionman2ConnectionPool Implements ConnectionPool {
Public final connection getConnection () throws sqlexception {
Return PooledConnection.Decorate (man.getConnection (), man);
}
Public final void clear () {
Man.clear ();
}
PRIVATE FINAL CONNECTIONMAN MAN;
Private Connectionman2ConnectionPool (ConnectionMan Man) {
THIS.MAN = Man;
}
Public Static ConnectionPool Decorate (ConnectionMan Man) {
Return New Connectionman2ConnectionPool (Man);
}
}
In this way, programmers only need to implement an auxiliary Interface ConnectionMan. Do not consider encapsulation of Connection. Then use our Connectionman2ConnectionPool class to convert it to ConnectionPool, hand it over to the user of ConnectionPool. Yay!
"What should I do if I have forgotten to convert with Connectionman2ConnectionPool?"
Oh, don't forget, the compiler is not vegetarian. User is looking forward to ConnectionPool, and Li Si has only Connectionman, he can't think of it!
what? Today's homework?
Ah, let your parents write praise to the ajoo teacher. :)
joke. If that bit can find further refactor, welcome to point out!
