Orientação a objetos
From Sistemas2a
A Orientação a Objeto é um paradigma de análise, projeto e programação de sistemas de software baseado na composição e interação entre diversas unidades de software chamadas objetos.
A análise e projeto orientados a objetos têm como meta identificar o melhor conjunto de objetos para descrever um sistema de software. O funcionamento deste sistema se dá através do relacionamento e troca de mensagens entre estes objetos. A utilização de UML é muito comum no projeto de sistemas orientados a objetos.
Na programação orientada a objetos, implementa-se um conjunto de classes que definem os objetos presentes no sistema de software. Cada classe determina o comportamento (definidos nos métodos) e estados possíveis (atributos) de seus objetos, assim como o relacionamento com outros objetos (interface).
Contents |
[edit] Paradigmas da Orientação a Objetos
Os Paradigmas são normas. Como um código de conduta - qualquer semelhança é mera coincidência - são seguidas à risca. Os paradigmas diferem o que parece ser um objeto do que realmente é um objeto. Uma programação procedural orientada a eventos, se feita modularmente, pode enganar novatos. Um objeto só será um objeto se puder satisfazer essas normas. Os Paradigmas são Tipos, Classes e Objetos, Herança, Polimorfismo, Encapsulamento e Mensagens.
FmLApe Thanks:) Cool topic, write more often! You manage with it perfctly:D
[edit] Herança
Herança é a partir de uma classe você criar outra classe, sem começar do zero, aproveitando todos os atributos e métodos da classe anterior, conhecida como classe Pai - por favor, sem discussões sobre porque A classe (feminino) é Pai(masculino). Quando o grande Desenvolvedor criou o Homem e a Mulher, ele utilizou herança em ambas a partir da classe Humano; no homem ele colocou juízo e na mulher livre arbítrio, sabe, coisas do tipo? Ambos tem uma cabeça com coisas e coisas, um trocon com coisas e coisas - umas diferentes, graças ao grande Desenvolvedor! - e enfim, quando se instanciam, são objetos filhos de uma mesma classe pai - Humanos - mas pertencentes a classes diferentes - Homem e Mulher. Sendo mais realista, imaginel uma classe "usuário", simples assim: username e password; ela pode ser classe pai de um aluno e um cliente, pois apesar de serem diferentes, possuem nome e uma senha de acesso. Essa reusabilidade gerada pela herança permite atualizações e adaptações rápidas e mais eficazes. Imaginando que você ainda tenha outras derivações como funcionários, e outras 10~15 derivações (!), caso haja a necessidade de uma alteração comum a todas, ao modificar-se a classe pai - "usuário" - TODAS as outras classes derivadas passariam a possuir aquelas modificações.
[edit] Polimorfismo
Algo que é polimórfico tem várias formas. Um objeto possui polimorfismo, que nada mais é que assumir em uma dada situação o papel de outro objeto pertencente a outra classe. Sua instanciação permanece a mesma, somente seu comportamente muda. Um objeto só pode assumir o comportamente de outra classe se essa lhe for ancestral, ou seja, "em nome do meeeeu P'Ai", sacaram? Bom, como tem muita ligação com herança, coloquei assim em seguida para dar o exemplo: nosso "aluno" é filho da classe "usuário", assim como "funcionário" ou "cliente"; num caso de precisar-se de uma função de verificação de username e password, o argumento poderia ser um ponteiro da classe "usuário", e nessa função eu posso passar como argumento qualquer filho de "usuário" que ele vai saber agir "em nome do pai". Isso se aplica à chamada dos métodos de uma classe também.
[edit] Encapsulamento
Encapsular é esconder. Existem uma série de rotinas complexas por trás de uma simples validação de campos. Esse é o ponto, pois parece errado dizer que existe algo complexo em uma coisa simples. O usuário do seu sistema deve ver, sentir, perceber algo simples e isso acontece porque as rotinas estão bem encapsuladas. Analogia: quando você se alimenta, come qualquer coisa, existem vários processos, como morder, mastigar, engolir, digerir e absorver. Eu sou leigo em questões fisiológicas, e digo que isso é o suficiente para mim! Agora, esses processos que são claros escondem - encapsulam - uma série de ações de químicas e enzimas, com nomes funções específicas, conhecidas por um especialista. No desenvolvimento de sistemas, você é esse especialista, deve montar tudo de forma que você saiba o que está acontecendo, e o usuário perceba que está funcionando. Para encapsular processos, utilizamos também de interfaces, visuais ou não, para tornar mais simples e intuitivo o uso do sistema. São parte de uma interface símbolos como minimizar, maximizar e fechar, setas à esquerda e direita como voltar e avançar, respectivamente, e outros.
[edit] Mensagens
Os Objetos de um sistema possuem métodos e atributos que devem ser particulares. Assim, nunca um objeto pode interfirir, modificar ou controlar métodos e atributos de outros objetos. Em uma primeira vista um leigo poderia pensar que os objetos não se relacionam, mas outra característica - norma - de objetos é que eles podem se comunicar. Assim, "educadamente um objeto pede a outro" que dispare um método ou informe sobre algum atributo. Imaginemos uma rotina que envolva um jogador e um servidor de jogos; o usuário, em primeiro instante, ainda não é o jogador-objeto; ao informar na tela de login seu username e sua senha, um método será disparado para logar esse usuário; as informações trocadas entre a tela de login e o servidor são mensagens. Imagine mais ainda: "olha servidor, tem um cara aqui que quer jogar, disse que o username é 'kruk' e a senha é 'kurk'" e o servidor ao receber a mensagem com esses parâmetros ativa seus métodos. A partir daí, de uma mensagem, o jogador poderia ser instanciado e virar um objeto jogador e se relacionar com o sistema.
