I’m trying to understand the solution provided but since the code is not in the same order as the questions given by the specs, I find it hard to understand what comes first and understand the logic behind everything.
I’m getting lost around in_fahrenheit and in_celsius methods. Why do i have to put self.class? What is the meaning for putting class?
You’ll see that we’re calling the
ctof method in
in_fahrenheit. The latter is an instance method - these are methods that belong to an instance of a given class, in this case any instance of Temperature or its child classes (Fahrenheit and Celsius).
ctof, however, is a class method - which belongs to the Temperature class. When I say that a method belongs to an instance or belongs to a class, I mean that
self inside the method is defined as the instance or the class (remember that
self is the receiver of the method).
Class methods cannot be directly called on an instance of the class; they must be called on the class itself. We use class methods to implement logic that does not belong to a particular instance, or to create new instances of the class (which is what we’re doing here). You can find more information about this in the “Classes 2” reading.
Hope this helps! Let me know if you have any more questions about class methods or the RSpec 4 Temperature exercise.
when tackling rspec problems such as this one, are there any tricks on where to start first? For example, in the solution it is really streamlined and incorporates the whole spec and what the spec asks towards the bottom, such as using ctof / ftoc is first in the solution. The way i’m doing it, is that I try to code the first part of the “question” and keep on adding more code as I read down the spec.
It sounds like you’re doing it exactly right! You can only try to solve the problem as it’s presented to you. That usually involves writing some code to pass a spec, then adding code and refactoring your previous code to pass later specs. The solution is presented as a complete solution to all of the specs, not incrementally for each spec.
The type of problem-solving you’re describing is crucial to test-driven development, or TDD. Write the code to pass a spec you or someone else has written, then add to it and/or refactor to pass the next spec as well. We’ll learn more about this in the main course.
Bump. There really needs to be a video walk through for this. Kind of surprised/annoyed that there seems to be walkthroughs for the easy stuff, but when you get to the harder exercises, where much of the exercise references stuff that either wasn’t mentioned in the curriculum, or it is brought up after the exercise (how/why that happens boggles me), there is no walkthrough.