Questions about OOP

Given this code :

function OOPModule.new(Name, Damage)
     local newItem = {}
     newItem.Name = Name
     newItem.Damage = Damage
     setmetatable(newItem, OOPModule)
     return newItem
end
  • The table is located within OOPModule, but how do I go about accessing the same objects from a second script without directly accessing the table?

  • Can client-side constructors be hacked? What is the process that occurs during object creation in the client?

  • In such a game implemented with OOP (with one client script, one server script, and multiple module scripts), the client would call the module and the server would run it when?

  • How would I implement an inventory system using OOP? Would it be passed through a constructor if a player clicked a button to equip an item? How do I go from there? How do I use it in a way to provide the player with health but avoid exploits?

  1. Classes are defined in modules. A module contains the constructor function and class methods. The constructor function produces an object (table), connects it to the class’ methods, populates the objects propertie’s, then returns the newly created object. This means the object belongs to the caller of the constructor, not the module. Accessing the object from other scripts would require you to cache the objects in the module and provide an interface for retrieving them, or setting up an alternative pipeline in which one script can communicate an object to another. Sending objects over a network requires additional work.

  2. The construction of an object largely remains the same regardless of what end of the network you’re on, client or server. What is and isn’t legal in those respective constructors is tied to existing rules with the replication boundary; you can’t go accessing ServerStorage on the client.

  3. You’re referring to SSA (single-script architecture). SSA is not a requirement for OOP. OOP in an SSA codebase is not any different either. Objects aren’t ever shared between the client and the server, so there’s no “calling” or “running”. SSA typically uses a service-controller pattern where server-sided APIs, client-sided APIs, and shared APIs exist. The server-sided API creates its relevant objects, the client-sided API does the same, and the shared API provides shared functionality. You’ll build a bridge between these APIs if necessary

  4. The inventory would be the object. It’s up to you if items in the inventory are represented as objects as well. Objects are used to create individualized instances of compartmentalized functionality. You want cars, so you build a car class than does car stuff, then create individual instances of cars which can operate and be operated on separately in set ways. The same goes for an inventory