OOP, Organization, and Tips

Help and Feedback Scripting Support
#22

Ah, I see. It does look good to me. You’re doing it right! But it does make me wonder, how are the GUI interactions and animations being controlled now? If you are still looking for a good way to do this and haven’t done so already, I’d recommend making a Player class. That class, which creates and maintains the PlayerGui, Character, and Backpack related classes should contain a unequip method since equipping deals with scripts from all three of those areas of responsibility. In OOP you yoink code up higher in the hierarchy to deal with access issues like this. Unfortunately this is also another reason I don’t like OOP as it creates heavy top-level classes.

I’m beginning to think you have a vendetta against spaces. You can’t just backspace everything you don’t like! lol

(Interesting, in the quote above, two periods show up as three…)

#23

lol i didn’t do anything about the spaces yet but ill get to them eventually

GUI interactions and animations are being controlled by the main code now, for example:

--unequip current, if
if equipped then
	weps[equipped]:Unequip()
	--stop tracks
	for i, v in pairs(tracks[PLAYER]) do
		v:Stop()
	end
end
--equip
equipped = inputObj.KeyCode.Value-48
weps[equipped]:Equip()
--update gui
GUI:ShowWepInfo(MAIN)
GUI:UpdateWepInfo(weps[equipped],MAIN)

Would my Gui module be considered a singleton. If so, whats the single object under that class? I’m still have trouble classifying what type of module it is. And I’m still unclear if it should be an extension of my main script for not.

Also, is it bad having a single main script to control everything?

#24

Eeeeh, it could be argued either way depending on who you ask probably.

You’d probably want to inline the one liners if you did. If I wasn’t going to abandon OOP, I’d make this a full-blown class and throw the main screen gui into the properties of it and have each actual method access it through self.screenGui. I’d also put the button connection into the constructor. I’d also recommend giving those articles I posted a read.

Oh no, not at all. If designed right your main script can handle everything and be very, very simple. This is because everything should be in the framework or paradigm you are using. That’s the benefit of information hiding and abstractions.

#25

I just feel inconsistent having a whole class module dedicated to GUI and my main script deal with everything else.

There has to be some sort of rule I must follow if I want to dedicate a pre-existing object a complete module that I attach it to.

#26

Yes… you must succumb to OOP entirely, or shun it and embrace functional programming. Using both will lead to code smells, bad vibes, and heinous deeds. Does this mean you’ll join my campaign?

#27

What would this function be called then?

function Gui.Attach(MAIN)

end
#28

You have to make it a non-static class. Like so:

local WeaponInfo= {}

function WeaponInfo:show()
	self.info.Visible = true
end

function WeaponInfo:hide()
	self.info.Visible = false
end

function WeaponInfo:update(weapon)
	local info = self.info
	if weapon.type == 'Firearm' then
		info.Pool.Text = weapon.pool
		info.Mag.Text = weapon.mag
	else
		info.Pool.Text = '-'
		info.Mag.Text = '-'
	end
end

function WeaponInfo:init(info)
	self.info = info
end

return WeaponInfo

You’ll notice in OOP languages, you don’t create objects in constructors. You initialize them. The new keyword is usually what actually makes them. (allocates memory, calls constructors)

#29

So are libraries/utilities non-static classes?

#30

Function libraries and utilities are not OOP concepts, but OOP does have a place for class libraries and utility classes. Static classes and methods are attempts to imitate functional libraries and utilities. That is exactly what one of the articles above is on. I REALLY suggest that you read them.

#31

Alright thanks for all the help. I’ll post again if I need help.

Greatly appreciated.

#32

When I create a new firearm instance, they have stats like mag, pool, cycle, etc.

What if I want the stats to change depending on what firearm it is. Would I have a module for each firearm with all the necessary information, kind of like a data base that it reads from? All I have to do is transfer over the firearm name via arguments?

I don’t want to create another sub class for firearm, which is already a subclass of weapon, since most firearms would have the same functionality anyways.

#33

Here is an article from Refector Guru: Replace conditional with Polymorphism. You could throw conditionals all over your code to handle the differences between each type of weapon, but the OOP was is to make a subclass. Not much would have to be changed I’m guessing, maybe just the constructor since only the initial values need to change?

#34

What would I do if I want to communicate witth the main script after the object is done with it’s method?

For example, after the firing and subtracting from the mag, etc. I want the main script to create a projectile with position, direction, etc.

I don’t want to write that all under the weapon :Fire method bc that kind of defeats the whole purpose of OOP.

#35

When the player clicks, each weapon should probably have an action associated with it. A general Activated method could be created that each subclass defines. For firearms, this would be the equivalent of “fire.” I’m not aware of the situation and all the requirements, but does that sound about right?

#36

I meant like,

let’s say

--snippet from Firearm object module; subclass of superclass 'Weapon'

--services
local ReplicatedStorage = game:GetService("ReplicatedStorage")

--fire method
function Firearm:Fire()
	if self.mag>0 then
		if self.cycle == "Semi" then
			self.mag = self.mag-1
			--I want to fire a remote event to the server
            --how should i do it?
			ReplicatedStorage.RemoteEvent:Fire() --current solution
			--OR 
			--somehow commuciate back to the main script that called this method
            --how should i do it?
		end
	end
end

I think’ I’m doing pretty well with the whole independence and I don’t want to mess something up.

Side note -

Is it also bad to have services/constants written at the top of your class/object modules??
Is it bad I want to call back to the main script when the method is done?

Am I doing something wrong?

1 Like