Problem with polymorphism

Putting aside any opinion on what is the best way to implement the converter, this would be the implementation of the way it suggests in the question.

Interface that each "temperature unit" should implement:

public interface ITempertureUnit
{
    double FromKelvin(double value);
    double ToKelvin(double value);
}

Methods should implement unit conversion from and to Kelvin

Implementation of units Celsius, Kelvin and Farenheit

public class Celsius : ITempertureUnit
{
    public double FromKelvin(double value)
    {
        return value - 273.15;
    }
    public double ToKelvin(double value)
    {
        return value + 273.15;
    }
}

public class Kelvin : ITempertureUnit
{
    public double FromKelvin(double value)
    {
        return value;
    }
    public double ToKelvin(double value)
    {
        return value;
    }
}

public class Farenheit : ITempertureUnit
{

    public double FromKelvin(double value)
    {
        return value * 1.8 - 459.67;
    }
    public double ToKelvin(double value)
    {
        return (value + 459.67) / 1.8;
    }

}

Converter implementation:

public static class Converter
{
    public static double Convert(double value, ITempertureUnit from, ITempertureUnit to)
    {
        return to.FromKelvin(from.ToKelvin(value));
    }
}

Mode usage:

double valor = Converter.Convert(100, new Celsius(), new Farenheit());

See working on ideone

The answers obtained are all very good and already provide much of what the AP needs to learn, considering that the need for it is in learning the concepts of interfaces and polymorphism. Still, as these concepts are part of a larger concept (from orientation to Object), I thought it was worth providing a complementary answer (with a suggestion of alternative implementation without inheritance or polymorphism).

In other words, I just I offer here a complementary description with the solution already proposed by @Maniero in his answer when he mentions:

"[...] but the classes of temperature units would have to be completely different, starting with the fact that they really are objects of temperature and not just a vehicle for methods that do not make sense."

It's okay that you're learning. But essentially I agree with @Maniero about you being using something unnecessarily and therefore misguided.

The Temperature is an entity that is more for an attribute (a value used in some other context, perhaps even in another class) than a class itself. It makes very little sense to think of temperature as a class because it would have no behavior (something it would literally "do", and that would be implemented in the form of object-oriented methods). You have the need to convert temperature values according to different units, but it is somewhat forced to transform these conversion functions into methods because these conversions are not really behaviors of a temperature class (or any class inherited from it). In fact, inheriting from a base class (or even an interface) "temperature" also sounds strange, because there is not even any specialization to be done in the child classes!

That way, if you keep in mind that the temperature is more for a value or an attribute than for a class itself, it may be easier to see that your problem is not about polymorphism, but about representation . That is, how would you represent a temperature so that it is easily converted into different units?

Thus, a possible solution is to implement a class that represents a temperature. Internally she does it the way her developer wish. It's a black box. That is, it does not matter how she stores the value, as long as it is easily accessible from outside and in any of the units. Yeah, this implementation will be a class anyway, but there's no polymorphism involved because there's no inheritance. The " class "is just the way of implementing" a new type", which conceptually you can still continue to think of as a value or an attribute.

If you stop to think, there are countless examples that they do just that. The Class String itself, or the Class DateTime are like this. They implement a " structure "(and this name is quite conducive, even more than" class", although the implementation is in fact a class) that stores, represents, and handles that type of data more" complex " than a int or a float.

Well, having said that, consider this example of implementation in C#:

/**
 * Implementa uma classe genérica e geral para manipulação de temperaturas
 * EM DIFENRENTES UNIDADES. 
 */
public class Temperature
{
    /** Valor da temperatura (sempre em Celsius, por convenção minha). */
    private double m_dValue;

    /**
     * Construtor protegido, para evitar que a classe seja instanciada
     * diretamente. Para instanciação, deve-se utilizar os métodos
     * apropriados para cada unidade.
     * @param dValue Double com o valor da temperatura EM CELSIUS.
     */
    protected Temperature(double dValue)
    {
        m_dValue = dValue;
    }

    /**
     * Método estático de criação de temperaturas em Celsius. 
     * @param dValue Double com o valor da temperatura em Celsius.
     * @return Instância do objeto Temperature com a temperatura dada.
     */
    public static Temperature asCelsius(double dValue)
    {
        return (new Temperature(dValue));
    }

    /**
     * Método estático de criação de temperaturas em Fahrenheit. 
     * @param dValue Double com o valor da temperatura em Fahrenheit.
     * @return Instância do objeto Temperature com a temperatura dada.
     */
    public static Temperature asFahrenheit(double dValue)
    {
        Temperature oRet = new Temperature(0);
        oRet.Fahrenheit = dValue;
        return oRet;
    }

    /**
     * Método estático de criação de temperaturas em Kelvin. 
     * @param dValue Double com o valor da temperatura em Kelvin.
     * @return Instância do objeto Temperature com a temperatura dada.
     */
    public static Temperature asKelvin(double dValue)
    {
        Temperature oRet = new Temperature(0);
        oRet.Kelvin = dValue;
        return oRet;
    }

    /** Propriedade de acesso ao valor em Celsius. */
    public double Celsius
    {
        get { return m_dValue; }
        set { m_dValue = value; }
    }

    /** Propriedade de acesso ao valor em Fahrenheit. */
    public double Fahrenheit
    {
        get { return m_dValue * 1.8 + 32; }
        set { m_dValue = (value - 32) / 1.8; }
    }

    /** Propriedade de acesso ao valor em Fahrenheit. */
    public double Kelvin
    {
        get { return m_dValue + 273; }
        set { m_dValue = value - 273; }
    }

    /**
     * Implementação de exemplo do operator de soma.
     * @param t1 Instância da primeira temperatura.
     * @param t2 Instância da segunda temperatura.
     * @return Instância da temperatura com o resultado da soma. 
     */
    public static Temperature operator+(Temperature t1, Temperature t2)
    {
        return new Temperature(t1.Celsius + t2.Celsius);
    }

    /**
     * Retorna a representação da temperatura em string com todos os
     * valores em cada uma das unidades suportadas.
     * @return String com a representação da temperatura.
     */
    public override string ToString()
    {
        return string.Format("Temperatura: {0} °C ({1} °F ou {2} °K)", Celsius, Fahrenheit, Kelvin);
    }
}

Note that:

• The Constructor was made protected (protected) from it cannot be used directly (outside of this class). This is due to the fact that the signature of the constructor simply called Temperature with a value double is confusing. Note in other answers there is always something like fromKelvin(double value), since the name of the unit in the method name indicates the intent. In this case, I created static methods to construct a temperature from a given unit(asCelcius, asFahrenheit and asKelvin) in the same way, only instead of calling "from" ("de", in Portuguese) I I called it " as " because I want to convey the intention that it is not a conversion, but a creation. The "structure" internally turns to keep everything right.

• There are properties for accessing the values in the different units. Want to read or update in Kelvin? Just do x = t.Kelvin or t.Kelvin = x. Simple and straightforward (as if you were updating the day of a date by doing d.day = 10 in another such structure). Note that internally I I chose to keep the value in Celsius. Could I have a variable for each and always update all? It could, but it's unnecessary. Therefore, I always convert and keep in Celsius in updates, and convert to return in accesses if necessary.

• This approach gives room for other interesting things. If you overload an operator, you can do counts with temperatures, compare values, etc, in the same way as you would if you used double, but without worry about unity! I implemented the sum operator (operator+) to exemplify, in the code below.

Example of using Class Temperature:

class Program
{
    static void Main(string[] args)
    {
        Temperature t = Temperature.asCelsius(100);
        Console.WriteLine(t);

        t.Fahrenheit = 48;
        Console.WriteLine(t);

        t.Kelvin = 397;
        Console.WriteLine(t);

        Temperature t1 = Temperature.asKelvin(380);
        Temperature t2 = Temperature.asCelsius(22);
        Temperature t3 = Temperature.asFahrenheit(80);
        Console.WriteLine(t1 + t2 + t3);
    }
}

This program generates the following output (the last line shows the result of the sum t1 + t2 + t3 in the code above):

Temperatura: 100 °C (212 °F ou 373 °K)
Temperatura: 8,88888888888889 °C (48 °F ou 281,888888888889 °K)
Temperatura: 124 °C (255,2 °F ou 397 °K)
Temperatura: 155,666666666667 °C (312,2 °F ou 428,666666666667 °K)

@Maniero's answer is quite simple, but it does not solve an AP requirement that is to avoid using if.

To meet this requirement, you need to go a little further, eventually using interfaces like you tried in your initial solution. But fortunately C# has delegates, which allows you to store references for methods and dispenses with interfaces!

Then, considering this converter statement:

public static class TemperatureConverter 
{
    public double CelsiusToFahrenheit(double valor)  { //calcula aqui }
    public double CelsiusToKelvin(double valor) { //calcula aqui }
    public double FahrenheitToCelsius(double valor) { //calcula aqui }
    public double FahrenheitToKelvin(double valor) { //calcula aqui }
    public double KelvinToFahrenheit(double valor) { //calcula aqui }
    public double KelvinToCelsius(double valor) { //calcula aqui }
}

You can declare a dictionary that associates every possible user entry to a given conversion method, something like this:

delegate double TemperatureConvert(double valor);

static Dictionary<String, TemperatureConvert> converters = 
        new Dictionary<string, TemperatureConvert>
{
    {"CelsiusToFahrenheit", TemperatureConverter.CelsiusToFahrenheit},
    {"CelsiusToKelvin", TemperatureConverter.CelsiusToKelvin},
    {"FahrenheitToCelsius", TemperatureConverter.FahrenheitToCelsius},
    {"FahrenheitToKelvin", TemperatureConverter.FahrenheitToKelvin},
    {"KelvinToFahrenheit", TemperatureConverter.KelvinToFahrenheit},
    {"KelvinToCelsius", TemperatureConverter.KelvinToCelsius}
};

And then you select a converter from the user input, like this:

static void Main(string[] args)
{
    var temperature = double.Parse(args[0]);
    var conversor = args[1] + args[2] + args[3];

    var convertedTemperature = converters[conversor](temperature);

    Console.WriteLine(convertedTemperature);
}

Now this application can be invoked by passing the temperature, the original scale and the scale to be converted, more or less like this:

converter.exe 50 Fahrenheit To Celsius

And in this case the output will be the conversion implemented in the method FahrenheitToCelsius :-)

See working on ideone .

Of course you might want to worry about validations, case tolerance, etc. And of course also, in an application with a graphical interface, user inputs can be limited by using comboboxes, for example.

And if you want to exercise the use of interfaces (which is really unnecessary in this example), you can implement each converter in its own Class, All Implementing an interface common for the conversion method, and reference instances of the converters in the dictionary instead of just the conversion method.

If you used Java, for example, which does not support delegates, using interfaces would probably be a valid solution to avoid the ifs.