Modular Programming...

[I_AM_DON_AND_YOU?]

This is the scenario:

I have a VB.Net project comprising of a few Forms. On Form1 I have more than
20 buttons. There is a very lenghty code written in click event of each and
every button. Right now I haven't used any sub procedure. I mean to say I am
writing the code directly in the click event. So it's become very lengthy
and therefore to figure out some problem or make any changes I have to
scroll at lot. Also in addition to click event procedures there are may
other events where code is written. It's kind of mess.

My question is would it be good idea if I add 20 Modules and name them
Button1Code, Button2Code etc.etc. and create one procedure in all of them
which will contain the code of Button's click event. Then it would be easier
to quickly find out the code. For example I would know that if I have to
make changes in the click event of Button1 then I have to go to Button1Code
Module (and check the procedure in it), and so on..

Is this a good idea? What are your suggestions.

Thanks in advance!

 

[Robin Tucker]

No - that would be overkill. Perhaps abstracting some functionality into a
"utility" module might make sense, depending on how similar the button
functions are. If they are all doing the same thing, then obviously
methods/subs should be constructed to take advantage of this.

Well, show us a couple of snippets of button code so we can make a better
judgement.

 

[Jay B. Harlow [MVP - Outlook]]

Don,
I tend to follow OOP programming over straight Modular programming. Where
code is broken out into different classes, where each class is its own "unit
of responsibility"

How similar is the code in each of the 20 buttons? If the code is largely
the same except for one or two values, or one or two sections. I would
consider creating a new button class that inherits from Button, the one or
two values that are unique per button I would make properties of this class.
The one or two sections I would make events. On the form I would use my new
button class, setting the properties per button that are unique, the form
would handle any unique events. The click event within the new class would
have all the common code, it would use either the events or the properties
for the distinct values per button.

If I have the "same" 20 buttons on multiple forms, then I would consider
create a class for each button, each form would get an instance of that
class. I don't use this one very often.

You can use #region within your form's code to help organize the event
handlers.

Generally I do not move a subroutine (event handler) from a form to a module
to organize my code as I rarely have routines so large that they make the
form's code unmanageable.

Hope this helps
Jay

 

[I_AM_DON_AND_YOU?]

99% of code written in all the click event is different. Why you think it
would "overkill" ?

Thanks!

 

[I_AM_DON_AND_YOU?]

99% of code written in all the click event is different.

Thanks

 

[Jay B. Harlow [MVP - Outlook]]

Don,
Did you read the COMPLETE message, did the other two comments help?

Hope this helps
Jay

 

[I_AM_DON_AND_YOU?]

You wrote:
"..............You can use #region within your form's code to help organize
the event handlers....."

Could you tell me how it helps us to organize event handlers.

Thanks!

 

[Robin Tucker]

Like I say, its difficult to judge based on what you have told us.

For example, if you are writing code to handle 20 different types of image
file - one for each type, I would not have a problem breaking it into 20
different classes (21!) with a base class and derived classes. But there is
little point making modules - you might as well #region each button.

 

[Tom Leylan]

My question is would it be good idea if I add 20 Modules and name them
Button1Code, Button2Code etc.etc. and create one procedure in all of them

As was pointed out by someone else when they used the term "overkill"... you
are basically trading one long relatively unmanageable form for 20 small but
still relatively unmanageable modules. Extremes in either direction are
usually a bad thing. It wouldn't be easy (for instance) if all your books
were on one long bookshelf... the alternative needn't be a single bookshelf
for every book however.

As an alternative you could add a single module that contained 20
procedures. That way you've divided the mess into two parts rather than 21
parts. Additionally you should avoid naming any module "Button#Code" as a
button is simply a UI component. It happens to be the way you designed the
operation to be run but it isn't what the operation "does." If Button #2
happened to be labeled "Save Customer" then the subroutine could be called
SaveCustomer but never Button2Routine.

All things being equal however, you can just try your idea out. Make 20
modules and cut and paste the code. I don't think you will find it easier,
I'll guess most people believe you will find it harder... on the other hand
if you find it easier then who's to argue?

 

[I_AM_DON_AND_YOU?]

Could you tell what you mean to say by this:

".....you might as well #region each button...."

Thanks!

 

[Jay B. Harlow [MVP - Outlook]]

Don,
You can use #regions to group related handlers into collapsible sections of
code.

For example in the form I have open right now. I have

#Region " File menu support "

Private Sub menuFileClose_Click(...) Handles menuFileClose.Click
me.Close()
End Sub

...

#End Region

#Region " View menu support "
...

#End Region

Where the first region has all the event handlers for the file menu, while
the second region has all the event handlers for the view menu.

When I open the above form in Code view, both of the above sections are
collapsed by default. If I need to work on the File Menu I open that
section, if I need to work on the View menu I open that section.

You could put your button click handlers into similar sections. Either a
single section, individual sections or grouped logically.

Also, "Edit - Outlining" has a number of options to show or hide routines. I
use "Collapse to Definitions" and "Toggle all Outlining" on the "Edit -
Outlining" routinely, to help find which routine I want to work on, then I
manually expand that one routine.

Hope this helps
Jay

 

[Robin Tucker]

Well its a simple little trick to maybe reduce the amount of scrolling you
have to do:

#region "Button 1"
' code for button 1
#end region

#region "Button 2"
' code for button 2
#end region

Then, you will be able to "expand/collapse" the regions. I do this with a
rather heavy form I have, breaking it down into various handler subgroup
regions. Just makes it easier to see structure thats all.

 

[Jay B. Harlow [MVP - Outlook]]

Don,
I should add that there is a Refactoring http://www.refactoring.com where
you can replace a Method with a Method Object. The Method Object is a class
that contains the code for the method.

http://www.refactoring.com/catalog/replaceMethodWithMethodObject.html

The parameters to the method become parameters to the objects Constructor,
while the class has a single method (initially) that is the body of the
original method. The intent is then to refactor this method into smaller
more manageable methods.

However I am concerned that you are heading toward what Tom has stated, "you
are basically trading one long relatively unmanageable form for 20 small but
still relatively unmanageable modules" along with an unmanageable form.

As I stated in my other post I tend to follow OOP, and I tend to follow the
smaller routines are better routines rule.

If you do go the 20 module route, I would strongly suggest 20 classes, where
the procedure in each class is declared as Shared.

Public NotInheritable Class Form1Button2Code
Private Sub New()
End Sub

Public Shared Sub Button2Click()
End Sub

End Class

This requires you to use the class name to call the procedure, helping to
encapsulate the method better. Also I included the name of the form with the
name of the class, to better identify that the code really belongs to the
form. Encapsulation is another OOP term. Its better to Encapsulate the
button handlers in the form, as then all the code for the form is with the
form.

Note the NotInheritable on the class prevents others from deriving from the
class, the Private Sub New prevents instances from being created, which is
effectively what a Module does. However a Module you can call its routines
without giving the module name, you then have no real idea where the routine
came from. With using a class as above you at least know the routine came
from the above class.

Hope this helps
Jay

 

[I_AM_DON_AND_YOU?]

Thanks. It's new thing for me. It would have been good if we could able to
insert Region WITHIN a click event also.

 

[I_AM_DON_AND_YOU?]

Thanks. I will use this "Region...End Region.." structure.

Also, do you have any (similar) idea to hide/unhide the code within one
procedure.

 

[Jay B. Harlow [MVP - Outlook]]

Don,
As I mentioned, I find smaller routines are better. Rather then have one
long routine, I tend to have many smaller routines. With smaller routines in
most cases you will probably have better code reuse.

With smaller routines, you don't need to hide code within the routine
itself, using the options on the outlining menu, you can hide or unhide the
routine bodies...

Hope this helps
Jay

 

[Cor]

Hi Jay B,

Lets start with, we totaly agree. But I have a question. I am of course from
an old fashion time.

What I have always thought was that modulair programming was to divide your
project in managable structures, with reusable code in all parts of your
project.

The best way to do that is in my eyes is using OOP techniques.

When I reads this kinds of threads I always think. Modulair programming is
translated as using old fashion VB modules, which have in my eyes nothing to
do with modulair programming.

What is it what I see wrong?

Cor

 

[Jay B. Harlow [MVP - Outlook]]

Cor,
Its one of those things that it is both.

The way I view it is, in the simplest sense Modular program is breaking your
problem into individual modules. This can be applied to almost all
programming languages, including languages that do not support Object
Oriented Programming. For example on the AS400 (iSeries) I can apply modular
programming to an RPG or COBOL program, by breaking my RPG or COBOL program
in to manageable modules.

OOP definitely encompasses modular programming as you group (divide) your
project into manageable structures or classes...

Hope this helps
Jay

 

[Tom Leylan]

When I reads this kinds of threads I always think. Modulair programming is
translated as using old fashion VB modules, which have in my eyes nothing to
do with modulair programming.

What is it what I see wrong?

I'll jump in and suggest you have it correct. People seem to be mistaking
"modules" with modular programming. Writing modularly is a logical
consideration which promotes code re-use while reducing maintenance
headaches. Modules are physical things and are little more than a storage
mechanism.

It is quite possible to write a "modular" program in a single physical
program file or to write a completely non-modular program which is stored in
a dozen or two module files. I wrote a short article named "Function
Reusability and Contracts" which attempted to illustrate the idea... it
ended with "remember, a dumb function is a smart function."

Meaning of course that anything it needs to know is passed in and any
results are passed back. It isn't typically considered modular if the
routine relies on some public variables being present and it isn't
considered modular if the function you devise to calculate the cubed root
automatically displays the result in a textbox.

 

[I_AM_DON_AND_YOU?]

Can we read your article?