Partial Classes

Out of several enchancements available in .NET 2.0 partial classes is one of them. Partial classes simply means that you can break your class and write them separately (as if they were separate entities). This becomes a useful feature when you have a large class that does more than one thing. If you open a software engineering book, you are likely to find statements like: “…your function/classes should do one thing and do it well”. Yes, this is an ideal situation but often times when modeling the real-world the developer is forced to combine multiple funcationlity within one class. This is specially true in a web-environment because there is a tendency to combine UI and logic. Pros The .NET model simply does an amazing job of separating design and logic. But with the current model, if you add some controls your classes will contain a list of all the WebControl members such as TextBox, RadioButton and so on. This is really UI and should be separate from the logic of the class. In .NET 2.0 however, you can separate all the UI members and move it to a partial class. Then write another partial class that will contain only the logic side of the page. A far more clearner and easier to maintain technique. Cons Since partial classes allow you to separate the class definitions anywhere within the current namespace, there might be a tendency from the developer to have large partial classes that does far too many things. What this does is you have a structured program masked with OOP keywords all over the place, and not a “true” object-oriented program. To the programmer it might appear as if he/she is using sound software-engineering methodologies because they are using class, structures, delegates and partial classes! Underneath all this keywords however is a flat structured program with lots of functions! So in conclusion, even though partial classes a great way to separate “functionality” of a class one must be careful and continue to follow sound practices.