Vitor Rubio Developer - Dicas de programação

Hoje eu programo orientado a objetos. Pelo menos eu "acho" isso. Conheci muita gente que dizia que programava orientado a objetos mas na verdade programava de maneira procedural, orientado a evento ou RAD. Não que as outras metodologias sejam ruins, mas é que muitas vezes elas são a ferramenta errada para se resolver  o problema. Além disso muitos programadores misturam as metodologias combinando o pior das duas em vez de o melhor das duas. Já vi até programadores dizerem que programam orientado a objeto simplesmente porque a linguagem é orientada a objeto, ou pior ainda, porque a IDE tem "objetos" que você arrasta e solta em uma "form" e que você acessa funções (métodos) destes com seu nome e um ".". Meu amigo, isso é RAD e não POO. Embora RAD tenha o seu valor para prototipação e aplicações rápidas e sujas, não é um bom ambiente de desenvolvimento a longo prazo. É uma programação orientada a evento degenerada. Além disso, por mais que a l...

Um dos assuntos que estudamos em ciência da computação ou processamento de dados que eu mais gosto é: Algoritmos e Estrutura de Dados. Se bem que gostar não é garantia de dominar, né? É sempre um assunto meio complicado. Admiro muito os professores dessa  matéria, que resolvem problemas desse tipo quase sem pensar. Uma das coisas que se estuda nessa matéria é a Lista Ligada.  Trata-se de uma estrutura simples, porém poderosa, onde um atributo desta estrutura é um dado (de qualquer tipo que o programador queira) e um ponteiro para um próximo objeto de mesmo tipo. Se o ponteiro for null (em linguagens c-like, nil em pascal, nothing em basic) significa que não há próximo objeto. Abaixo a figura de um nó da lista. Esses nós podem ser ligados uns aos outros em cadeias, conforme a figura abaixo. Além disso as listas podem ter dois ponteiros, um apontando para o elemento posterior e outro apontando para o anterior, formando uma lista duplamente ligada. A lista pode t...

Em hierarquias longas de objetos é importante saber onde colocar o código dos contructors (construtores) pois eles tem uma ordem lógica para executar e, se for um parameterless constructor (construtor sem parâmetros) então todos os parameterless constructors serão executados desde a raiz object. Um parameterless constructor sempre executa o parameterless constructor da classe base (pai), mas um construtor com parâmetros você deve especificar: :this([parametros]) para executar um outro constructor na mesma classe e deixar a hierarquia seguir sucessivamente :base([parametros]) para executar um constructor específico da classe base NADA para executar o parameterless constructor da base. O programa abaixo ilustra isso. using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; namespace HerancaConstrutor { class ClasseBase { public ClasseBase() { Console.WriteLine("parameter...

Recentemente me perguntaram no site da DevMedia se é correto ou não misturar interfaces e objetos em uma conversão temporária, como esta abaixo: var C: TCarro; begin C := TCarro.Create; //tenho um objeto, mas C não conta referencias C.Placa := 'ABC1234'; (C as ICarro).Rodar; //converte e roda na mesma linha, mas zera o contador de referencias na proxima linha C.Parar; //isso dá erro Segue links da Thread: http://www.devmedia.com.br/poo-dominando-o-uso-de-interfaces-revista-clube-delphi-134/22569 http://www.vitorrubio.com.br/downloads/TesteInterfaces.zip http://www.vitorrubio.com.br/downloads/CD134_Interfaces_V2_Reformulado.zip Isso por causa do problema de se zerar o contador de referências em interfaces tendo mais uma referência ao objeto em uma variável do tipo objeto e destruir esse objeto prematuramente. Basicamente nesses casos o comportamento esperado seria um erro. Pode acontecer de o objeto continuar acessível na memória, ou pelo menos alguns méto...

Um leitor deu a dica de fazer um lookup que chame uma das forms do projeto. Há várias maneiras de se fazer isso, mas uma que encontrei foi usar formulários registrados com RegisterClass. Depois é só usar FindClass para encontrar o formulário, e FindComponent para encontrar o componente onde reside o valor a ser trazido. Se o componente for um TPersistentField, melhor ainda. Ele pode ser achado, e com um typecast para TField seu valor (o valor encontrado e escolhido no formulario de procura/cadastro padrão) pode ser trazido para o keyvalue. Abaixo um exemplo de como isso pode ser feito. Primeiro o registro do formulario: initialization RegisterClass(TfrmConsulta); Depois a chamada dele. Repare que ele é desconhecido para o formulário principal: não está no uses. procedure TfrmPrincipal.Button1Click(Sender: TObject); var NewFormClass: TFormClass; NewForm: TForm; begin NewFormClass := TFormClass(FindClass( 'TFrmConsulta' )); //detalhe: esse string 'TFrmConsu...

Saiu na revista Clube Delphi 131 dois artigos meus: um sobre bancos de dados gratuitos e outro sobre a criação de um componente lookup genérico . Lokups são campos utilizados para fazer a ligação entre duas entidades, duas tabelas. Em uma tabela de venda, por exemplo, há informações sobre o código do cliente para quem a venda está sendo feita, o código da forma de pagamento, e assim por diante. Um formulário não deve ter campos para se digitar os códigos diretamente, e sim campos lookup, que possam ser usados para procurar a forma de pagamento, o cliente e as outras informações em questão pelo nome e não pelo código. Neste artigo fizemos um lookup, usando um ButtonedEdit e um formulário com grid,  que pode funcionar em múltiplos bancos de dados e que traz os registros filtrando-os, usando para isso uma instrução SQL montada sob demanda. Isso ajuda a diminuir o tempo de abertura dos formulários e o tempo de carregamento dos lookups, bem como a quantidade de registros trazida n...

Saiu a Clube Delphi 128, e dessa vez o meu artigo é capa! Agradeço ao Guinther Pauli , editor da revista, pela paciência que tem com meus atrasos :p Meu artigo sobre interoperabilidade  explica como integrar sistemas Delphi Win32, .Net e talvez outros através de DLLs, COM, WebServices e troca de mensagens pela API do windows. Mostro nesse artigo como consumir uma DLL feita em Delphi através do .Net, como consumir pelo Delphi uma DLL .Net através da integração COM, como consumir pelo Delphi um webservice feito em .Net e como fazer as aplicações se comunicarem via API do windows. Lógico, sobre interoperabilidade fiquei devendo, por questões de tempo e espaço, algumas coisinhas que pretendo mencionar em artigos futuros, na revista e/ou neste blog: .Net consumindo webservice em Delphi  Introdução do Lazarus na brincadeira  Integração por sockets  Integração por xml, json e txt Por enquanto não vejo a hora de ler os artigos sobre programação Android com fre...

Se você ler o livro Padrões de Projeto   verá que há uma crítica quanto ao uso indiscriminado de Herança. Na verdade o livro mostra que existem outras maneiras de se incorporar ou agregar várias funcionalidades e depois conseguir incorporar ainda outras sem  o uso de herança. Lendo este livro você verá que há uma discrepância grande entre a Análise Orientada a Objeto (AOO) e a Programação Orientada a Objeto (POO). Enquanto a AOO defende que não pode existir em código nenhum objeto que não seja representante ou modelo de um objeto do "mundo real" a POO, por restrições e questões técnicas, apresenta as figuras das classes de persistência (inexistentes no mundo real) dos DTO (data transfer objects, também inexistentes) dentre outros modelos e padrões. Além disso, em POO você pode ver coisas como sobrecarga de operadores, caso em que a AOO nem sequer cita. Enquanto o livro Padrões de Projeto foca na POO, ignorando algumas premissas da AOO, ele também põe a herança em s...

Nesta série de artigos estaremos criando, do zero, um sistema de Account Management (gerenciamento de contas de usuário). Hoje em dia um relógio não representa mais nenhum avanço tecnológico, visto que todo e qualquer aparelho moderno deve possuir um relógio como requisito mais básico. Celulares, aparelhos de som, DVD players, Blu-Ray (e o extinto videocassete), microondas, televisores, monitores, agendas, calculadoras, telefones fixos, videogames e qualquer outro aparelho pode vir com um relógio, e geralmente vem. O relógio passou do status de  produto tecnológico para ser apenas um ingrediente, uma peça. É exatamente isso que está acontecendo com os sistemas de Account Management, aqui chamados de AMS. Veja que enquanto alguns dizem que o CRM é o topo da evolução de sistemas para gerenciamento de clientes, o CRM serve apenas para gerenciar contato e relacionamento com os clientes. A tendência de o CRM tentar centralizar os dados a respeito de clientes de todos os outros s...

Você já se perguntou como suprimir o método Create para que não seja utilizado? Tentar "esconder" o constructor colocando-o como private não irá funcionar por um motivo simples: ao utilizar o create será visível e perfeitamente "invocável" o create da classe base, que não conterá as informações necessárias para criar realmente o objeto e poderá causar access violations. O que fazer então? Na verdade o constructor create nada mais é do que uma espécie de class method (método de classe) especial que serve como alias para o NewInstance. O Create atua como um factory method nativo e bem simples, sendo o  NewInstance que efetivamente aloca memória e constroi o objeto. Então uma maneira muito elegante de se criar um singleton é, em vez de disparar um exception caso o método create seja executado mais de uma vez, sobrecarregar os métodos NewInstance e FreeInstance para impedir que de fato o objeto seja criado duas vezes, ou destruido antes do tempo. Esses m...