Wow, been almost 2 years since I’ve read my own post on this thread, but since to this day I still notice it bleeds a few likes upon unsuspecting observers, I’d like to give a follow up to this now that I’ve had the chance to work on more serious projects and rack up experience.
Addressing my reply and therefore the original thread: I was wrong in calling the Rcade class layer unnecessary. Very very wrong, and I’ll deep dive into that.
I almost literally use the exact pattern shown for Rcade now when creating classes and it not only helps with making inheritance much easier and simpler but also for consistency among classes because it abstracts creating the class container boilerplate away. vocksel/class from Wally.
The way the class module works is it creates a basic class container (the whole shebang - the table, the ClassName, inheritance support for the class and its metamethods and so on) and you instead write everything that you want happening on construction in an init function. Not as extensive but it gets the necessities out of the way so you don’t repeat yourself constantly.
The rest of the information can be gleaned from the thread itself which describes the use of the pattern; although they are implemented differently, both the class library and Rcade from the thread both achieve the same intended end result of better class creation.
The posts I made in this thread prior were born out of a place of misplaced confidence in what I believed was correct without either actually having tried out the pattern or being familiar with it and knowing what its drawbacks may have been, if there were any. So over 2 years later, I want to clear the air and apologise for misleading information and terrible advice in my posts. There was a whole lot of words to say virtually nothing very useful and said from a place of inexperience.
Addressing my own points directly:
-
Rcade is unnecessary and ruins readability: Flat out false. Readability is not affected by the use of a middleclass or class creation abstraction. You are simply picking a different location to write your object’s properties for construction.
-
Constructors are made to be explicit: init is explicit. This point makes no sense.
-
Some classes may (require or) desire more than one constructor: Possible to do even with an abstracted class. It may look a bit messy though especially if your new is created somewhere else but alternate constructors are essentially supposed to just change how the base constructor is called as opposed to making a whole new unrelated object.
-
Inheritance is quicker and cleaner with two metatables: Not in most cases honestly. Certainly not quicker and debatable on if it’s cleaner. With the class library I’ve been using as linked earlier, inheritance is incredibly easy - I just have to think in terms of writing properties alone.
-
I wouldn’t need a whole layer: This is true. It’s also true that I like to be consistent among my projects. I don’t think there’s a good or bad answer here since different content has different parameters but this isn’t a view I hold any longer. Speedy provided a good follow up on why the layer is good which is addressing metatables. It is also correct that it’s very easy to break DRY.
-
“An object should only have upwards inheritance”: In my second post, all my comments about inheritance are bold ways to say that the only OOP I know is OOP-in-Roblox and know nothing about encapsulation, polymorphism or any tenets of true OOP. This is just a mess of a reply here, and I was also wrong in saying that OP doesn’t understand the application of DRY.
Although my posts already each have replies, I’m going to hide the content and replace them with a message pointing out this reply. I don’t want any more developers being led by bad advice I gave over 2 years ago when they find this thread because it’s not good for their learning.
This is a good thread with good explanations and a pattern worth using. And even if you don’t want to go to this extent, consider giving vocksel’s class a look as well (especially if you’re a Wally user!).