Skip to main content

C# 2.0 - Partial Types

For those of you interested, i found a very interesting list of features that were introduced in C# in here. This is a very complete list that contains all the features, and i'm explaining them one by one in this post series. We've talked about Generics and Iterators. Now it's time for some partial types.

A partial type is a type which definition is spread across one or more files. It doesn't have to be in multiple separated files, but can be. This is a very simple concept that can give us many benefits, let's see:
  • If a type is partial, multiple developers can work on every part of it. This allows a more organized way of working and can lead to production improvement. 
  • Winforms, for example, generates a partial class for the form so that the client can separately edit other parts it. This way, a part contains information about the design and the other contains the logic of the form. In fact, this is a very spread pattern across .Net. Entity Framework uses this too. The T4 Template by default creates partial classes for each entity and then we can create other parts of the same class to include our business logic without worrying with it getting overwritten. 
  • There is virtually no performance penalty in using partial types, because at compile time the parts will be unified. So, this is really just a convenience feature.
We can also create partial interfaces, structs and methods (not sure if this was introduced in 2.0). In case of methods, we need to be sure that they return void.

Below are some inconveniences of using partial types:
  • A partial type generally has it's logic or definition spread across it's parts, so it can be difficult to find the piece of code you want (this is arguably a bad argument, because today's IDE's overcome this problem.).
  • When using a partial type, sometimes may become hard to know every attribute a class implements, or every interface (also, the same as before).
To be clear, a partial type is always the sum of it's attributes, implemented interfaces, generic type parameters, documentation, etc. Let's see an example:

This is equivalent to:

To use a partial type, keep in mind that the partial declarations must obviously be in the same namespace.

Thank you for reading, next time i'll talk about nullable types!

Comments

Popular posts from this blog

The repository's repository

Ever since I started delving into architecture,  and specifically service oriented architecture, there has been one matter where opinions get divided. Let me state the problem first, and then take a look at both sides of the barricade. Given that your service layer needs to access persistent storage, how do you model that layer? It is almost common knowledge what to do here: use the Repository design pattern. So we look at the pattern and decide that it seems simple enough! Let's implement the shit out of it! Now, let's say that you will use an ORM - here comes trouble. Specifically we're using EF, but we could be talking about NHibernate or really any other. The real divisive theme is this question: should you be using the repository pattern at all when you use an ORM? I'll flat out say it: I don't think you should... except with good reason. So, sharpen your swords, pray to your gods and come with me to fight this war... or maybe stay in the couch?

The evolution of C# - Part III - C# 2.0 - Iterators

It's been a while since i wrote the last post, but i did not forget my purpose of creating a series that shows the evolution of C#. Today i came here to talk about one of the most useful features of C#, even if you dont know you're using it. Let's talk about iterators ! What is an iterator? For those of you who didn't read about the iterator pattern somewhere in the internet or in the "Gang of Four" book, you can read a description  here . The iterator is a class/object/whatever which knows how to traverse a structure. So, if you have a list or collection of objects, an iterator would have the knowledge of how to traverse that collection and access each element that it contains. The iterator is a well known design pattern and is behind many of the wonderful that we have nowadays in .NET (Linq comes to mind). Why is it a feature? Truth be told, an iterator is a concept well known way before .NET even existed. Being an OO Design Pattern, the iterator has

My simplest and most useful type

I have been doing some introspection on the way I write code to find ways that I need to improve. I consider this a task that one must do periodically so that we keep organized. There is a very, very simple problem that occurs in every application I know: How to return the results of an operation to the user? I've seen many implementations. Some return strings, some throw exceptions, some use out parameters, reuse the domain classes and have extra properties in there, etc. There is a myriad of ways of accomplishing this. This is the one I use. I don't like throwing exceptions. There are certainly cases where you have no choice, but I always avoid that. Throughout my architectures there is a single prevalent type that hasn't changed for years now, and I consider that a sign of stability. It is so simple, yet so useful everywhere. The name may shock you, take a look: Yes, this is it. Take a moment to compose yourself. Mind you, this is used everywhere , in every