Skip to main content

C# 2.0 - Nullable Types

São 3 da manhã e não me apetece dormir. Estive a ajudar um amigo meu a trabalhar no código dele e estou apenas parcialmente cansado. Bem, porque não continuar com a série sobre a evolução do C#? Vamos a isso!

Desta vez vamos falar de nullable types. Já todos utilizámos, mas no .NET 1.0 eles não existiam. Como é que representávamos um valor vazio? Uma string pode conter null, supostamente é essa a representação do valor vazio. Como é que representamos um valor numérico vazio? Verificamos se é maior que 0? Bem, nalguns casos é exactamente isso que fazemos. Ou isso, ou criamos um valor constante que representa um "não valor". Mas para mim isto não é expressivo suficiente.

Basicamente, um nullable type é apenas um non-nullable type envolvido na estrutura System.Nullable. Esta é uma estrutura genérica por isso faz uso dos Generics introduzidos no C# 2.0. A estrutura é bastante simples, contém apenas uma propriedade HasValue e Value. Ambas são muito explícitas e isto torna as coisas mais fáceis de trabalhar. Em relação à sintaxe, vejamos o seguinte:


As duas linhas acima têm o mesmo significado. Podemos atribuir null a ambas as variáveis e utilizar as mesmas propriedades. É apenas uma facilidade sintáctica!.
Na minha opinião, nullable types trazem os seguintes benefícios:
  • Acrescentam simplicidade ao lidar com bases de dados. Em T-SQL podemos ter um int, numeric e outros tipos nullable.
  • Podem transmitir o significado de um parâmetro/variável mais facilmente. Se esse parâmetro for opcional, é mais fácil deixá-lo nullable (apesar de hoje em dia termos também parâmetros opcionais).
Não é possível ter reference types nullable (nem sequer faz sentido) nem nullable dentro de outro nullable (um nullable duplo?). Esta é uma feature muito pequena que passa despercebida para algumas pessoas que conheço e portanto pode ser menos utilizada do que merece.

Obrigado e até à próxima!

Disclaimer: Esta foi uma tradução literal do post em Inglês, por isso a informação não é actual.

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? ...

Follow up: improving the Result type from feedback

This post is a follow up on the previous post. It presents an approach on how to return values from a method. I got some great feedback both good and bad from other people, and with that I will present now the updated code taking that feedback into account. Here is the original: And the modified version: Following is some of the most important feedback which led to this. Make it an immutable struct This was a useful one. I can't say that I have ever found a problem with having the Result type as a class, but that is just a matter of scale. The point of this is that now we avoid allocating memory in high usage scenarios. This was a problem of scale, easily solvable. Return a tuple instead of using a dedicated Result type The initial implementation comes from a long time ago, when C# did not have (good) support for tuples and deconstruction wasn't heard of. You would have to deal with the Tuple type, which was a bit of a hassle. I feel it would complicate the ...

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. Ent...