So I already know how most OOP DataStores work, many of them have the Player Stuff set up like this:
function module.new(player)
local self = setmetatable({} {__index == module})
self.Player = player -- Player this belongs to.
self.Data = {...} -- The Starter Data given (you meed to Load it in first)
self.Key = `Player_{player.UserId}` -- Players Key for Data
return self
end
-- functions that Get / Save things
function module:LoadData()
end
function module:SaveData()
end
But, even of they are set up that way or not, why would be good about them, It may just be the way that Im using it but i have never saw the point in doing it, and I was wondering if I was better off using a Regular DataStore without OOP.
Should I make a OOP DataStore?
And what would be Advantages and Disadvantages towards an OOP DataStore?
Can I first correct what you are saying/calling the DataStores. There is not really anything called a “OOP DataStore” as such however what I am guessing you mean is saving the data inside of one table or encoding a object via JSON and saving the data that way (well at least I hope ur not saving methods in a DataStore).
In general you should really be trying to save as much data together as possible really (for example having all your game currencies together). Main reason I would say that is so that it is more easy for you to access things without having a ton of DataStores but also it reduces the rate limit for the DataStores because then there is like only one per person you need to access and save to and stuff. Possible issues is that all the data is saved in one place so if for any reason there is an issue with saving all the data is loss but if you are careful (or just use one of these datastore modules which do the saving mostly for u) it should really be fine.
Let me know if that is not what you mean but from what I can see this is what you are talking about.
The major benefits I find for writing my own datastore object would be:
Caching data for faster Get requests
Only making save requests if changes have been detected to be made
Custom get request function resulting in cleaner code especially during initial loading situations
You can also have it detect weather the initially loaded data doesn’t have a specific key inside of its table (if its a table), and have it be appended into the old table
Example Code
function dataStore3:GetAsync(scope, dataStoreName, template)
local cachedDataStore = cachedData[dataStoreName]
if not cachedDataStore[scope] then
if not template then
return
end
local success, loadedData = internalGetAsync(scope, dataStoreName)
if success and not loadedData then
cachedDataStore[scope] = {
data = cloneTable(template),
changesMade = true,
}
elseif success and loadedData then
cachedDataStore[scope] = {
data = httpService:JSONDecode(loadedData),
changesMade = false,
}
for key, value in pairs(template) do
if cachedDataStore[scope].data[key] == nil then
cachedDataStore[scope].data[key] = value
cachedDataStore[scope].changesMade = true
end
end
end
end
return cachedDataStore[scope].data
end
In the realm of Roblox game development, Object-Oriented Programming (OOP) is a popular approach used to organize and manage data in a more structured manner. Specifically, an OOP DataStore is a data storage system that conforms to OOP principles.
One of the advantages of using an OOP DataStore is that it can help you organize your code in a more intuitive and structured way. This, in turn, enables you to access and manipulate data more efficiently without creating a cluttered codebase.
Another advantage of an OOP DataStore is modularity. This means you can easily add new functionality or modify existing code without affecting other parts of the system. In other words, an OOP DataStore can be designed to be easily scalable, allowing you to build upon your project as it grows.
Furthermore, OOP DataStores can be reused across different projects, thereby reducing the need to write new code from scratch for each new project. This feature makes OOP DataStores a valuable tool for game developers as they can save a significant amount of time and effort.
Lastly, an OOP DataStore can abstract away the complexities of the underlying storage system, making it easier to switch between different storage backends without changing the rest of your code. This is known as abstraction, and it’s an important concept in software development.
However, there are also some disadvantages to using an OOP DataStore. For example, an OOP DataStore can introduce overhead due to the additional abstraction and complexity, which may impact performance, particularly in larger projects. Additionally, if you are not already familiar with OOP principles, there may be a learning curve involved in designing and using an OOP DataStore effectively. Finally, if an OOP DataStore is not designed carefully, it can lead to code bloat, which makes it harder to maintain and debug your code.
Well I mean the whole point of OOP is to make everything centralized rather then loads of different saving stuff in different scripts. Then if you want to change how you save things it is just one module script that needs changing compared to the possible 2-3 or something amount of scripts.