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 - refactoring untestable code - an introduction

I started testing my code automatically a couple of years in after starting my career. Working in a small company, there weren't really incentives for us to automate testing and we were not following any kind of best practices. Our way of working was to write the code, test it manually and then just Release It ™ , preferably on a Friday of course. I'm sure everyone can relate to this at some point in their career, because this is a lot more common than the Almighty Programming Gods of the Internet make us believe. I find that the amount of companies that actually bother writing tests for their production code is a fraction of the whole universe. I know some friends who work in pretty big companies with big names in the industry and even there the same mindset exists. Of course, at some point in time our code turned into a big pile of shit . Nobody really knew what was going on and where. We had quantum-level switcheroo that nobody really wanted to touch, and I suspect it i...

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

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