trying to use polymorphism

[danielea]

Hi, I am trying to understand polymorphism and if it can help me in this situation. I have a third party framework that handles Secure FTP functions. Within this framework I am working with two main classes (FTP) which handles FTPSSL over http, and (SFTP) which handles accessing the secure FTP server over the file system. What I would like to do is wrap both of these FTP classes so that I have one class that I would instantiate and in the constructor pass in which type of ftp access i need. It in turn in the constructor instantiate a class level variable that I can use throughout my class methods without having to cast back and forth from object. My instincts tell me that I can use polymorphism somehow, but I can't figure it out. If you need more info, please let me know.

My wapper class would look something like this: however declaring it as object forces me to cast back to SFTP or FTP everytime I use it which defeats the purpose of making the variable name loosely coupled with the methods in my class.

#
public class myFTPHandler
{
private object ftpHandler;

public enum FTPType
{
FTP,
SFTP
}

public myFTPHandler(FTPType ftpType)
{
switch(ftpType)
{
case FTPType.FTP:
ftpHandler = new SFTP();
break;
case FTPType.SFTP:
ftpHandler = new SFTP();
break;
default:
break;
}
}

public void MyMethod1(string userName, string password)
{
ftpHandler.Login(userName, password);
}
}
#

[BigEd781]

Your description is the complete opposite of polymorphism. This is exactly the problem that polymorphism attempts to solve. You don't need all of these switches on a type, you need a well defined interface and classes that implement that interface. Your code would turn into something like this:

interface IFTPHandler
{
    void Authenticate(string username, string password);
}

class SFTPHandler : IFTPHandler
{
    void Authenticate(string username, string password)
    {
        // authenticate using SFTP
    }
}


class FTPHandler : IFTPHandler
{
    void Authenticate(string username, string password)
    {
        // authenticate using standard FTP
    }
}

void Main(...)
{ 
    IFTPHandler handler = // figure out if you need to create an instance of FTPHandler or SFTPHandler and use the interface object to call method
    handler.Authenticate( username, pswd );  // which one will be called?  We don't care!  That's polymorphism
}

I don't even know for sure that your use case is good for this. You could probably isolate the connection logic into one method and just use one class. I don't know, I haven't done this before. However, my example shows that you don't need to check a type, you just need to create a different concrete instance and assign it to an instance of the interface. The correct methods will be called and your code will be nice and clean.

[danielea]

Thank you. your explanation helped me to understand this concept much better. I've used this as a base to implement exactly what i needed.

Again, thank you.

[BigEd781]

No problem. An even more obvious example (though contrived) would be this:

interface IMakeNoise
{
    void MakeNoise();
}

class Dog : IMakeNoise
{
    public void MakeNoise()
    {
        Console.WriteLine("Woof!");
    }
}


class Bomb : IMakeNoise
{
    public void MakeNoise()
    {
        Console.WriteLine("Boom!");
    }
}


class CarHorn : IMakeNoise
{
    public void MakeNoise()
    {
        Console.WriteLine("Honk!");
    }
}

void Main(string[] args)
{
    IMakeNoise noiseMaker = new Dog();
    noiseMaker.MakeNoise();  // prints "Woof!"


    noiseMaker = new Bomb();
    noiseMaker.MakeNoise();  // prints "Boom!"


    noiseMaker = new CarHorn();
    noiseMaker.MakeNoise();  // prints "Honk!"
}

Of course, in real code the classes that implement a given interface will logically have a connection. They will produce different behavior but will share a set of methods (hence the term "interface"). You can also define an interface by using an abstract class. This is useful when some classes share a partial implementation, but need to customize their behavior as well. In the rest of your code you can now pass the objects around generically through their interface alone but get the specific behavior that you need in different situations.

[TheGreatCthulhu]

Just a thing or two to add.
Because C# interfaces were used in the explanations, it might make you think that you should use them always or most of the time. However, I'd like to highlight a sentence from BigEd781's last reply, in case you didn't read it more carefully: "You can also define an interface by using an abstract class".

Here, the word "interface" is used in a more general sense - meaning "a set of behaviors" or "what a class can do."

With polymorphism, and inheritance, you have two choices : (1) C# interfaces - which define only public methods/properties, but not implementations, and (2) base classes, which may also be abstract, allowing for implementation details.

Now, when to favor one over the other?
Well, developers have different opinions on this...
Read this MSDN article for starters: Recommendations for Abstract Classes vs. Interfaces.
Also, as a guideline, while you work, observe how abstract classes and interfaces are used in the .NET framework itself.
You're probably not going to understand difference between using the two right away - don't worry about that; follow the Microsoft's recommendations for the time being, until you develop your own view.

[BigEd781]

exactly, thanks Cthulu. I always have a hard time explaining the difference between a a type's conceptual "interface" and the "interface" keyword in C#. Would vote you up on that if I could.

[TheGreatCthulhu]

exactly, thanks Cthulu. I always have a hard time explaining the difference between a a type's conceptual "interface" and the "interface" keyword in C#. Would vote you up on that if I could.

It's OK.

BTW: Compiler Error: The identifier or identifier substring 'Cthulu' could not be found. Is a character missing?