OOPing Guidelines

In theory, anything that can be categorized as a noun (a thing) in your code is a candidate for being an object. In practice, you’ll bundle related parts into one object for simplicity unless there is a need within your code to treat a part as a separate thing (it needs it’s own separate state and actions).

Something like a jerry can that operates in the world as it’s own thing is a valid candidate. The nozzle for the can, any caps/lids, a fill level indicator (or whatever), other parts that do something simple and germane to the “jerry can” concept could all be considered as part of the same object unless there are compelling reasons to treat some of these as separate things. There’s a bit of subjectivity/art in where you separate related components into different objects, and quite a lot depends on what you are trying to achieve. Naturally, it will be easier to figure out where to draw lines for some things than others.

This info is wrong if a can belongs to a fill point rather than the other way around

Separating the fuel tank fill point into it’s own thing seems unnecessary. That functionality is probably fairly simple and it’s closely tied to what a jerry can is. The state of a fill point seems like it could be part of the can object. If you did decide to make it a separate object, then you would do well to look into an OOP concept called composition. The basic idea is that you make one object an attribute of another and let the attached object handle things it needs to do for itself. If you are planning to use that fuel tank fill point code in objects other than the jerry can (maybe it’s a complex and sophisticated implementation or something), then that might be a reason to go that route.

This page, this page, and this post are helpful Lua/Roblox OOP resources if you haven’t seen them. Here’s a stackoverflow discussion on what should be objects and a list of OOP best practices.

I think OOP is something you can ease into. Bundling state and methods together can provide immediate benefit. Don’t fret over best practices too soon (developing expert knowledge of all that stuff is not a trivial undertaking). Let it be an evolution.

2 Likes