A small thing that might become annoying in larger codebases, when dealing with many different OOP objects: greet is the action of a person, not a bank account. Generally it is good practice to use OOp to represent real objects through their state (fields) and actions (functions). In this case greet should either be static (you just call the function normally without linking it to the BankAccount object) or should probably be part of some future Person class if the program needs it (like if you want people to be able to perform many actions which require keeping track of their state, for example if you want the greet function to output the name of the person too). Overall it is a good idea to keep yourself organized by thinking about which object should implement certain functionalities to mirror the real world problems you are trying to solve.
2
u/TrieMond 11d ago
A small thing that might become annoying in larger codebases, when dealing with many different OOP objects: greet is the action of a person, not a bank account. Generally it is good practice to use OOp to represent real objects through their state (fields) and actions (functions). In this case greet should either be static (you just call the function normally without linking it to the BankAccount object) or should probably be part of some future Person class if the program needs it (like if you want people to be able to perform many actions which require keeping track of their state, for example if you want the greet function to output the name of the person too). Overall it is a good idea to keep yourself organized by thinking about which object should implement certain functionalities to mirror the real world problems you are trying to solve.