Multiple aspects for the same result with coding?

I have read that there are usually multiple ways to reach the same result when it comes to coding but is that actually true, or is there usually a reason to prefer one over the other?

Yes, that has been true in my experience. There are always arguments someone can make about preferring one approach over another. Often those arguments are subjective and depend a lot on context.

When explaining Computed Properties, Amit mentioned that we could either create a method to return the surface area or use a computed property.

In this example, does it matter which one is used? I would think they result in the same way but alas, I am newer to coding so I wanted to ask others who actually know :P

The example you mentioned is so simple that it doesn't matter. There are lots of small differences and concerns that come up in real programs. Methods can accept arguments, so if area depended on my favorite color and that wasn't already information stored within my shape, an argument would make sense: square.area(favoriteColor: Color.Red). That wouldn't be possible with a computed property.

As it stands, though, area doesn't depend on any arguments, so you're left with the superficial calling syntax difference between square.area and square.area().

Side note question - When you were starting out, did you have difficulty putting a certain syntax, method, functions, etc. into a real world solution? I overall seem to have difficulty knowing how I would actually use but maybe that will become clearer as I complete this track?

Yeah, things' utilities will become clearer as you have more opportunities to use them. I sometimes have the problem that I know how to do something without using new knowledge, so it's unclear if the new stuff is helpful at all. It's kind of like getting a rice cooker or electric kettle. Maybe I only drink tea, but then it also comes in handy when coffee drinkers visit. Or apparently you can use rice cookers to make huge, tall pancakes.

Hi Joe,

Thought I would drop my two cents again. I agree with krilnon as for the computed properties to an extent, however as far as performance goes it is more efficient to go with a computed property than using a separate method - but it really DOES NOT increase the overhead of the application in this case as it is such a small operation.

There are always going to be multiple ways to do something, when you are learning I think it is better to create something step by step so you know what you are doing. Then once you have reached your desired outcome, you can refactor it so that you are using fewer calls to methods or fewer if statements etc. As an example, im working on a separate C++ based cross platform application at the moment and I have been for the past few days creating a class which quite simply will layout some image elements on the screen in the same format with native controls depending on the device. So as you can imagine at the start there were a lot of if's for's and while's - however once I had it all working properly with the desired outcome I read through it and made it as efficient as I possibly could.

I speak about efficiency, but I don't think this is something to worry about until you are doing something UI or data intensive. A good example of efficiency is when you get to the part of the course that introduces you to GCD. If you were to do all the data processing tasks on the foreground thread it would make your UI sluggish (if heavy) - whereas placing them on the background increases efficiency. This kind of ties back to your question in that there are two ways to do a data processing task, in the foreground and in background thread, they both achieve the same outcome and do the same thing - just one is more efficient than the other.

Hope this helps, excuse the rambling! Jayden

however as far as performance goes it is more efficient to go with a computed property than using a separate method

What makes computed properties more efficient?