There's no better authority than one's boss, except perhaps one's experience. Convince the boss that this sloppy habit will cost valuable maintenance time down the road and let the boss create a coding standards policy that addresses this. Although they may kick and scream at the thought of such a policy, it is in the best interests of the company.
If that doesn't work, let 'em write whatever sloppy gunk they want-only they have to maintain it. That'll learn 'em. -----Original Message----- From: dotnet discussion [mailto:[EMAIL PROTECTED]] On Behalf Of Rod Falanga Sent: Wednesday, May 01, 2002 11:28 AM To: [EMAIL PROTECTED] Subject: [DOTNET] VS.NET: Would like a pointer to an article, book, whatever, which describes why it is best to leave controls Protected We've been working with VS.NET since beta 1, although it hasn't been easy going for us. I have been quite excited by the product since Beta 2. And having some C++ background, I am thrilled to be once again doing some "real" OOP again. To date, our work has been primarily on writing ASP.NET pages, although we've written one or two Win Form apps as well, but nothing of any consequence at the moment. As I'm sure you all know, one of the tenets of OOP is information hiding. And one of the ways that I see VS.NET achieves this is by marking all controls put onto a form (either Win Form or Web Form) as being Protected. This has proven to be, for my co-workers, a very frustrating thing, since they are most comfortable with being able to interact directly with any control on any form, from anywhere within a VB program, by merely referencing the form and DOT control name (e.g.: frmSomeForm.txtLastName). My co-workers don't like to have to write either methods or properties referencing the values of the controls they wanted to address. I knew that all one had to do was change the Protected attribute to Public, and they could then access the control the way they used to. However, at least to my way of thinking, that violates good OOP paradigm, and in essence brings one back to the object-based approach that VB had up to version 6, at least in large measure. For that reason, I didn't mention that you could change the control's attribute in that fashion. Well, one of my co-workers has discovered on his own, that you can change a control's Protected attribute to Public. So, now I'm disappointed. And also I am concerned that this will lead us down a path of potentially sloppy programming style. (One of my other co-workers would prefer, if she had her way, that we declare all variables used in a program in a .BAS file, so they could be globally accessible. Fortunately, we've been able to change that habit.) I can, of course, attempt to use what I see as good OOP techniques, but I am a member of a team, and have to bow to the will of the group, or at least team leader, if it comes to a difference in programming style. Therefore I solicit your help. I have no "authority", in the sense that I haven't written a book, or article, or given a talk at VBITS, or TechEd, etc. However, if someone else who HAS either written a book, article, given a talk, in essence has a "name", has said that it really is better to leave controls' Protected attribute alone, then I could show it to my colleagues and maybe they will agree that's a better way to go. So, does anyone know of a book (in any .NET language, I don't care, but VB.NET would probably be better) that espouses leaving all controls' Protected attributes alone, for good OOP reasons; please tell me about that book or article! I would prefer to show them such an article or book, and win their approval for better OOP practices, based upon an authority, rather than on my word alone. I work with intelligent people, who I am sure would agree to leave controls' Protected attribute alone, if shown that an authority says leaving controls' Protected attribute alone, is a better way to achieve good OOP practices. Rod You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
