Hello everyone, I have one problem, the solution of which I can not find in any way. My problem is that I understand the Unity API well and can do what I want, but I can’t organize my code correctly, sometimes I sit for a very long time on a simple class, thinking about the best way to write it. The problem is that I know what classes, structures, interfaces, abstract classes, virtual methods and their overriding, etc. are, but I don’t understand which of these is best applied in a particular situation, and I don’t understand when I need to do it. Previously I learned C++ for 18 months, but I learned the basics, algorithms, etc., I didn’t use third party libraries, but tried to write them myself to learn the basics, and it went well. I could separate and neatly maintain the code, but now when I started learning C # and Unity, it became difficult for me to understand what and where to do. I started to apply some design patterns that really helped me to simplify the work, but it seems that this is not what I need. I read about the principles of OOP and I even seem to understand when it should be applied by examples, but I still can’t understand it when I write code. I want to know what I need to do so that I can apply OOP principles in the right situations and write good code.
I kinda feel like the answer to this is just ‘practice’. The more you plug away at it the more you’ll get a grasp on what patterns to use and how to organise/structure your code/assets.
In any case, Unity preferences component and compositional design more than it does ye olde inheritance/OOP design (yes I know Unity’s component structure is a layer above inheritance). Leaning into that will make your life a lot easier. Once you learn those fundamentals, then you’ll have a good idea of how to use it, and also how to break it to your benefit.
That’s not to say your typical good practices don’t still apply.
I think what you’ve really discovered is that there are a lot of ways to solve the same problem. How you organize your code is very subjective, and in my opinion the best way to learn about how to write code is to read a lot of code.
Like spiney said though, composition > inheritance. You generally want to minimize dependencies and maximize flexibility. How you do that will come from experience.
Ah Yes! I know exactly what you are talking about here. I sometime find myself ‘paralyzed’ trying to find the absolute best way to resolve a coding issue. I constantly re-work something if i find what at the time appears to be a better solution. re-code, re-code, over and over, only to find I have made very little progress in the project. You have to get to the point where you just write the code as you know how to and get the project working. Then you can re-evaluate what you have done and learn from it. Just don’t get hung up on everything having to be the technically best way to do it, you will frustrate yourself to the point that you will not enjoy development anymore. So basically I just re-said what Spiney199 said in his first sentence!
You need practice, just write your own games or even find paid job project.
You will constantly find many code issues, will understand which design decisions was more and less maintainable and what can replace them.
Job projects are especially great for situations “how to organize code”. When I started working professionaly a year ago, it was kinda eye-opening experience for me and I learnt code architecture stuff I would never come up with myself.
It works just fine to program in C# while still thinking in C++. A lot of the fancy OOP stuff, especially Design Patterns, never really worked and people saying to do it now are just copying from 15-year-old advice. Unity projects tend not to be large enough that designing your own large inheritance trees is worth it.
Most of the issues I have are just the usual that happen in any language and any sort of project – do it the easy fast way, or try to think ahead and write a more flexible framework? Or, combine these similar things are one class with lots of options, or write 2 classes that share a few things?
It seems you have a too narrow view on programming paradigms. This is a really great (19minutes) video about the different paradigms and what they actually mean. It may help to better shake off any fundamental idea about certain paradigms and see them as what they are and what’s the point of those voluntary constraints.
think this comes down to opinion since i feel large inheritance trees are just needless complexity, and things can be expressed cleaner using composition and interfaces over inheritance.
edit:
reading comprehension fail missed the “not”, going to leave the comment since i do find making lots of small 1 purpose components is a really nice approach for games.
Thank you all for the answers !
I realized that I need more practice. I assumed that this is what I need to do but I wasn’t sure. Thanks again !