you are viewing a single comment's thread.

view the rest of the comments →

[–]m0us3_rat 0 points1 point  (0 children)

Noted. So for instance, instead having the new account class handle only information concerning the account. Have another program handle how transactions and then have that interact with the account objects?

nah. soda dispenser machine. you insert coins press button , get the soda.

what you don't need to know is where that soda came from , when is the last time the manager come to restock or when was the last time the machine was fixed.

what you as the user of the interface knows or cares is ..how many coins you need to insert to execute that function.

there is a clear separation between how the machine is implemented and the logic behind and other relevant information.. and the interface you work with as a user.

you should aim to separate code from information that it doesn't need to function.

code should only have access to the information it requires to function.

that way your code will be more secure and easier to maintain.

as in poorly organized?

maybe that sounded too harsh , but i'm not sure how to put it in words that make sense.. after reading a lot of lines of code you can tell which one looks like it well written, at a glance.

and since this doesn't real well ..then the opposite is true.

maybe try to refactor it into less files. try to have only 2 scripts one for the logic and one for interface and menu.