Java OOP Temperature Converter

Question

I am doing a college exercise and would like to know how to improve the execution of the idea. The idea is to create a program that converts temperature measurements.

Main.java

package app.cnv;

public class Main {
  public static void main(String[] args) {
    Celsius celsius = new Celsius(37);

    System.out.println(celsius.convert(new Fahrenheit()));

    Fahrenheit fahrenheit = new Fahrenheit(98.6);

    try {
      System.out.println(fahrenheit.convert(new Celsius()));
    } catch (AbsoluteZeroException e) {
      System.out.println(e.getMessage());
    }
  }
}

Temperature.java

package app.cnv;

public abstract class Temperature {
  public abstract double convert(Temperature to) throws AbsoluteZeroException;
}

Celsius.java

package app.cnv;

public class Celsius extends Temperature {
  double celsius;

  Celsius() {
  }

  Celsius(double celsius) {
    this.celsius = celsius;
  }

  @Override
  public double convert(Temperature to) {
    if (to instanceof Fahrenheit) {
      return (celsius * 9) / 5 + 32;
    }
    return celsius;
  }
}

Fahrenheit.java

package app.cnv;

public class Fahrenheit extends Temperature {
  double fahrenheit;

  Fahrenheit() {
  }

  Fahrenheit(double fahrenheit) {
    this.fahrenheit = fahrenheit;
  }

  @Override
  public double convert(Temperature to) throws AbsoluteZeroException {
    if (to instanceof Celsius) {
      if (fahrenheit < -459.67) {
        throw new AbsoluteZeroException("The temperature cannot be less than absolute zero.");
      } else {
        return ((fahrenheit - 32) * 5) / 9;
      }
    }
    return fahrenheit;
  }
}

AbsoluteZeroException.java

package app.cnv;

public class AbsoluteZeroException extends Exception {
  public AbsoluteZeroException(String err) {
    super(err);
  }
}

Answer 1

What if I add a class Kelvin without modifying the other classes? When I convert Celsius to Kelvin then, your code says that 20 °C = 20 K, which is simply wrong.

Your whole approach is doomed to fail. What you should do instead is to define one reference temperature scale. I would take Kelvin for that. Then, for every other temperature scale, have methods fromKelvin and toKelvin. That's all. This approach is well-known from constructing compilers, which has the same problem of several similar source languages and several different target machines.

For converting between arbitrary temperature scales you can have a helper method in the Temperature class like this:

public static Temperature convert(Temperature from, TemperatureScale to) {
    double kelvin = from.toKelvin();
    return to.fromKelvin(kelvin);
}

You can see that there are two completely different classes involved:

1. A temperature scale, like Kelvin or Fahrenheit
2. A specific temperature, consisting of a temperature scale and a value, like 293 Kelvin

---

Regarding the exception class: There is no good reason to give it a String parameter. The name of the class is already expressive enough. Therefore you should remove that parameter and just throw new AbsoluteZeroException(). You should probably rename it to BelowAbsoluteZeroException. Or you should just take the predefined IllegalArgumentException and be fine. In many cases you don't need to invent your own exception classes.

Answer 2

Using 2 classes here doesn't make sense.

Every time you add another class, you'll have to modify every classes conversion method.

There is a tight coupling between Celsius & Fahrenheit. You are using an instance of Fahrenheit to determine the type you want to convert to. This isn't necessary.

Note: In programming you want low coupling, high cohesion. Lots of information is available online

Temperatures would work better as an ENUM. Then you can do something like:

Tempature tempatureCels = new Tempature(98.6, TempatureType.CELSIUS);
Tempature tempatureFahrenheit = Tempature.convert(tempatureCels, TempatureType.FAHRENHEIT);

Answer 3

You might follow the example of java.util.Date. The internal representation of a Date is always in UTC, and it's converted to other time zones and date formats as needed. Similarly, you could define a Temperature class that is always in Kelvin, and a TemperatureScale interface with as many implementations as you like to perform conversions and formatting.

Answer 4

This is a hard question to answer because this problem is so simple it simply does not need an object-oriented solution. You'd be much better just writing two methods named convertCToF and convertFToC which will throw an Exception at absolute zero (if you desire).

Critique:

• You should make your Constructor(...) methods public, as per convention
• There is no need for empty constructors.
• If you are going the object-oriented route in Java, it's best practice to use encapsulation and declare member fields to be private and write get and set methods for said fields.
• You could instead declare an interface with a method called convert and attach them to your classes, that way it will be mandatory to implement a convert method rather than having to use @Override

But overall you really need to reconsider if you actually need to use OOP for this. See this video covering the overuse of class in Python. https://www.youtube.com/watch?v=o9pEzgHorH0

Answer 5

All this criticism of the object model is well founded, but don't forget that this is a college exercise. College exercises sometimes ask you to do something problematic so you can understand why it's problematic. A classic example of this is bubble sort. So I wouldn't focus on that too much unless you're in a relatively advanced programming course.

The first thing that leaps out at me is that you have classes Fahrenheit and Celsius, but your convert method doesn't return instances of those classes; it returns a double. The pattern of passing a valueless instance of Fahrenheit or Celsius to the conversion method to indicate the desired units of the function's double output function is profoundly unidiomatic for OOP. I suspect that your professor is after a conversion method that converts an instance of Fahrenheit to an instance of Celsius that represents the same temperature.

You might have

public abstract class Temperature {
  public abstract Celsius toCelsius();
  public abstract Fahrenheit toFahrenheit();
}

public class Celsius extends Temperature {
  double celsius;

  Celsius() {
  }

  Celsius(double celsius) {
    this.celsius = celsius;
  }

  @Override
  public Celsius toCelsius() {
    return this;
  }

  @Override
  public Fahrenheit toFahrenheit() {
    return new Fahrenheit(celsius * 1.8 + 32);
  }
}

This isn't great object oriented design, but it might just be what your professor is looking for. If your class is more advanced, it's possible that the exercise is designed to teach a more advanced technique to support methods that convert from one class to another.

As suggested elsewhere, another approach might be to have a single temperature class that stores its magnitude in Kelvin and has factory methods like Temperature fromCelsius(double celsius) for constructing instances from a given system of units, and instance methods like double toCelsius() that return a value in a given system of units.

Answer 6

Enums are great for this sort of thing in my opinion, unless you want people to invent their own temperature representations. If you want full-fledged object oriented usage with method chaining etc., it's still possible with approach I present below (would require small changes tho). It all depends on a context you are gonna use it in. Since this is a college exercise, this fresh idea may 'broaden your horizons'.

enum Temperatures {
    KELVIN {
        public double toKelvin(double in) {
            return in;
        }

        public double fromKelvin(double inKelvin) {
            return inKelvin;
        }
    },
    CELSIUS {
        public double toKelvin(double in) {
            return in + 273.15;
        }

        public double fromKelvin(double inKelvin) {
            return inKelvin - 273.15;
        }
    }, 
    FAHRENHEIT {
        public double toKelvin(double in) {
            return (in + 459.67) * (5.0 / 9.0);
        }

        public double fromKelvin(double inKelvin) {
            return (inKelvin * (9.0 / 5.0)) - 459.67;
        }
    };

    abstract double toKelvin(double in);

    abstract double fromKelvin(double kelvin);

    public double convert(double in, Temperatures to) {
        double inKelvin = this.toKelvin(in);

        return to.fromKelvin(inKelvin);
    }
}

Then you can simply:

System.out.println(Temperatures.FAHRENHEIT.convert(95, Temperatures.CELSIUS));

Answer 7

In my opinion you should create a factory for creating a converter which would take an input of "source" scale and "target" scale, which would basically return a converter that first converts it to kelvin and only then to target scale. For example, the factory interface would be the following:

void addConverter(Converter c);
Converter getConverter(Scale from, Scale to)

Meanwhile the converter abstract interface would be the following:

public Temperature convert(Temperature from); 

And then implement the converter in pairs: CelsiusKelvinConverter and KelvinCelsiusConverter.

In addition: avoid casting. If you need to cast, your interface is flawed.

Regardless, if you were to ask anyone, odds are they will have a different opinion regarding the matter. My suggestion is asking about and making your conclusions.