Non-Basic OOP

[open mica]

I get the basics of oop but when anyone goes any deaper i get extremely confused about it. Can anyone make it clearer. I've seen multiple videos and explanations but it feels like they just jumped abit without really explaining.

[stoic spire]

What do you consider "deeper OOP knowledge", maybe just sending some keywords you've heard (no need to understand what they mean just yet, just to paint me a clearer picture) can help

[open mica]

i know how to get the data from a instance and save it; i kinda know how to create some new intances and that about all i know. also how is __index activated becuase ive seen no things used to activate it but it still activates (., [""]).

its really i think its how it connects im confused about

[stoic spire]

__index just fires when the table it's connected to is indexed by a key that's not in the table

[open mica]

ik

ok i see it now abit dont mind that part ig

[stoic spire]

Anyways, OOP just refers to a writing style. It means that your codebase is created around "objects", and those objects interact with each other.

OOP is split up into 2 main styles: inheritance and composition. Inheritance looks like the explorer in roblox, every object can inherit other objects. Composition flips this around. You compose multiple things together to create a new object.

e.g.

a car and a boat:

inher:

make a car class
let it inherit an engine, wheels, etc.

make a boat clasS
let it inherit an engine, rudders, etc.

composition:

make an engine class
make a wheels class
make a rudders class

make a car class, composing of an engine and wheels
make a boat class, composing of an engine and rudders

(I forgot to mention that both have ups and downs, yet I would just recommend trying to make some project fully using 1, then fully using the other. Then it should be clear when you should use which

[stray fulcrum]

OOP Code example:

local enemyClass = {}
enemyClass.__index = enemyClass

function enemyClass:destroy()
    self.enemyPart:Destroy()
end

function enemyClass.new()
    local newEnemy = {
          ["enemyPart"] = Instance.new("Part")
     }
    
    -- Basically makes newEnemy == enemyClass so you could essentially do newEnemy:Destroy()
    setmetatable(enemyClass, newEnemy)
    table.insert(enemyClass, newEnemy)
end

[stoic spire]

all lowercase 😉

[stray fulcrum]

thanks

[stoic spire]

Why are you inserting the class into the module?
You can also just return it and the variable that function returns is the class

And yes, that is a very basic OOP example, as I said before, I would pick either inheritance or composition, then make some entire project written in that style, then make a different project (or the same, but that could be boring) in the other style

Truly the best way to get a hang for it. Nothing beats just good ol' experience

[stray fulcrum]

you could destroy every enemy just by doing a for loop

[keen barn]

FYI, by convention, constructors are given the name "new", not "createNew"

[stoic spire]

I would've then just grouped the class together, so all enemies fall under "1 object"

But that does partially depend on what you're exactly going for. As I said, you can try to read into OOP usecases, when to write which style, etc. etc. But in reality, you can easily just "feel" what the right style is, once you've tried writing in both

[stray fulcrum]

could you give and example, i dont quite understand

[stoic spire]

Wanted to come up with a better example but couldn't come up with any. Anyways, based off of your code

local httpService = game:GetService("HttpService")

local enemyClass = {}
enemyClass.__index = enemyClass

function enemyClass.new()
    local self = {}
    self.enemyList = {}
    
    return setmetatable(self, enemyClass)
end

function enemyClass:add()
    local enemy = "Add your enemy stuff in here."
    self.enemyList[httpService:GenerateGUID()] = enemy  --shit between the brackets just generates a random string 
end

function enemyClass:remove(id)
    if not self.enemyList[id] then return end
    self.enemyList[id] = nil
end

function enemyClass:clear()
    --remove all NPCs
    self.enemyList = {}
end

Oh god, I did my best writing in camelCase and I still fucked up... just ignore that

I mean, I can't see any PascalCase, what do you mean?

[stray fulcrum]

i see the edited tag

but

nvm

OOHHH I GET IT

[stoic spire]

Anyways, some advantages to write it like this could be e.g.:

easier for groups of enemies (e.g., if you wish to pathfind per "group" of enemies, then you can easily make them share 1 reference like this. Grouping enemies up makes it so you only have to pathfind once per group instead of per enemy)
easier for managing teams (let's say that you've 5 teams, now every team can get 1 class, instead of using flags/values inside of each enemy). But that is another example of composition vs inheritance

[stray fulcrum]

so this would just be for groups

but doing things individually is harder since its all grouped

so that's how utg made their teams system

[stoic spire]

You could still use subclasses, but as I said before. You should just play around with inheritance and composition OOP. As there are 50 ways of writing the same code. And thousands of ways to write code based off of a simple description. The easiest way to learn what style to use is to just fuck up. And there's nothing wrong with messing up, or doing it the hard way. Just make sure that you learn from those mistakes and try to do it better the next time around

[onyx cargo]

@stoic spire hi bro, I have a question about oop. What is the difference of oop and module

[broken nest]

oop is not just a "writing style", it has genuine semantics behind it, but you should know that