#Logic decoupling

1 messages · Page 1 of 1 (latest)

faint mirage
#

Hi, so im currently making a game with a few systems. I've organized them into

ServerScriptService: Package, ServerModules, ServerScripts
ReplicatedStorage: ClientPackage, ClientModules, Remotes, ReplicatedAssets
ServerStorage: ToolAssets

thing is my logic for initialzing all these systems is kinda coupled, largely depending on eachother.

Question: How do you guys do your arhictecture and avoid coupling logic especially when it comes to server and client communication or is this normal?

vital latch
#

how is it coupled

faint mirage
#

The system logic themselves are separated ig, its just how i use them which kinda makes them coupled.

for e.g my itembuilder module relies on my DataTemplate module
and my itembuilder methods rely on my hitbox module, and etc..

im not sure if this is fine or not.

vital latch
#

coupling is impossible to not have

#

decoupling something is just making it so that you need to know very little about some dependency when using it

#

for example, if you had a DataService, the access point should be a single method like :Get(), not some table with all the player data

#

good code is code that has the fewest assumptions made

vital latch
#

you could have a HitboxService that both ToolService and MovementService uses

#

since hitboxservice just exposes API to centralize hitbox registration, it's not actually coupling, it's just centralization and stopping yourself from copy pasting hitbox registration code

faint mirage
#

ye this makes sense, i guess my problem was more of a scalability problem since my serverscripts that used these modules had if conditions rather than relying on dynamic data

#

like if data.Type == "Axe" then do axe logic
elseif data.Type == "Backpack" then do backpack logic

vital latch
#

it should be dynamic

faint mirage
#

instead of doing if conditions should i just create entire new functions for them rather than relying on 1 function identifiyng multiple things?

like 1 function to handle axe stuff and another for backpack?

vital latch
#

consider maybe using OOP or some command pattern

vital latch
#

let me walk you through how i clean something up

#

how does your thing work right now

#

is it like

# 
function swing
    if tooltype == 'axe' then
        -- do some code
    elseif toolType == ... then
        ...
#

?

faint mirage
#

basically yea its
if toolData.Type == "Axe" then

vital latch
#

and thats all inside one function?

faint mirage
#

ye its inside a function thats called when they equip it from their inventory

#

1 function

vital latch
#

okay yea

#

its very convenient

#

it's one function you call

#

and it abstracts everything and swings the tool

#

which is good

#

except for the fact that it makes the swing code super big

faint mirage
#

yea but i felt that one function was handing too much logic

vital latch
#

which in turn makes it very unreadable

#

right now, the swing function is acting like an interface

blazing needleBOT
#

studio** You are now Level 4! **studio

vital latch
#

it takes the data and things and then routes it to different blocks of code

#

so you should start by turning all those different if statements and blocks of code into functions

#

so instead of

# 
function swing
    if type == 'axe' then
        -- LONG CODE
    elseif ...
        -- LONG CODE
#

its more like this

function swing
    if type == 'axe' then
        axe()
    elseif ...
        ...()
#

instantly that makes it 100x more readable

#

and these functions

#

dont even need to be in the same module anymore

#

you could have your ToolService

#

ToolService
-> Axe
-> Backpack

#

and then

#

your swing code

#

would be as simple as

# 
function swing
    local callback = someTable[type]
    callback?()
faint mirage
#

ty, this helps. Idk why i didnt think of just putting the code of the if statements into functions x_x i've been too focused on modules n shi to focus on the simple stuff

vital latch
#

now all your pre-existing code stays the same because it calls swing - that's an example of decoupled code because it's abstracted away
and your swing code isn't bloated and all the things are easy to edit

#

and you dont have to know how the Axe function is being called when youre editing it

#

you just know it is

#

less assumptions in the code more assumptions for you

#

👍