In my quest for making big programs easily, i though i should study Cargo-bot as it is the ‘official’ example of how to write a big polished program with Codea, and use it as a guide. And, indeed, it is full of good stuff that i am now able to appreciate and understand since i am more experienced. But i still have some questions.
Q1: there is this Table=class() class to encapsulate some usefull table functions. But it has no init() because no instance is made, the member functions are used directly in the code. So why not making it just a table Table={} to gather these functions? Why making it a class()? Is there a good reason for that?
I think, in this case, there is no specific utility of using class. But an another question is when we have to use static functions or kind of module than classes ? For example, we can talk about Singleton pattern => http://gameprogrammingpatterns.com/singleton.html
Singleton:
- It doesn’t create the instance if no one uses it.
- It’s initialized at runtime.
- You can subclass the singleton.
Else, I prefer write table:remove(obj, allInstances) (or table.remove(array, obj, allInstances)) than create a new table or class for add functionality on tables who are a basic type with an already existant global table for stock functions.
@Dave1707 thanks.
I have another question, for experienced object-programmers, or @simeon or @John if they have some time available.
I have started to use Cargo-bot classes as a base for building things. I can now see how professionnal it is designed: everything is so well decoupled! It goes to a point that is surprising for my natural expectation. More precisely:
-the Panel() class groups Button() objects for position and touch.
-the Screen() manages a scene and draw() objects included like buttons.
The panels can exist independently of the screens and contain the same buttons. It is a strong decoupling between functions, which is good (really?). But for me, this is weird.
My ‘naive’ expectation would have been that:
Panel() would collect Button(), manage their position and draw them,
Screen() would collect Panel() and draw them.
It is more hierarchical than the choice for Cargo-bot, and then more coupled, but it feels as a more ‘nalural’ modeling of reallity than the other choice. Why is this a bad idea? (it must be a bad idea, because cargo-bot choice is different and less natural, so there is a reason why it was made that way).
Has any experienced programmer around who understands my question some comment about this?
@Jmv38 I haven’t looked at the Cargo-bot code so I can’t really comment on it. But from the point of writing a large program, don’t make the classes any more complex than they need to be. Have each class do only what they’re set up to do, that is, don’t try to make them do a lot of different things. Make sure the class names match what they’re doing. Make sure each class does what you want it to do before moving on to other classes. And try to write the code in such a way that you can test it easily. It won’t take very long before thing start to get complicated and if you lose track of what things are doing, you’ll be in trouble in no time.