Introdução
Vou começar escrevendo no blog algumas razões de preferir o C# ao invés do VB.Net ao desenvolver uma aplicação. Deixo claro que isso é uma comparação de sintaxe da linguagem e sintaxe cada um tem sua preferência, por isso vou explicar o porquê de eu preferir o C#.
O Visual Basic.Net tem uma sintaxe simples e ainda vem por padrão com o Option Strict Off, esses dois fatores combinado ainda com o Visual Studio torna o VB.Net uma linguagem muito fácil de se programar. É realmente uma maravilha para os iniciantes e isso é um grande mérito da linguagem.
Mas há pontos na sintaxe que você pode se meter em incríveis confusões. Parece até um filme de sessão da tarde não é mesmo? Vamos ver onde estão essas tais confusões e como podemos tentar evitá-las tornando o código mais “profissional” possível.
Falando em deixar o código mais “profissional” é isso que o C# normalmente te obriga, e muitas das confusões no VB.Net podem ser resolvidas com o Option Strict On que evita uma série de erros, deixando seu código mais bonito e rápido, acredite vale a pena ligar o amiguinho.
A sintaxe do VB.Net pode deixar você confuso e quebra até conceitos de orientação a objetos, vou explicar mais abaixo.
Construtor Padrão Fora do Padrão
Quando você cria o “Form1” pelo Visual Studio, você está criando uma classe, Ok? Essa classe descende da classe System.Windows.Forms.Form e está divida em duas partes, uma fica o código do Design(no arquivo Form1.Designer.vb) gerado normalmente pela ferramenta que tem o método InitializeComponent e a outra a sua implementação(no arquivo Form1.vb).
O método InitializeComponent é quem inicializa todos seus componentes, se ele não for executado nada vai aparecer na tela, mas onde ele é chamado? Resposta: No construtor que fica escondido.
Isso é confuso, pois você não vai encontrar a chamada do método a não ser que você implemente um construtor, então basta escrever a assinatura do construtor e dar um enter para o Visual Studio preencher o conteúdo que estava oculto para você.
Public Sub New()
' This call is required by the Windows Form Designer.
InitializeComponent()
' Add any initialization after the InitializeComponent() call.
End Sub
Só para deixa claro, toda classe tem um construtor, e quando você não implementa ele fica com o construtor padrão que por sua vez não tem nenhuma instrução dentro dele. Mas no VB.Net qualquer form que você crie, o construtor padrão não é mais padrão.
Parece Shared Mas Não é Shared
Ainda falando sobre os forms do VB.Net, como você executa o método Show no seu “Form1”?
Um form é uma classe, e caso você queira usar um método dessa classe, você precisa criar uma instancia do form, a não ser que o método do form seja Shared(static em C#, Java...) certo?
Bem, no VB.Net você consegue chamar um método que não é shared sem instanciar um objeto, isso vale apenas para as classes que descendem da classe Form, ou seja, todos os formulários que você cria.
O VB.Net deixa você chamar qualquer método da classe "Form1" sem necessidade de instanciar por questões de retrocompatibilidade com o VB6:
Form1.Show()
O correto seria:
Dim frm As New Form1() frm.Show()
No primeiro caso é criado automaticamente uma instancia do "Form1" e depois é executado o método Show, más você não fica com a referencia dessa instancia como é no segundo caso onde está armazenada a referencia na variável 'frm' e você tem um controle total daquela instancia e pode até criar várias instancias de um único form.
Chegando ao Fim da Parte 1
Quando comecei a aprender orientação a objetos fiquei confuso nos dois casos acima. Não fiz nenhuma comparação direta com o C# porque simplesmente não acontece isso nele. Há mais casos ainda que irei abordar nos próximos posts e se você não sabe o que o Option Strict faz e nem sabe sobre métodos shared e construtores fique tranqüilo que irei abordar nos próximos posts também.
Até a próxima,
Tiago Esmeraldino
