Maximizing.ASP.dot.NET.Real.World.ObjectOriented.Development [Electronic resources] نسخه متنی

Assessing Your Needs and Requirements

I hate writing documentation. To a certain degree, I don't like finding out what exactly it is that my customer wants either (because we all know exactly what customers need). Gathering requirements just isn't as fun as hacking out some code and making the little box do something.

Sadly, this guerilla coding technique creates all kinds of problems. The truth is that we don't know what our customers need, and without documenting your goals, you'll be stuck in an endless mode of revisions and tweaks, and you'll never get your product out the door. So important are requirements that many large books have been written on the subject, and many colleges require a course on requirements gathering in their computer science curriculum.

Once again, there is no universal truth. Among the core tenants of extreme or agile programming are that your code is the documentation and that short iterations of development lead to more efficient code that gets to market faster. Having worked in that environment, I agree that there are a lot of advantages to this approach to development, particularly with back-end components or systems that process huge amounts of data without user interaction.

Books have been written on class design too, and somewhere in the world, a class probably is being held on the subject right now. There are dozens of popular design patterns that are widely accepted to tackle common problems. If you really want to be a student of these patterns, I encourage you to read up on them. Many can be found that are specific to .NET (some in the .NET Framework SDK), and more general books can show you patterns that are more platform-neutral.

A class should encapsulate some kind of functionality into an easy-to-use package, and you shouldn't have to understand its underlying code in order to use it. Our car analogy demonstrated this ideawe don't care how the engine works, or even if it's a gasoline motor or a hybrid (assuming of course that you're not an environmentalist). All we care about is that a car does what we needit gets us between points. When we design a class, we concentrate on what we want the class to do (i.e., its "behavior"), not how we want the class to do it.