Just a couple of quick questions for the experts on best practise really.
I’ve created a module in my program that now contains 8 methods and 5 properties. Everything is working really well to this point. The program contains the main window and a small number of other windows that open up in response to button clicks.
Now those methods I have in the module use a mixture of the module properties, and values that are passed directly to them, and doing this has meant that I can use some of them more than once in the program; only a couple of them though.
The other option I have of course is to attach methods within the windows, keep the properties local to it, and use a couple of module properties as and when needed.
Question is then, would the favoured way be to keep all my methods in the module and keep all my properties in there as well, or place the methods within each window and use local properties with just a couple of global ones ?
Are there specific benefits to using either approach ?
Second much simpler question is this:
In respect of the buttons I use, I can add actual code to the buttons events as needed, or I can create a method and then call the method in response to the button click. Is there any preference for this too ? I currently use the second way because its a bit easier when navigating the code in the IDE to have all the methods in one place, plus if I change a button or control I dont have to start copying large amounts of code around, I can simply call the method from the new/revised control.
Stephen,
I personally keep all methods and properties local to the window which uses it, unless the method can be called from multiple windows - in which case I put the method in a module.
I simply do this in order to prevent possible problems, and to prevent my module from containing potentially hundreds of methods, and becoming hard to find what I need.
I believe you should keep methods and properties together with the object they relate to.
I mean, if a windows subclass has a property named “Foo” which relate to its behavior, makes no sense to store it in a separate module. This become more evident if you use the window as a real subclass and thus you instantiate from it with
dim w as New MyWindow
In this way every instance of your MyWindow subclass will have their private property.
Same is for methods: think to windows as objects (like they are) and ask yourself if the method you are invoking is something which is part of the window object in term of handling properties and behaviors of the object itself.
Additionally, start declaring as Private the window properties (as well other objects properties), and you will be forced more to keep this separation. You will eventually make some method or properties public at some point, but only the necessary, not more.
About the second question, I agree is better to keep a separate method for the implementation of the button behavior.
This also permits you to have a better separation from the UI and the logic. It also allow to call the method from different places, this happens very often.
Thanks chaps. I was thinking about code duplication by attaching them to the individual windows but even that is negated at least to some degree by the fact i can reduce the code size and do less checking of the properties. This is the first time Ive used so many windows in one app though, and I can see the benefit of keeping code local to the window.
Does anyone know of any benefits, or otherwise, in terms of how Xojo compiles and runs the code, in relation to these options ? If there is a given approach that benefits that process, or is more friendly to the compiler ?
I believe you should not think to the compiler.
In most case I’d say it makes almost no difference to the compiler. However it makes a big difference on how you can maintain you code. Most of these concerns are driven from the need of having a code more structured and easier to maintain.
Despite the current Xojo compiler is not the most advanced in terms of optimizations, with modern compilers is better to let it decide how to optimize the code and avoid premature optimizations from your part.
Three sheet windows that are called from the main window in response to button clicks - these sheet windows represent Create/Edit/Delete options for a record already selected in the main window.
When each sheet window opens, it calls the method inside the module, and passes an integer ID to identify itself. That method then retrieves the record (In case of Edit/Delete) and displays the fields in the window.
Inside the method, I have along these lines :
…Do stuff to retrieve record from db
Select Case WindowIdentifier
Case 0
…Add fields to wEditWindow
Case 1
…Add fields to wDeleteWindow
End
Is this better left as is, or should I add more specific code to each individual window and ditch the method in the module ?
Retrieving the record data would be duplicated, but populating the fields from it would not.
So basically each sheet window opens, and passes an id into the method in a module.
The method then adds fields to the appropriate sheet window.
It sounds fine to me, as it is.
This way you only have 1 method to update (if ever necessary), and each window calls it.
Otherwise, each time you wanted to make modifications, you would need to edit the code inside numerous different windows.
So just to reiterate - I would keep code used by multiple windows in a method inside a module, but in general, keep code attached to each window.
Obviously this is only my opinion, and there are a lot more experienced users on this forum, who may offer more sound advice.
Your description of the edit/delete, etc functions cries out for a class to handle your data I/O… As far as OOP techniques much better to use a class and create instances to the minimum necessary scope than to place everything in a global module.
Absolutely agree with Dave. If you have a need to duplicate code, then make a method/function out of it. Then you can call it consistently from other locations. This could be a good use of putting it on a Common_Module.
The module should know nothing of individual windows.
You shouldn’t have more than one window for add/edit/delete.
You should have a single window to display/edit the data. That way, all functionality is encapsulated in a single object (the window). If you change the structure of the data - add/delete fields - you have a single place to update your code.
There are two competing goals here:
Never duplicate code
Never make the same code to more than one thing
That may seem contradictory at times, but that dissonance indicates you need to rethink your approach and factor your code better.
Or perhaps you continue with refactoring in mind once you get the functionality working as you would like. There is nothing wrong with that approach especially when you are starting out. Everyone gets better each project they work on and usually are refactoring as new techniques are learned and tested.
