Firemonkey, ame-o ou o odeie!

Tempo de leitura: 3 minutos

Firemonkey é a mais nova framework de desenvolvimento de aplicativos no Delphi. Eu digo nova pois até então havia apenas a boa e velha VCL. O Firemonkey surgiu há cerca de 3 anos e eu o considero “utilizável” a partir do Delphi XE7, ou seja, há pouco mais de 1 ano. O surgimento do Firemonkey no Delphi causou um grande reboliço na comunidade Delphi. Aquele programador que se acha no Delphi, que programa desde o Delphi 1, está no mesmo nível de um programador que começa hoje se o assunto for Firemonkey.

Ainda me recordo de comentários como: “Que bug feio no Delphi, o index não começa mais com 0”. Ou então: “Que merda, onde eu troco a cor do Form”. Ou ainda: “Que palhaçada, não tem mais left e top, agora é position.X, position.Y, não sei pra quê? Isso estou me referindo apenas as coisas básicas. Se entremos na parte de desenvolvimento mobile então, ai são muitas pérolas. Eu ri muito já com cada coisa que eu li por ai!

Isso é perfeitamente normal! Afinal, o Firemonkey era, e ainda é, algo novo para todos nós. Por ser algo novo requer dedicação por parte daqueles que querem entender de fato como essa nova framework funciona. E foi isso que fiz por quase 12 meses. Se eu fosse resumir o Firemonkey em uma frase essa frase seria: O Firemonkey é tudo o que a VCL deveria e tentou ser e não conseguiu! Essa afirmação eu faço dada a estrutura de classes do Firemonkey. Para começar ele é todo baseado em interfaces o que reduz muito o acoplamento e com isso o efeito colateral caso haja alguma alteração. Além disso, sabemos que a boa prática prega: “Programa para uma interface, nunca para uma classe concreta.”. Logo podemos concluir que o Firemonkey nesse aspecto emprega com louvor essa boa prática.

Firemonkey, uma relação de amor e ódio!

Por esse motivo, comparações de Firemonkey com a VCL são quase que um crime. São duas coisas completamente diferentes, com propósitos diferentes. E para terror dos programadores de OnExit e OnShow o Firemonkey nos obriga a entender de padrão de projetos, POO e boas práticas. A começar por ele próprio que é todo baseado na arquitetura MVC. Quer outro exemplo? Não há componentes Dataware, os famosos DBEdit e DBGrids, no Firemonkey temos que usar Livebindings e Livebindings não é outra coisa que padrão Observer na prática. Logo os que falam mal de Livebindings provavelmente não enxergam o benefício de se trabalhar com esse padrão.

Diante disso é fácil entender que, quando o assunto é Firemonkey, ou você o ama e o adota e dá graças a Deus por ter sido obrigado a trabalhar da forma correta. Ou então você o amaldiçoa pois não consegue fazer nele seus códigos espaguete com os quais estava acostumado na VCL. Não podemos esquecer que estamos falando de programadores Delphi e esses “seres” são muito, mas muito criativos. Eles se esforçam para fazer aquele POG bonito mesmo em um ambiente propício a trabalhar da forma correta.

Eu poderia ficar aqui dias escrevendo sobre todos os benefícios de se trabalhar com Firemonkey e principalmente de estudar os conceitos nos quais eles está apoiado mas vamos por partes e devagar. No próximo post vamos conhecer um pouco mais sobre a estrutura da FMX e quais são as classes chaves dentro desta estrutura.

Por hora é isso, nos vemos no próximo post!

  • Bem… eu não odeio o firemonkey. Ainda não gosto dele… Mas odiar é demais.
    Contudo, a seguinte frase “Ou então você o amaldiçoa pois não consegue fazer nele seus códigos espaguete com os quais estava acostumado na VCL” me assusta muito.
    Umas das coisas que eu odeio no Java (e os que me conhecem sabem o quanto eu odeio essa porcaria) é que ele te obriga a trabalhar do jeito dele, ou seja, você “não consegue fazer nele seus códigos espaguetes”. Entende onde eu quero chegar?
    Nenhuma linguagem ou programação deve limitar o estilo de programação do programador. Se eu julgo por bem que naquele momento é devido usar o código espaguete, caso a linguagem não me permita faze-lo, eu vou xingar e amaldiçoa-la. Quem é ela pra determinar o que eu, rei e senhor do meu projeto, deus único e absoluto do meu código posso ou não fazer?