Dennis J. Bottjer | MVP ASP.NET

This weekend I decided to do a little reading and downloaded "Improving .NET Application Performance and Scalability" at http://msdn.microsoft.com/practices/EngPrac/default.aspx?pull=/library/en-us/dnpag/html/scalenet.asp.  This is a really good guide and provides you with theory, checklists, and how to's.  Anyway, one of the major themes was do not wait until an application is deployed to begin perforance tuning.  Instead the authors recommend that performance tuning should be part of the design process.

For performance to be part of the design process good performance must be defined.  Goals must be set for things like application load time, response time, and CPU and Memory utilization.  Once these goals are in place a base line has been established and we can collect data, analyze results, configure, test and messure.  This is a repeatable process that refines performance during development.

It seems possible to write .NET applications and never write interfaces.  It seems less likely to write .NET application and never use an interface.  So what are interfaces and how can they improve your code? 

Essentially, an interfaces is a contract or a template.  Interfaces allow us to define what our objects will do without worrying about how they will do it.  It is important to realize that interfaces are not instantiated like classes, they are just the definition and contain no implementation.  Interfaces are typically defined with a capital "I" followed by a name where the first letter of the name is capitalized.  While classes can only directly inherit from one base class, they can implement a nearly infinate amount of interfaces. 

An interesting use for interfaces is for defining method parameters.  Instead of defining an input parameter as a particular object we can define that parameter as an interface.  This is a powerful concept b/c it allows us to build more flexible methods that will accept any object that implements the same interface as the input parameter.  This same concept can be applied to return types.

Microsoft Developers are familar with properties.  Properties have been part of popular MS development tools such as Visual Basic for several version.  The tradition has continued in .NET with Win/Web forms controls. Developers can manipulate text, font color, font size, etc. via properties.  Perhaps a lesser known fact is that not all OO languages support properties.  Many languages simply support Public Fields.  A field is basically a fancy name for a class instance variable.  Many languages simply make these fields public instead of private or protected.  The danger in this practice is that it violates encapsulation and allows direct access to class data.  Using properties we are able to encapsulate our class data which allows for things such as data validation.  That is when a property is being set, the data being assigned to the property can be validate.  For example, we can make sure that a number or a date falls within a certain range.