Is OOP really better than the usual?

Help and Feedback Scripting Support
#1

An example, there are 30 coins, and each will get its own script. I know about OOP with metatables and modules and I use them in my projects. I use metatable modules so can apply one script to all coins. Does it reduce the weight of the project? Or just exists to prevent confusion caused by many scripts?

#2

I don’t personally see any advantage to OOP in Roblox and I never have. The reason is because it takes a lot to implement, and everything is already OOP with the exception that you can’t extend them or do anything with them. OOP is a paradigm, and it’s not faster per second than another paradigm. OOP shines best when you have a variable number of cookie-cutter objects with slight variation, other than that, there isn’t a difference.

1 Like
#3

So, 20 same objects with 20 scripts are equal to one OOP script?

#4

Yes indeed, the scripting style wont matter its how easy / hard to edit, as I said, these moments are when OOP shine, they are pretty much clones of each other with slight variation so OOP is better in this situations BUT it will NOT affect the performance, at the end of the day, it’s just a preference

1 Like
#5

Thank you for your thoughts that explained a few questions in my head

#6

Your welcome! If you have any more questions, feel free to ask and / or dm me at any time!

1 Like
#7

Another thing I forgot to mention, OOP will help in making your code clean and easily editable causing a more organized project.

1 Like
#8

OOP is great only when you’re using it appropriately. It’s useless if you want to run basic logic but is powerful when you’re working with individual components.

Let’s say we are coding a car system. We want to manually create, boost or destroy each car as many times needed during our game. Traditional code and modules would give us this

local Car = {}

function Car.CreateCar()
	local Car = {}
	Car.Speed = 10

	return Car
end

function Car.BoostCar(Car)
	Car.Speed += 5
end

function Car.DestroyCar(Car)
	table.clear(Car)
end

return Car

local Car = require(Car)

-- // On Player Joined
local newCar = Car.CreateCar()

-- // On Player Pressed Boost
Car.BoostCar(newCar)

-- // On Player Left
Car.DestroyCar(newCar)

There are 3 glaring problems with this approach:

1. Does not scale well during production

2. Our methods are entirely disconnected from the actual newCar object, and we are forced to index directly from the Module table.

  • This means we have to manually pass our self argument (In this case, Car table) which can get pretty confusing really quick.

  • On a readability standpoint, Car.BoostCar(newCar) is bloaty and unintuitive. If you want to have multiple Cars that you want to boost separately, this can become an eye sore real fast.

Now if we incorporated OOP our code would look more something like this

local Car = {}
Car.__index = Car

function Car.new()
	local self = {}
	setmetatable(self, Car)
	
	self.Speed = 10

	return self
end

function Car:Boost()
	self.Speed += 5
end

function Car:Destroy()
	table.clear(self)
end

return Car

local Car = require(Car)

-- // On Player Joined
local newCar = Car.new()

-- // On Player Pressed Boost
newCar:Boost()

-- // On Player Left
newCar:Destroy()

We can now freely call methods on each separate Car which makes this solution more scalable and more flexible.

In the end, if using OOP isn’t benefitting you, you’re probably using it wrong. It’s really easy to overengineer on new concepts but remember you’re free to use whatever paradigm you want whenever you want in your code.

4 Likes