I l @ ve RuBoard |
I haven't really said much about Visual Basic yet. Everything I've said so far applies to all applications, regardless of what language they're implemented in. But since this book is about enterprise application development in Visual Basic .NET, I should spend a least a little time looking at the language itself. Visual Basic has traditionally been about lowering the bar for developers and about making development more accessible to more people. Microsoft's vision for Visual Basic .NET has not really changed in this regard, but Microsoft has added a host of important features to the language and thrown out a lot of legacy deadweight. Still, it is important to understand Visual Basic .NET in its historical context. Visual Basic Then and NowIn the past, I always said that you don't build large applications in Visual Basic, you build them around Visual Basic. This was true because the needs of enterprise or large-scale applications were at odds with Visual Basic ”mostly because of the lack of important object-oriented programming (OOP) features that would make large-scale development projects manageable. This often led to code bloat and odd designs that were difficult to maintain. Classic Visual Basic was not without its benefits, however. Thanks to a development environment and COM-based architecture, you could create large, complex applications quickly. Visual Basic has always been known as a rapid application development (RAD) platform. One fairly common approach to developing applications was to implement them quickly in Visual Basic and then isolate the critical performance areas and replace the components with Visual C++ components . This type of development offered three distinct advantages:
The Limitations of COMVisual Basic wasn't the only problem when it came to developing large applications, however. COM didn't always make things easy, either. COM has to be the most successful component architecture in the entire history of computing. It made its first appearance in 1993 and has become the dominant component architecture for the Windows platform. Visual Basic 6.0 is by far the best platform for creating COM components quickly and easily. But COM is not without its own problems:
Visual Basic: The Next GenerationVisual Basic .NET is a major advancement as a language and development platform. The years of cut-and-paste "inheritance" are finally over now that a real OOP infrastructure of implementation inheritance is available. Even though Visual Basic .NET offers several improvements over previous versions, it has retained its RAD roots. At the same time, the combination of Visual Basic .NET and the .NET Framework provides a wealth of features unmatched by classic Visual Basic. More Info Chapter 2 addresses many of the advanced language and platform features that are critical to large system implementations and maintenance. Moving Beyond COMVisual Basic .NET and the .NET common language runtime (CLR) address the limitations of COM in four key areas:
Good Coding PracticesNothing can substitute for good coding practices. Despite the features of Visual Basic .NET and the .NET Framework that enable better application design and implementation, nothing can prevent someone from designing a poorly implemented application. Quite the contrary. With the .NET Framework being so new, it will take developers time to train and adjust to a new way of thinking. It is all too easy to fall into the trap of thinking in "the old ways," leading to some pretty poor designs. Unfortunately, this is an inevitability for any new platform and the .NET platform will not be any different. Implicit vs. Explicit ProgrammingThis is a point that I'll periodically revisit throughout the book and that you should burn into the back of your mind: explicit programming gooood; implicit programming baaad. Implicit programming can take many forms. But it can be summed up as a practice in which the intent of the code is not obvious, nor is it enforced. When I say the intent of the code is not obvious, I mean precisely that. The interfaces supported by a class give you no indication of how they should be properly used. Enforcement, on the other hand, is all about the original developer preventing unsupported use of a class. When you design classes, methods, and interfaces, you should always do so in a way that makes their intended use obvious and makes it difficult or impossible to use them in an unintended way. From the OOP design perspective, this can mean several things. For example, if a class should not be inherited from, you should declare it NotInheritable . If a class should only be derived from, not instantiated , you should declare it with MustInherit . Methods should always define their parameters as specifically as possible. Using Object as a type provides flexibility but can also lead to errors. When you declare regular variables , you should also use the most specific type possible. This will reduce the options other developers have when they use your libraries and will minimize the chances for mistakes. Explicit programming also lets you do more design-time validation of your code, which can save you a lot of headaches . Design-time validation is essential to the modern programmer. It essentially allows you to detect certain errors as you type, rather than having to first compile the application and then run it to detect errors. This can be a huge time-saver and reduces the potential for common types of programming errors. More Info I'll talk more about implicit programming in Chapter 2, where I'll also discuss the use of late binding. Naming ConventionsVisual Basic .NET is, like all earlier versions of Visual Basic, case-insensitive. This can lead to poor or inconsistent variable and function names , but Microsoft has established a set of style guidelines for the .NET platform that are reasonably easy to follow. In the past, the recommended form of naming more or less followed the rules of Hungarian notation. If you've ever dealt with variables that look like pszName or lpszClassName , you know what I'm talking about. Visual Basic was never so strict, but you do see variations on the theme. There were, and continue to be, several reasons for this usage in languages such as C++. First and foremost, you cannot evaluate types at run time. (COM objects do allow this through QueryInterface but in a limited way.) If a type is already known, you're in good shape ”hence the funny -looking variable names. The .NET Framework frees you from some of these problems. Through the miracle of reflection, you can always evaluate not only the Type (note the capital T ) of a variable but also all the types from which it's derived and all the interfaces it implements. This is intrinsic to the platform itself and alleviates the potential confusion of variable types. More Info Check out Chapter 6 for more information on runtime type checking and evaluation. Given this new ability to evaluate types at run time, the designers of the NET Framework decided that they could do away with Hungarian notation ”it was never very pretty anyway ”and employ a more readable and user-friendly notation. The following sections describe the naming practices that Microsoft recommends for methods and variables. (This material is adapted from a paper entitled "Coding Techniques and Programming Practices" by Rob Caron. You can find the full document at http://www.msdn.microsoft.com/library/en-us/dnvsgen/html/cfr.asp.) MethodsFollow these guidelines regarding methods:
VariablesFollow these guidelines regarding variables:
|
I l @ ve RuBoard |