Refactoring In Vb Classic

CategoryRefactoring:

"How can you refactor VbClassic when it's got no such thing as inheritance?"

See RefactoringInVisualBasic for refactoring in VisualBasicDotNet.

(...a discussion started in ExtremeProgrammingWithVbClassic.)

Answers:

Comments:

I have usually found that inheritance plays a small role in refactoring. I find that I use far more containment than inheritance, because the refactored portions often do not need to be exposed for application program use, and containment easily exposes the methods for testing.

Use subroutines!

You can shuffle code around.

There is no reason why you can't write good code in VB.

"Good Code" isn't the question. To refactor, you usually try to make things OnceAndOnlyOnce. How do you do that with subroutines?

Surely that is the point of a sub-routine? You have sub-routines that perform a piece of functionality that get called from the places where that code would, otherwise, need to be repeated.

"Bad code" is usually much harder to extract in another sub or function. Especially Exits (Exit For, Exit Sub, etc.) are a real pain, just like gotos. You'll be glad if the code you want to refactor is well structured. -- WillemBogaerts

I routinely practice code re-structuring as a part of refactoring. Building a unified point of exit inside the function (a 'Procedure_Exit' label), and then changing the Exits to 'Goto Procedure_Exit' provides extra structure (as well as an opportunity to clean up for the function before 'Exit Sub') to the function, and enables much refactoring.' -AaronCumming?

Encapsulation can be used in place of inheritance and most times it it superior to inheritance when refactoring.

It's been my experience that you can do Refactoring in practically any programming language, even if it's not object oriented: If you're working on a procedural program in a structured language, for example, it can be quite beneficial to refactor it, making it more Structured or Modular. (See StructuredProgramming and ModularProgramming.) I was quite successful, for a number of years, refactoring C programs, making them more reliable, robust, efficient, and maintainable.

So there's every reason to believe that one can successfully refactor VisualBasic programs: VisualBasic even supports creation of COM classes and objects.

Starting in 1999 I had some experience doing RefactoringInVisualBasic with VbClassic:

I applied some of the standard refactorings, as described in MartinFowler's RefactoringImprovingTheDesignOfExistingCode book:

And I started these pages to document VbClassic refactorings I was doing at the time: -- JeffGrigg

I've been working on making VB6 a more OO-Friendly language by exploring some... hmmm... unusual ways to instantiate objects. This has led me to what I call:

The IntroduceCreationObject Refactoring

I've used this in more than 3 different projects and my peers in the company seemed to like the results so they're using it as well. I wonder if it qualifies now as a Pattern? :)

-- AlfredoChavez

Refactoring, like DesignPatterns, is not applicable only to OOP languages. Likewise the principles laid out by SteveMcConnell in CodeComplete, while written for procedural/structured programming, are equally applicable to OOP languages. In fact, when presenting the ideas of Refactoring to other developers I use McConnell's discussions of the principles of cohesion and coupling as a way of identifying the most obvious smells that refactoring can address. -- SteveSawyer

The MediatorPattern can be used among a form's subroutines. Instead of having complicated, interacting events like cmdFoo_Click and txtBar_Change, the GUI update code can be delegated to a shared UpdateGui() subroutine. This UpdateGui() routine has the same role as the aFontDialogDirector mediator in the GangOfFour's example [GOF:274]. The interacting controls (cmdFoo and txtBar) are the colleagues in the GangOfFour's example.

CategoryVbClassic

EditText of this page (last edited February 12, 2009) or FindPage with title or text search