Not needed yet, as we only have two interactable objects, but we duplicate a lot of code between the door and the sphere.
Presumably, at some point we can identify common base code for these and abstract them into a class (say InteractableBaseCode) that extends BaseCode (which in turn extends Monobehaviour). Are there any limits to this sort of abstraction, apart from my mental aptitude for understanding of Inception?
Iāve only just reached the āpolishā section of the course so please excuse me if Iām off base here.
A useful guide for most code is to keep it DRY, which stands for Donāt Repeat Yourself. If itās possible to tidy up duplicate code into a single place, it is almost always a good idea to do it.
Given that youāre talking about just one additional level between BaseCode and the Interactive objects, Iād definitely go for abstraction in this particular case.
The practical limit for abstraction is when the hierarchies become impossibly deep. I try to balance DRY with the KISS (Keep It Simple, Stupid!) principle, but that rapidly becomes a matter of personal taste (what is too deep? when does code become complicated?)
For me personally, two or three levels of abstraction before a concrete class is about as far as I ever want to go. If itās getting deeper I would suspect that the class is being asked to do too much, and look instead for ways to refactor it into several separate shallower hierarchies.
Sure that could be an alternative, make a InteractableBase class and extend that class for the various objects. Like you said it depends on what common code you have between them. If you have 10 interactable objects and they all share a lot of code then it might be wise to do that, but if only 2 have some duplicate code then perhaps itās not the best approach.
For me personally I tend to avoid using base classes as much as possible because I find they create a lot of confusion very quickly, so I only use them very rarely.
An interface makes more sense to me since in my design I didnāt necessarily want every interactable object to work the same way.
And if you still want some common code between them you can still use an interface and since C# 8 you can now define default code inside an interface. Default interface methods - C# 8.0 draft specifications | Microsoft Docs
Thanks. Definitely food for thought. From my (minimal) introduction, inheritance seems the antithesis of readability. Even with just one layer of abstraction, I keep forgetting what is in BaseClass and therefore forget to utilise it.
Further arguments to document your classes, their jobs and which properties/functions they have, I guess
I think inheritance is not the antithesis of readability in any sense. You should learn the tools you have available and use them accordingly.
I sugest you really dont avoid using ineritance just becase āit is confusingā, you should really think: āIs there a lot of code in common in this clases which I could place in a common (parent) class between them?ā If the answer is yes, then go ahead, dont be afraid of trying new stuff, I think having DRY (Dont Repeat Yourself) code is more important than having to learn a skill or two to understand it.
As a matter of fact, the more tools you learn, the better programmer you will be, and the better problem solving skills you will have. As you wil have more tools available when facing a problem, so you will be able to solve them better.
I have been seeing some common denominator in some of the posts of this course, whith messages similar to āI dont understand/know this concept, so I dont want to use itā, I think each and every concept in programming is a tool, and has its use cases, and its cases where its not the best approach. In my opinion and my experiencie, the best you can do is learn and get used to this concepts, so that you will then have the possibility to realize by youself if that tool is the best or not, in that problem you are trying to solve.
One thing to considerā¦
If you find you have a number of IInteractable objects that have a common set of functions but would not make sense to have a common ancestor class, in order to avoid code duplication it could be useful to gather code in some sort of utility class that all of them could use. Much like we have things such as Mathf for all sorts of math functions.