Mostrando postagens com marcador OOP. Mostrar todas as postagens
Mostrando postagens com marcador OOP. Mostrar todas as postagens

sábado, 5 de julho de 2014

Swing! A primeira impressão não é a que fica.

Como é bom mudar de opinião e ver as coisas sobre outra perspectiva. Nunca conseguiria ser como as pessoas que morrem com uma opinião fixa sobre alguma coisa, muitas vezes sem ao mesmo ter tido alguma experiência com o motivo da opinião.  Já havia escrito sobre isso no Facebook, mas com o sucesso do projeto no qual estou trabalhando decidi falar sobre isso aqui no blog também.

Algum tempo atrás eu redescobri o Swing! Não é o que você está pensando é o Java Swing. Antigamente, não gostava do seu modelo, achava demasiado complicado! Para mim a melhor plataforma para criação de interfaces com o usuário era a disponibilizada pelo Delphi. O modelo do Swing não podia se comparar as facilidades disponibilizadas por ele .

quinta-feira, 14 de fevereiro de 2013

E o programador virou pedreiro!


Qual é o papel atual do programador no projeto de um sistema na industria de software brasileira? Eu digo que é de pedreiro e explico o motivo!

No inicio da era da informática, a atividade de programação era tudo em um projeto de software. A criação de um sistema era considerada uma arte. Cabia ao programador criar sistemas que controlavam os misteriosos e novos computadores utilizando uma linguagem compartilhada entre eles e as máquinas. Essa atividade era executada por “gente estranha”, normalmente engenheiros que viravam a noite se dedicando a entender a língua das máquinas de modo a poder “conversar” com elas. Os sistemas criados por eles, normalmente, eram muitos específicos e muito ligado ao hardware. Muitas vezes, a programação era considerada uma ação secundária e vinculada ao projeto de hardware.

Com a evolução dos computadores e sua rápida disseminação, surgiram novas linguagens de programação de modo a facilitar criação dos softwares e a permitir que eles fossem compartilhados entre máquinas diferentes e pudessem realizar as mais diversas tarefas. O software, nesse momento, começa a ocupar um papel importante nas organizações, sendo responsável pela automatização de diferentes tarefas. O hardware se torna secundário e o software assume a frente.

sexta-feira, 14 de janeiro de 2011

A Melhor Linguagem de Programação

Volta e meia, em diversos fóruns, vejo a pergunta: Qual a melhor linguagem de programação? Ou ainda: Devo apreender C# ou Java? (eu achei Delphi legal mas me disseram que está morrendo). Há tem ainda ruby, que ta todo mundo usando!


A verdade sobre qual a melhor linguagem de programação é que não existe melhor linguagem de programação!!! Infâmia, blasfêmia, dirão os religiosos Java, principalmente, embora programadores xiitas existam em qualquer linguagem (tem gente que acha Clipper excelente e usa até hoje), mas isso é assunto para outro post. A verdade é que não existe melhor linguagem de programação e sim a melhor linguagem para resolver determinado problema no menor tempo e com o menor custo! 

Em principio você pode escolher qualquer linguagem para resolver qualquer problema e os programadores tendem a querer fazer isso na linguagem que dominam, criando assim bizarrices. Sempre haverá alguém que dirá que VB é horrível, que Assembly, (sim é Assembly e não Assembler) não se usa mais. Esses programadores tendem a reinventar a roda, pois seu conhecimento é limitado a uma linguagem e, pelo senso comum, tendem a criticar outras linguagens. Sim existem pessoas que tiveram problemas com outras linguagens e as criticam, eu mesmo não sou fã de VB, porém se o problema que eu quero resolver é simples o suficiente para ser feito por uma macro no Excel e eu posso fazer isso em alguns minutos em vez de levar algumas semanas criando um aplicativo eu vou utilizar VBA para criar essa macro e resolver rapidamente o problema. O mesmo se aplica a domínios específicos, como microcontroladores, onde normalmente é usado C e quando existem problemas de memória e velocidade se usa Assembly. Agora eu não vou usar Assembly para desenvolver um editor de texto!

A casos em que domínio de uma aplicação é tão amplo e complexo que são utilizadas diversas linguagem a fim de representa-lo e resolver os problemas impostos por ele.

Se você chegou até aqui, deve estar pensando “Putz, ou que eu faço então!”. Simples, concentre seu aprendizado em apreender algum paradigma de programação e após isso pesquise e encontre uma linguagem que resolva da melhor maneira os problemas que você encontra. 

Também não existe melhor paradigma de programação, assim como as linguagens. Cada paradigma é melhor para problemas específicos. A base moderna dos paradigmas é a programação estruturada, das quais derivam a programação procedural e a programação orientada a objetos. A programação procedural funciona bem para domínios muito simples já programação a programação orientada a objetos se aplica melhor a domínios mais complexos. Embora existam outros paradigmas, estes são os mais utilizados.

O problema é que a maioria dos programadores não conhecem os paradigmas e “cozinham” software espaguete. Programadores que utilizam uma linguagem OO produzem código procedural, e os procedurais produzem coisas inomináveis. Regras simples como “uma função uma responsabilidade” não são respeitadas o que gera funções monstruosas, com centenas de linhas, totalmente impossível de se entender e quem dirá manter ou expandir.

Todo o programador deve conhecer o paradigma de programação estruturada, a escolha de um paradigma procedural ou OO vai depender do domínio do problema. Martin Fowler no seu livro Padrões de Arquitetura de aplicações Corporativa diz: 
"Embora possamos identificar as três camadas usuais, apresentação,domínio e fonte de dados, em cada aplicação corporativa, a maneira simples para extrair dados de um único banco de dados e exibi-lo na Web pode, todo ele, consistir de um único procedimento. Eu ainda me esforçaria para separar as três camadas, mas, neste caso, poderia fazê-lo simplesmente colocando o comportamento de cada camada em sub-rotinas separadas. Se o sistema se tornasse mais complexo, quebraria as três camadas em classes separadas. Se a complexidade aumenta-se ainda mais, dividira as classes em pacotes separados"
O programador deve desenvolver o “feeling”, para notar quando deve refatorar seu código para outro paradigma. Ele deve estar atento a evolução da complexidade do seu código e tomar as medidas necessárias para que isso não saia de controle.

Quando um programador verifica que um paradigma ou uma linguagem não é a mais adequada ao domínio do seu problema e muda seu sistema utilizando um outro paradigma ou outra linguagem ele deixa de ser um programador para se tornar um desenvolvedor de software.

Como dica, posso dizer que entenda o paradigma estrutural, e estude com afinco OO e só então estude o paradigma procedural, pois é muito mais fácil entender o procedural após OO do que o contrário, por isso que muitos programadores Java acham que criam programas OO, mas estão desenvolvendo software de maneira procedural. Utilizar classes não qualifica um programa como OO.

Outra dica são os livros da a série como programar dos Deitel, que é extremamente didática e inclui muitas boas práticas de programação além de explicar os paradigmas.

Ah, e a propósito, todo desenvolvedor deveria conhecer C, pelo menos a título de curiosidade. Um excelente livro sobre essa linguagem é o C Completo e Total do Herbert Schildt.