I am a Java dev for almost all of my programming (at least in the workplace) but I do some Unity for fun on the side. I have used C# properties many times and they are convenient to still provide encapsulation without having to write out getter and setter methods.
With that said, is there any disadvantage to writing actual getter and setter methods for fields instead (other than my time)? Assume this is within my personal Unity code for fun and not in any sort of work or shared dev environment.
C# properties are made of methods. Thus, by using methods instead of properties, you do not get any runtime advantages.
Instead it will be all about developer productivity and readability of your code.
Readability is for yourself too. In a few months when you forgot the details of your code and you need to modify it to fix a bug or add a new feature. Even if you do not care about that, you probably care about doing more with the same amount of code.
On the productivity side, we have that properties have the advantage of requiring to write less code. Much more if we are talking about auto-properties. About readability, they result in less verbose code (less Get, less Set and less ()).
Properties may also affect discoverability. As having getter and setters will result in the methods associated with the same field being separated in intellisense.
However, there are some arguments for methods. For instance, if setting a value can fail, you might want to use a method and return bool so you can communicate to the caller if the set failed. You could, in theory, get away with using a property... after all, the caller can read the property after setting it to check if the value was set. However, returning bool is a thread-safe ready API.
Another case is when the property has to do a long computation to return a value. Using a method conveys that it is doing something behind the scenes. Similarly, using a method instead of a property can convey that reading the value could have side effects (it is not pure). Addendum: This is not a hard rule. Yet, in general a method does something, it is an action. On the other hand, we expect to be able to read properties at any time without major consequences.
Finally, if you have a property that returns an array, it could be missed for an indexer. It is preferred to provide an actual indexer or use a method to avoid confusion.
By the way, Alan Kay, who coined the term object-oriented, does not like setters. Instead, state should be encapsulated. He said:
Lots of so called object oriented languages have setters and when you have a setter on an object you turned it back into a data structure.
For Alan Kay, letting third parties change the state of the object unexpectedly is a bad idea.
With that in mind, let met tell you about a couple cases where properties are a bad design:
Avoid providing properties as a mean to decide what to do. The caller code should not have to read properties of your object to decide what method to call. Instead encapsulate that logic in the methods of your class. That is, with object-oriented design, prefer Tell, Don't Ask.
Avoid properties that change the behavior of methods. If you have them, you will end up with code that backups the value of a property, change the value, calls the method, then restores the value. Instead add that value as a parameter to the method (even if you need to add it to virtually every method in the class). That makes for a much easier to use API, follows the principle of least astonishment, and it is better for thread-safe code.
Properties, in particular readonly properties, remain very useful for logging and debugging. Also there are things that depend on properties to work, such as some forms of serialization and data binding.
Keep in mind that properties are "actual getter and setter methods." A property is nothing more or less than one or two methods, along with a piece of metadata saying "this is a property." The syntax for calling a property method is different from the syntax for calling an ordinary method, but aside from that, a property method works exactly the same way as any other method.
That said...
With that said, is there any disadvantage to writing actual getter and setter methods for fields instead (other than my time)? Assume this is within my personal Unity code for fun and not in any sort of work or shared dev environment.
In your own personal code? No, not really.
The main disadvantage is that when other people read your code, they're likely to get the wrong idea about what's happening. If you write deflection = surface.Deflection, I'm going to guess that finding the deflection value is fast and easy. If you write deflection = surface.GetDeflection(), I'm going to guess that finding the deflection value involves something slow or difficult, like reading a file, or communicating with a sensor which will determine the deflection.
In other words, the usual way to write getters and setters is to write them as C# properties, so if you don't write them as C# properties, people are going to assume that you had some particular reason for not doing that.
And, of course, if you ever write C# as part of a team later on in your life, the team is probably going to want you to write getters and setters the "normal" way, so you may want to get in the habit now.
But if you'd rather read and write controller.SetProcVar(aircraft.GetAttitude().GetBankAngle()) than controller.ProcVar = aircraft.Attitude.BankAngle, then that's not going to cause you any unexpected problems.
