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

From crappy to happy - dependency what, now?

Following the introduction on this series on a previous post, we will now talk about dependency injection and how it has the effect of allowing for more testable code. Sometimes when I talk about this concept it is difficult to explain the effect that applying it might have on the tests. For that reason I think it is better to demonstrate with a near-real-world situation. Obviously, keep in mind this is not real code, so don't worry about the design or implementation details that don't contribute to the point being discussed. The code As you can see, it is simple. There's a class called ShipManager (what else?) that receives position updates for the ships. It keeps the last position reported from each ship and does some calculation to see how much the ship moved. It assigns some values to the update and finally it persists the final version of the update. How do we start testing? When you think about it, tests are dead simple. A test either passes or it doesn...

Why is the Single Responsability Principle important?

The Single Responsability Principle is one of the five S.O.L.I.D. principles in which i base my everyday programming. It tells us how a method or class should have only one responsability. Not a long time ago i was designing a reporting service with my colleague Nuno for an application module we were redoing and we had a method that was responsible for being both the factory method of a popup view and showing it to the user. You can see where this is going now... I figured out it would not be a that bad violation of the principle, so we moved on with this design. The method was called something like "ShowPrintPopup" and it took an IReport as an argument. All this was fine, but then we got to a point where we needed to have a permissions system to say if the user was able to export the report to Excel, Word, PDF, etc... The problem was the print popup would need to know beforehand if it would allow the user to export the report or not, so that it could show it's UI a...

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