I really don’t know if a chart exists regarding the specific features and differences between a Module and a Class, but that would be incredibly helpful. I am an absolute unit of a newbie when it comes to those items, and I’ve avoided them like the plague because I … have to admit … know zilch about these two.
I simply have a code repository in plain text format with instructions to copy-paste into each app.
Not sure if this helps, but as a pure example and as always there are many ways to do things especially in OOP
I have a program where technicians record maintenance done to certain breathing air bottles
I created a “class” for the different type of bottles that can be serviced, when the user clicks on a radio button of described bottle a new class is created and the technician works with that class and records the maintenance
I used a Module for recording properties such as “TechID”, and “Date” and then when the technician prints a record of maintenance I use the “class” properties" and also the Module information for printing
NOT saying this is the best way or only way just saying this is how it can help you understand the differences
There is so much more but as the basics I hope this helps
Later on after you get the grasp of classes you can learn Interfaces and such, but for now just focus on the basics
Learn the basics of Classes then move on and do not get caught up in more advanced topics as that hurts the learning process, just focus on classes first then move on
I guess we should ask if you have an Idea about something and wonder if or how you should create a class?
And maybe from that we can show/describe what should be in the class and what should be in a module
I have a class in my app which is made using a Listbox. So its Super is DesktopListbox. The reason for this is that I have three places in my app where I need what this listbox does. They have broadly similar behaviour, look similar, but have some differences. I suppose one could implement this by having a plain old listbox, and then in, say, an event handler, have some if statements to distinuguish what the handler does depending on whether I’m Listbox1, Listbox2, or Listbox3. But this would be a hack.
Now, all three instances of my listbox class are laid out in the IDE, not created at runtime, although instances of any class can be created on the fly if that is what is needed (I have a tabbutton class where I do just that). Where an event handler would be the same for all three listboxes, I put it in the class definition. In this case, PaintCellBackground, PaintCellText, and RowExpanded. There’s also some methods and properties in the class definition which are needed for the listboxes to operate, and an event definition. I need this because only one listbox is visible at all times, and it permits rows to be reordered and row expanding to be done. If the “main” listbox is re-ordered, then I can arrange for the other two also to be reordered in the same way (they all show the same content) - which is what the user would expect. I was in fact thinking yesterday that there may even be a fourth place I could use this listbox class - if I can be bothered to implement it.
My button class is based on a small canvas and these are rather like browser tabs, they get created at runtime as the user opens more of them. Having created it, I have to add it to what the user can see, thus:
Var tabPtr As tabButton
tabPtr = new tabButton // Create a new tab
// initialise some properties here, including adding event handlers using AddHandler
tabPtr.EmbedWithin (self) // Add this tab to the DesktopContainer that houses all the tabs
setTabWidths () // Adjust the Left of each tab so they line up nicely and all fit in the available space
and so on. My modules tend to just contain methods where a module is a suitable way to group them together, like all Declare methods, or all database methods.
I am creating a uniform login process to connect desktop, web, and mobile apps to a central account management database. The idea is for all apps to check in with the main web app so users can pay online and no Apple Tax / Google Play Tax is paid. App platforms are charging between 15 and 30 pct of all in-app and subscription purchases while online payment processing only shaves off about five percent. I also want to enable cryptocurrency payments so users can subscribe via crypto. No bank can snatch crypto if it’s in a 3pty wallet LOL
Yes the whole point of using classes is to make your code more modular and efficient
It is hard to let go of top down coding but using Classes is/will make your coding life so much easier in the long run
Take your example of sales, instead of writing out 100’s of lines of code for each said such item it would make life easier to create a class of such said sales widget and then if other widgets become available then subclass the main widget and adjust , easy peasy
They’re very different things, with different, complementary roles to play. In a sense, they’re diametric - a class encapsulates related properties and methods for situations where you envision having multiple instances of the object, whereas a module makes its methods and properties available to all parts of the application so they don’t need to be duplicated. I usually have a System module containing stuff particular to just this app - usually things of which there’s only one instance, like a master dictionary of something or other to which many parts of the app need to refer, and also many program-wide constants. I also have modules for Prefs, Updater, String Utilities and the like that go into all my apps. Many of my modules contain classes, for instance I do a lot of FTP, so I have an FTP module that contains methods for uploading and downloading as well as the CURLSMBS objects that do the low-level stuff - it helps with Navigator clutter.
If I have a program dealing with a particular widget, I make a class “Widget” - then I can have arrays of Widgets and dictionaries of Widgets instead of arrays and dictionaries of loose Widget properties, and windows with methods pertaining only to the functionality of each window rather than the internals of the Widgets themselves. If I have an app that needs to scour a server for files having certain properties, I make a class called “FileScourer” - there’s no need for that code to be in a window or module. If I need to speed up my app or make it more responsive, I make FileScourer a subclass of thread, and since all the functionality is encapsulated in the class, it’s trivial to instantiate a bunch of them and unleash them all at once.
Extending Derk’s example, the most basic effect of the difference between a module and a class is this:
Consider a Module representing a car:
Col as color, Bootcontents as String
It exists immediately.
if you change Bootcontents to “Groceries” , everyone looking in the boot sees the same thing.
Anything one person put in the boot would still be there when another person drives the car.
if we create a Class called car with the same properties, there are initially no cars, we just know what one looks like.
Create an instance of car
Dim JeffCar as new car
JeffCar.color = &cff0000 // mid life crisis
Jeffcar.Bottcontents = “Toolbox”
Dim JuliaCar as new car
JuliaCar.color = &cffffff
Juliacar.Bootcontents = “Laptop”
These cars are independant … putting something into Julia’s car boot will not affect the JeffCar at all.
We can repaint the cars.
We can dispose of the cars by setting them to nil.
A car can have methods like Fuel, Drive, Park and so on.
Later, if we want to consider a 3 tonne truck, we might start with a Car class, and create a new class called Truck, which inherits from Car but adds Trailer aspects.
Since Trailers dont have a boot, you can imagine that both Car and Truck might inherit from a simpler class called vehicle. And later on, we might create a Hovercraft class based on that.
So I’m going to just put this out there. Somewhere along my programming career, I stumbled on Apple’s attempt to bring high quality college courses to the masses, they called it iTunesU. There were a series of courses that came out of Stanford about programming that I remember wishing that I’d had access to when I had been learning object oriented programming which made it so clear, it may have saved me months of studying. The one in particular that would help here is still available online, as long as you can ignore the fact that he’s talking about Java and realize that the basic concepts are the same:
You’ll want lecture 5-11. Luckily the professor is very entertaining.
at a module properties exists only once, you can reuse this but you are at risk not clear all with default values and mix it with previous data.
a good example for the use of classes is a multiplayer game and a player class.
each player have it own data, score, position, status, direction, speed.
and if this players have to be moved this method can executed parallel at different cores.
classes can solve more complex situations where you would stuck with modules.
modules have usually a mix of many not related methods.
you could call modul method names from a modul with modul name prefix but a class encapsulate it better.