Refactoring In Visual Basic

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

But there is InheritanceInVisualBasic! (...and ways to do VisualBasicImplementationInheritance.)

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.

Recently (late 1999) I've joined a new project, where I'll have the opportunity to try RefactoringInVisualBasic. Thus far, I've successfully applied the following refactorings (described in MartinFowler's RefactoringImprovingTheDesignOfExistingCode book):

• ConsolidateDuplicateConditionalFragments (page 243)
• ReplaceMagicNumberWithSymbolicConstant (page 204)

• VbRefactorTypeToClass (like MartinFowler's ReplaceRecordWithDataClass, page 217)
• ConsolidateDuplicateConditionalFragments
• RefactorIntroduceWith / RefactorEliminateWith, RefactorMatchLoopToUsage, RefactorNegateIf, RefactorDefaultOrElse, RefactorRenestBlocks
• ReduceScopeOfVariable
• RenameClassInVb
• and others...

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

To keep this page general (it seems to have started like that), I have moved some text to ExperiencesWithRefactoringInVisualBasic. -- WillemBogaerts

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.

This page mirrored in WikiPagesAboutRefactoring as of April 29, 2006