Why use the same name as the property?

Hi Justin,

You've got a few questions in there, I'm going to focus on the last one "Should it not be named set changeOwner that way you do not need the getter function and the original property named owner can be accessed using dot notation?" and write a little about getters vs direct property access. (Feel free to reword the question if I've missed the mark on what you're trying to figure out.)

Without saying whether or not one style is better than the other (it will depend on the project and other factors) one of the principles of object oriented design is encapsulation. Encapsulation is a broad concept so I'm not going to cover it fully, but sometimes we want to restrict direct access to a member (e.g. owner) but have a getter return details about it.

It's not going to be necessary in every piece of code or made fully necessary in every example, but it's a worthwhile pattern to be able to recognise because it's very common. Especially in more strictly OOP languages.

For instance, say I have a large and complex Business Intelligence dashboard that executives look at to make decisions. We're a big company though, so I have some execs in the USA and some in China. A very small part of this dashboard program is a temperature display, maybe we're in food manufacturing and we want to chart how much more ice cream we sell as the temperature rises.

There's separate data science teams in the USA and China preparing these dashboards, and they're really more data people than programmers, so I don't want to expose everything to them. Moreover, USA uses Fahrenheit and China uses Celsius, and we need to be able both store the temperature for an hour in a region, and return that temperature using a common interface. Storing both a Celsius and Fahrenheit temperature would violate DRY and just feels clumsy.

Let's just say the China team wants to get the temperature for right now, we want to them to be able to call region.getTemperature(). we store our region.temperature value as a float using the Kelvin temperature scale. This allows us to within the getTemperature method check the local temperature scale setting and covert from Kelvin to the local scale (in this case Celsius for the China team). The USA team can also call the same method, and their dashboards will show the temperature in Fahrenheit.

If they were accessing region.temperature directly would they know it was in Kelvin? This is one (imperfect) example, but I hope it helps explain why these patterns get used.

To make the example a little more realistic we could say our object for each of our sales region manages querying a DB table where historical temperature data is stored and at a point in time we want the program to be able to find the temperature via a trusted weather API and run region.setTemperature(temp, datetime, tempScale) to store in the DB and have our data teams run region.getTemperature(datetime) to get historical temperature data, but that doesn't really add anything to the encapsulation example.