Re: Connection::connect() interface is changing

Warren,
I'm not sure that writing a different constructor is a reason to make a subclass.

I think a better option would be to make a ConnectionFactory class like this:

class ConnectionFactory
{
public:

        virtual Connection createConnection() const = 0; };

with sub classes like this :

class TCPConnectionFactory : public ConnectionFactory {
public:

	TCPConnectionFactory(const TCPConnectionParms &);
	Connection createConnection() const;

I work with a lot of code where if a connection fails, the software needs to keep trying to do what it was doing so that when the fault is rectified the program starts working again by itselft. For this to work I create a connection whenever I need to do something, and don't just have the same connection open. In this type of code the above is useful. A reference to some ConnectionFactory can be passed deep into some code without it needing to know how exactly connections are established. I realise this may be a bit more OO than most c++ programmers will like, and that Connection probably isn't copyable (auto_ptr<Connection> ? ) so maybe just different functions that produce a Connection or different ctors on Connection, I don't thin there is a need for introducing different types of connection based on how they were created.

Alex

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.mysql.com Links announce benchmarks bugs certification cluster commits dotnet gui-tools internals java maxdb myodbc mysql mysqldoc packagers perl plusplus replication win32 Request more information about Pantek

On 14/07/2007, at 2:50 PM, Warren Young wrote:

> Warren Young wrote:

>>     class Connection ... {
>>     public:
>>         class TCP {
>>         public:
>>             TCP(host, user, port, etc...);
>>         }
>>         Connection(const TCP& tcp);
>>     #ifdef MYSQLPP_PLATFORM_WINDOWS
>>         class NamedPipes {
>>         public:
>>             NamedPipes();
>>         }
>>         Connection(const NamedPipes& np);
>>     #else
>>         class DomainSockets {
>>         public:
>>             DomainSockets(path);
>>         }
>>         Connection(const DomainSockets& ds);
>>     #endif
>>     }

>
> I'm a dunce.  The solution is staring me right in the face:  
> inheritance!  This is a perfect is-a relationship.  Just make one  
> lightweight subclass of Connection for each connection style.   
> Then, depending on how we're feeling about code compatibility, we  
> can either retain the candy machine ctor in the parent class, or  
> make Connection's ctor private and make the subclasses call  
> mysql_real_connect() themselves.
>
>

-- 
MySQL++ Mailing List
For list archives: 
http://lists.mysql.com/plusplus
To unsubscribe:    
http://lists.mysql.com/plusplus?unsub=lists@pantek.com