Nada melhor do que uma introdução antes de aprender a programar em uma linguagem orientada ao objeto. O termo OOP é um acrônimo de Object-Oriented Programming que traduzindo significa Programação Orientada ao Objeto (POO). Esse tipo de programação não é tão nova, não foi inventada nos anos 80 como se acredita por Bjarne Stroustrup migrando a velha linguagem C estruturada para o C++. Na realidade já existiam linguagens orientadas ao objeto antes do C++ como o SIMULA 1 da década de 60, mais precisamente 1962, e Simula 67 de 1967. As linguagens Simula foram inventadas por Ole-John Dahl e Kristen Nygaard, no Centro Norueguês de Computação, Oslo, Noruega. Mas foi em 1990 que a POO ou OOP se destacou com o filhotinho chamado C++.
Com a linguagem que consolidou a POO veio também não só um maior poder de desenvolvimento, mas também complexidade. Era como matar mosquito com canhão. Em determinados momentos era necessário uma linguagem que não fosse tão complexa para desenvolver alguns simples projetos usando POO. Em outros casos vemos que o POO ajuda a diminuir a complexidade na manutenção do código, isso acontece em sua maioria com grandes projetos. O trabalho com grandes equipes também é muito facilitado com este novo paradigma.
Mas foi em janeiro de 1991 em Aspen, Colorado, quando James Gosling, Bill Joy, Patrick Naughton, Mike Sheradin, e várias pessoas se reuniram para discutir idéias para o Stealth Project, um projeto que pretendia desenvolver dispositivos eletrônicos inteligentes capazes de serem controlados e programados centralizadamente a partir de um Handheld. Eles decidiram que POO era a direção certa para o desenvolvimento da linguagem, mas ponderou sobre o uso do C++, resultando na criação de uma nova linguagem chamada Oak que acabou por problemas de patente mudando para Java.
O Java cresceu rapidamente em popularidade, impulsionados pelo crescimento da Web. Este rápido crescimento foi devido, a integração dos navegadores para rodar programas Java na Web. Rapidamente tornou-se parte integrante de várias páginas Web. Com a melhoria das funcionalidades da Web graças ao Java, a Web estava a mil por hora.
Os conceitos básicos do paradigma orientado ao objeto são relativamente fáceis de compreender e aplicar. Alguns dos motivos para o uso de objetos pode parecer bastante obscura nesta fase inicial, especialmente se você não tem muita experiência com o as técnicas antigas de programação (programação estruturada e metodologias estruturadas). A abordagem orientada para objeto foi inventada (ou, pelo contrário, evoluiu) devido a dificuldades que as pessoas estavam tendo a tentar obter bons sistemas de qualidade produzidos a tempo e dentro do orçamento, especialmente para grandes sistemas com muitas pessoas envolvidas.
Segue alguns motivos para usar o paradigma orientado ao objeto:
• Os objetos são mais fáceis de entender para nós seres humanos: os objetos são derivados de algo que estamos tentando automatizar, algo da vida real. Com essa abordagem não somos influenciados por procedimentos computacionais ou requisitos de armazenamento de dados. Por exemplo, em um sistema bancário, nós programamos em termos de contas bancárias, caixas e clientes, em vez de mergulhar em procedimentos de depósito e retirada de conta, e algoritmos de empréstimo.
• Os especialistas podem se comunicar melhor: tipicamente, o primeiro degrau é programador: reparador de falhas (bugs) no código escrito por outros. A segunda posição é programador sênior: escreve o código propriamente dito. O terceiro é designer: decide se o código precisa ser escrito. Por último vem o papel do analista: conversa com os clientes para descobrir o que eles precisam e, em seguida, estabelece uma especificação do que o sistema deve ser capaz de fazer.
Esta escala de trabalho não é uma má idéia em si. O problema surge quando você percebe que cada especialista tem que aprender todo um novo conjunto de conceitos e técnicas usando notações próprias às suas especialidades, isto é, no final todos precisam entender de tudo e registram cada um à sua maneira. Isso significa que há uma grande lacuna no entendimento entre os diferentes níveis agravado pelo fato de que a documentação tem ser transmitida especialista a especialista até chegar ao topo, e geralmente estes documentos tendem a ser lidos sem compreensão total das técnicas utilizadas para produzi-los. Isto pode conduzir a um grande problema: o analista produz uma grande quantidade de documentação, mostra-o para o designer. O designer, depois de semanas de esforço, produz ainda mais documentação, usando técnicas completamente diferentes, e envia a documentação para os programadores. Os programadores então começam tudo de novo. . . readaptando a sua realidade. Que perda de tempo!
Com abordagem orientada ao objeto, toda a gente pode lidar com os mesmos conceitos e notações. Além disso, primeiramente, há geralmente menos conceitos e menos para lidar com notações.
• Os dados e os processos não são artificialmente separados: nos métodos tradicionais, os dados que necessitam ser armazenados separadamente no início dos algoritmos que atuam sobre aqueles dados e só então depois eles são então desenvolvidos independentemente. Isso pode resultar em inconvenientes, em se tratando de dados, de formatos ou locais, no que diz respeito aos processos que necessitam de ser acessados (um site escrito sem suporte a escrita orientais é um inconveniente para os orientais). Com desenvolvimento orientado ao objeto, dados e processos são mantidos juntos e organizados de um modo simples de gerenciar. Os dados nunca é separado do algoritmo. Isso acaba também complexidade do código, complexidade essa que não facilita alterações no código para suprir as necessidades dos clientes.
• O código pode ser reutilizado com mais facilidade: com a abordagem tradicional, começamos com o problema que precisa ser resolvido, e permitimos a condução de todo o desenvolvimento em torno desse problema. Nós acabamos com uma solução primitiva para o problema de hoje. Mas o amanhã sempre traz um problema diferente para resolver, não importa quão fácil o novo problema é ou se é o último. Nós devemos ser capazes de quebrar nossa visão primitiva do sistema que dificulta para nós mesmos permitindo que um único problema influencie todas as partes do sistema. Temos que aprender a enxergar o projeto sob o novo paradigma.
Com o desenvolvimento orientado ao objeto, estamos constantemente à procura de objetos que sejam úteis em sistemas similares. Mesmo quando um novo sistema tem pequenas diferenças, estamos muito mais susceptíveis de ser capazes de mudar o código existente para se ajustar, porque objetos são como as peças de um quebra-cabeça: se uma peça for alterada, poderá afetar alguns pedaços ao lado dela, mas a resto do quebra-cabeça irá permanecer intacta. Nós tentamos encontrar os objetos existentes (escrito por nós, pelos nossos colegas ou por terceiros), antes de escrever qualquer código por nós mesmos. Como um sábio disse: "Programação orientada ao objeto trata sobre não escrever código". Estes conceitos de programação quando aplicado em áreas como software, bases de dados e redes aumenta a facilidade de compreensão sobre esses sistemas.
Termos:
-----------------------------------------------------------------------------------
Paradigma
[Do gr. parádeigma, pelo lat. tard. paradigma.]
Substantivo masculino.
1.Modelo, padrão, estalão: "D. Luís de Meneses .... parece constituir o paradigma da síntese ideal .... entre a coragem militar e o academismo cultural." (Antônio José Saraiva e Óscar Lopes, História da Literatura Portuguesa, pp. 455-456). 2.Termo com o qual Thomas Kuhn (v. kuhniano) designou as realizações científicas (p. ex., a dinâmica de Newton ou a química de Lavoisier) que geram modelos que, por período mais ou menos longo e de modo mais ou menos explícito, orientam o desenvolvimento posterior das pesquisas exclusivamente na busca da solução para os problemas por elas suscitados. 3.E. Ling. Conjunto de formas flexionais de uma palavra. 4.E. Ling. Modelo para a flexão de uma dada classe de elementos: o verbo amar serve de paradigma à primeira conjugação. [V. conjugação e declinação.] 5.E. Ling. Conjunto de elementos lingüísticos que podem ocorrer nos mesmos ambientes. [Cf. sintagma.] Paradigma defectivo. 1. E. Ling. Paradigma (3) a que faltam formas, como ocorre com os verbos defectivos portugueses.
-----------------------------------------------------------------------------------
Referências
Beginning C# 3.0 : an introduction to object oriented programming / Jack Purdum.
Object-Oriented Programming with PHP5 / Hasin Hayder.
Object-Oriented Analysis and Design: Understanding System Development with UML 2.0 / Mike O'Docherty.
Dicionário Aurélio 2004 / Aurélio Buarque de Holanda
OOP, POO, Introdução ao Curso de POO
Postagens
