Aulas 33 e 34

EXTREME PROGRAMMING

Antes de começarmos a entender o que é XP, vamos analisar um pouco da evolução do desenvolvimento de software ao passar do tempo:
Por volta de 1960 os computadores começaram a ser utilizados cada vez com mais intensidade nas empresas, uma vez que, até então, estavam quase que exclusivamente limitados ao uso militar. As máquinas eram caríssimas, e por isso, seus recursos deveriam ser explorados ao máximo. Os programas eram otimizados ao extremo para a arquitetura do computador em que iriam rodar, e os poucos programadores que existiam não estavam muito preocupados com a legibilidade do que escreviam, até porque não tinham mesmo muita opção. Existem muitas histórias sobre programas de computadores que simplesmente tinham que ser descartados quando uma arquitetura de hardware era substituída por outra.

Valores

Feedback
Algumas pessoas seriam capazes de caminhar na beira de um precipício com os olhos fechados, ou colocar a maior parte do seu dinheiro em um investimento com elevada chance de prejuízo sem acompanhá-lo de perto. Entretanto, a maioria das pessoas provavelmente manteria os olhos bem abertos em ambos os casos. Isso é particularmente verdade no caso de equipes trabalhando com XP. Normalmente, quanto mais cedo descobrimos um problema, menos prejuízos ele pode causar e maiores são as chances de resolvê-lo de forma barata. Por isso, projetos XP estabelecem formas de encurtar ao máximo a defasagem de tempo entre o momento em que uma ação é executada e o seu resultado é observado. Assim, por exemplo, desenvolvedores procuram entregar novas funcionalidades no menor prazo possível, para que o cliente compreenda rapidamente as conseqüências daquilo que pediu. Os clientes, por sua vez, procuram se manter presencialmente próximos dos desenvolvedores para prover informações precisas sobre qualquer dúvida que surja ao longo do desenvolvimento.

Comunicação
Para que os desenvolvedores compreendam o que o cliente deseja e este último entenda os desafios técnicos que precisam ser vencidos, é preciso que haja comunicação entre as partes. Diálogos são mais eficazes que videoconferências, que são melhores que telefonemas, que são mais expressivos que emails e assim sucessivamente. Conscientes disso, aqueles que trabalham com XP priorizam o uso do diálogo presencial, com o objetivo de garantir que todas as partes envolvidas em um projeto tenham a chance de se compreenderem da melhor maneira possível.

Simplicidade
O XP utiliza o conceito de simplicidade em inúmeros aspectos do projeto para assegurar que a equipe se concentre em fazer, primeiro, apenas aquilo que é claramente necessário e evite fazer o que poderia vir a ser necessário, mas ainda não se provou essencial.

Coragem
Equipes XP acreditam que errar é natural e quebrar o que vinha funcionando acontece cedo ou tarde. É necessário ter coragem para lidar com esse risco, o que em XP se traduz em confiança nos seus mecanismos de proteção. As práticas do XP são voltadas, entre outras coisas, para proteger o software de inúmeras formas. Equipes XP confiam na eficácia destas práticas e destes mecanismos de proteção e isso é o que as tornam receptivas a mudanças. Assim, ao invés de frear a criatividade do cliente e evitar mudanças, equipes XP as consideram inevitáveis e procuram se adaptar a elas com segurança e com coragem, isto é, com confiança em seus mecanismos de proteção.

Conclusão
Trabalhar com Extreme Programming equivale a encarar o desenvolvimento de software de uma forma diferente daquela a que estamos habituados. Trata-se de uma forma mais humana, onde todos - clientes, desenvolvedores e demais interessados no projeto - são identificados como pessoas que falham e que acertam. A estrutura de desenvolvimento criada pelo XP procura ajudar o projeto a explorar o que as pessoas têm de melhor e solucionar suas falhas com rapidez e segurança.
XP procura agir continuamente com priorização para evitar que trabalhos desnecessários sejam executados. Isso ajuda a poupar tempo, recursos e permite gerar maior valor para os clientes. Extreme Programming é a arte de maximizar o trabalho que não será feito. Pois, mais importante que trabalhar muito e produzir muito, é produzir a coisa certa, aquilo que o cliente realmente identifica como sendo valioso para resolver seus problemas, fazendo isso de forma consistente, segura e rápida ao longo de todo o andamento do projeto.

Link: http://www.nce.ufrj.br/conceito/artigos/2006/015p1-3.htm

Aulas 31 e 32

Padrão Invenção Pura

Problema:

A quem atribuir responsabilidades quando qua do as classes do domínio não são adequadas e não se quer violar os princípios da Coesão Alta e do Acoplamento Fraco ? Como criar componentes de software conectáveis ?

Solução:
Atribuir um conjunto de responsabilidades altamente coeso a uma classe artificial – que não representa nada no domínio do problema. Tal classe é construída especialmente para melhorar a coesão e diminuir o acoplamento, facilitando reutilização (uma invenção da imaginação).

Exemplo: Se for necessário salvar instâncias de Venda em um banco de dados relacional, considerando o padrão Expert, esta responsabilidade pode ser atribuída à própria classe Venda.
Porém há as seguintes implicações:
-Grande número de operações voltadas ao banco de dados- diminuição da coesão-
A classe Venda tem que ser acoplada com a interface do banco de dados relacional aumento do acoplamento–
Salvar objetos é uma tarefa geral, necessária em muitas classes – duplicação de código, baixa reutilização.
-Nesse caso, a solução é criar uma nova classe que é unicamente responsável por salvar objetos em algum tipo de meio de armazenamento persistente, como um banco de dados relacional.
-Chamamos esta solução de PersistentStorageBroker.
Esta classe é uma Invenção Pura.

Padrão Indireção
Problema: Quem irá evitar o acoplamento direto? Como desacoplar objetos de maneiraa apoiar o Acoplamento Fraco e manter o alto potencial de reutilização?

Solução: Atribuir a responsabilidade a um objeto intermediário que faz a mediaçãoentre outros componentes ou serviços, de modo que eles não estejam diretamente acoplados.

Exemplo:
O exemplo de uma Invenção Pura de desacoplar Venda dos serviços de banco de dados relacionais, também é um exemplo de Indireção. O PersistentStorageBroker atua como um intermediário entre Venda e o banco de dados.

Link: http://www.inf.ufg.br/~juliano/ensino/especializacao/ProjSw2007/ProjetoOO.pdf

Aulas 29 e 30

Padrão Polimorfismo

Problema:

Como tratar alternativas com base no tipo ? Como criar componentes de software conectáveis ?

Solução:

Atribuir responsabilidade pelo comportamento, aos tipos para os quais o comportamento varia, usando operações polimórficas.

Corolário:

não teste o tipo de um objeto nem use condições lógicas no código para executar alternativas que variam com base no tipo.O Polimorfismo significa "existindo em muitas formas". Ele permite que referências de tipos de classes mais abstratas representem o comportamento das classes concretas que referenciam. Assim, um mesmo método pode apresentar várias formas, de acordo com seu contexto.

O objetivo principal do polimorfismo é:

- Evitar a condição IF e ELSE;

- Usar polimorfismo melhorar a conectividade dos componentes.

Aulas 27 e 28

Exercícios:

1º) Um objeto "A" precisa executar um método quando o estado do objeto "B" for alterada. Qual o padrão GOF deve ser usado? Qual o papel do objeto "B" e do objeto "A" nesse padrão?


2º) Qual o padrão GOF deve ser usado quando necessitamos executar diversas ações de forma atômica

3º) Uma classe de conexão só pode ter, no máximo, 10 instâncias. Qual o padrão GOF a usar?

4º) Duas classes "B" e "B" tem iterfaces distintas. Qual o padrão deve ser usado se a classe "B" precisar um método da classe "A" ?

5º) Voçê deseja que uma classe de terceiros use um método de sua classe. Qual o melhor padrão?

Aula 25 e 26

MVC

Model-view-controller (MVC) é um padrão de arquitetura de software. Com o aumento da complexidade das aplicações desenvolvidas torna-se fundamental a separação entre os dados (Model) e o layout (View). Desta forma, alterações feitas no layout não afectam a manipulação de dados, e estes poderão ser reorganizados sem alterar o layout.
O model-view-controller resolve este problema através da separação das tarefas de acesso aos dados e lógica de negócio, lógica de apresentação e de interacção com o utilizador, introduzindo um componente entre os dois: o Controller. MVC é usado em padrões de projeto de software, mas MVC abrange mais da arquitetura de uma aplicação do que é típico para um padrão de projeto.


Model

A representação "domínio" específica da informação em que a aplicação opera. Por exemplo, aluno, professor e turma fazem parte do domínio de um sistema acadêmico. É comum haver confusão pensando que Model é um outro nome para a camada de domínio. Lógica de domínio adiciona sentido à dados crus (por exemplo, calcular se hoje é aniversário do usuário, ou calcular o total de impostos e fretes sobre um determinado carrinho de compras).
Muitas aplicações usam um mecanismo de armazenamento persistente (como banco de dados) para armazenar dados. MVC não cita especificamente a camada para acesso aos dados, porque subentende-se que estes métodos estariam encapsulados pelo Model.

View
"Renderiza" o model em uma forma específica para a interação, geralmente uma interface de usuário.

Controller
Processa e responde a eventos, geralmente ações do usuário, e pode invocar alterações no Model.

Link: http://pt.wikipedia.org/wiki/MVC

AULA 23 e 24

PADRÃO COMMAND


Propósito:
Encapsular uma requisição como um objeto, permitindo que os clientes parametrizem diferentes requisições, filas ou fazer o registro de log de requisições e dar suporte operações que podem ser desfeitas.


Também conhecido como:
Action ou Transaction
Motivação:
As vezes precisamos executar uma operação sem se preocupar com qual objeto que vai realiza-la
ou simplesmente não conhecemos qual objeto vai receber a delegação para executar tal operação.
Em uma aplicação Client/Servidor geralmente temos o componente Menu que é composto de
vários itens. Cada item do menu eqüivale uma operação, como salvar um arquivo, ler arquivo,
apagar arquivo, selecionar a paleta de cores e etc..


Aplicação:
Use o padrão Command quando você precisa:
- Parametrizar objetos por uma ação a ser executada
- Especificar, enfileirar e executar solicitações em tempos diferentes. Um objeto Command
poder ter o ciclo de vida independente da requisição do cliente.
- Suporte para desfazer operações. A operação "execute" do Command, pode armazenar
estados para reverter seus efeitos no próprio comando. Basta acrescentar na interface
Command uma operação chamada "Unexecute", que terá a responsabilidade de desfazer a
operação realizada pelo "execute". Os comandos realizados podem ser armazenados em lista
histórica.
- Estruturar um sistema em torno de operações de alto nível, como transações por
exemplo. Uma transação encapsula um conjunto de mudanças nos dados. O padrão
Command provê uma maneira de modelar transações. O Command tem uma interface comum, assim podemos chamar todas as transações do mesmo jeito.
- Reduzir acoplamento entre as requisições dos clientes e o objetos que as executam.


Solução:
Implemente o padrão Command para encapsular as operações e reduzir o acoplamento entre as requisições e os objetos que as executam. Para facilitar implantação de novas operações e tornar mais simples a manutenção das operações.


Conseqüências:
O padrão Command tem as seguintes conseqüências:
- Comand reduz o acoplamento (dependência) entre o objeto que chama a operação e o objeto
que executa a operação.
- Command é objeto que pode ser estendido e manipulado por outros objetos
- É mais fácil de acrescentar novas operações ou novos comandos, pois você não tem que
mudar as classes existentes.

Aulas 21 e 22

PADRÃO OBSERVER

O padrão Observer, é utilizado para quando você precisa encapsular objetos que você não conhece, dentro de um outro e notificá-los após uma determinada ação.

Pré-Requisitos
Entendimento de orientação à objetos;
Capacidade de abstração;

Situações
Você precisa de um log de ações no seu sistema administrativo;
Você precisa saber quando alguém executou os comandos do seu WebService;
Quando um visitante do seu site fizer cadastro, deve inicializar todas as tabelas relacionadas;


Motivações
Tradicionalmente, aconselha-se o uso de padrões de projeto, pois são uma maneira unificada de falar de um determinado algoritmo;
Segundo estudos, é um padrão com nível máximo de uso;
O .NET Framework utiliza em seus componentes;
Encapsulamento e entendimento simples e fácil;
Utilização correta da orientação à objetos;


O Padrão Observer representa uma dependência de um para muitos entre objetos para que quando um objeto mude de estado, todos os seus objetos dependentes sejam alterados automaticamente.

LINK: http://infotecfatos.blogspot.com/2008/01/padres-de-projetos.html

Aula 20

PADRÃO SINGLENTON

O Singleton é um dos padrões de projeto mais simples existentes. É um padrão de projeto de software (do inglês Design Pattern). Este padrão garante a existência de apenas uma instância de uma classe, mantendo um ponto global de acesso ao seu objeto.Nota linguística: O termo vem do significado em inglês quando se resta apenas uma carta nas mãos, num jogo de baralho.

O GoF nos diz que para uma classe ser um singleton, deve-se garantir que haverá apenas uma instância na aplicação e que deve-se fornecer um ponto de acesso à mesma. Mas como garantir que haverá apenas uma instância? É de conhecimento comum que, para criar uma instância de uma classe, devemos chamar o seu construtor. Assim, para resolvermos o problema, devemos restringir o acesso ao construtor, tornando-o um método privado. Em seguida, deve-se utilizar um método público que faça o controle da instanciação, de modo que ela só possa ser feita uma vez.

Conclusões:

Além de ser um dos padrões mais simples, o singleton é também um dos mais criticados e mal usados. Uma situação em que realmente é necessário que exista apenas uma instância de uma classe é difícil e o seu uso pode levar a muitos problemas. O uso abusivo de singletons leva a soluções onde a dependência entre objetos é muito forte e a testabilidade é fraca.
Adicionalmente, os singletons são difíceis de escalar, pois é difícil garantir uma única instância de um singleton em um cluster, onde existem várias JVMs. Um outro problema é que os singletons dificultam o hot redeploy por permanecerem em cache, bloqueando mudanças de configuração. Por esses e outros problemas, deve-se ter cuidado com o uso abusivo de singletons.

Aula 19

PADRÃO ADAPTER

Adapter, também conhecido como Wrapper, é um padrão de projeto de software ou de desenho (do inglês design pattern). Este padrão é utilizado para 'adaptar' a interface de uma classe. O Adapter permite que classes com interfaces incompatíveis possam interagir.
Adapter permite que um objeto cliente utilize serviços de outros objetos com interfaces diferentes por meio de uma interface única.

Em idéia geral o padrão adapter fornece uma interface conforme o cliente deseja, usando serviços de uma classe com uma interface diferente.Por exemplo: Precisamos implementar uma interface, descobrimos que uma classe já existente executa os serviços que o cliente deseja, porém, com os nomes dos métodos diferentes do desejado. Podemos utilizar essa classe para atender às necessidades dele, usando o padrão Adapter.

Ex:

Aula 18 - Início do 2º Bimestre - GOF

Os padrões "GoF" são organizados em famílias de padrões: de criação, estruturais e comportamentais. Os padrões de criação são relacionados à criação de objetos, os estruturais tratam das associações entre classes e objetos e os comportamentais das interações e divisões de responsabilidades entre as classes ou objetos.
Um padrão "GoF" também é classificado segundo o seu escopo; de classe ou de objeto. Nos padrões com escopo de classe os relacionamentos que definem este padrão são definidos através de herança e em tempo de compilação. Nos padrões com escopo de objeto o padrão é encontrado no relacionamento entre os objetos definidos em tempo de execução.

Os padrões de projeto de software ou padrões de desenho de software, também muito conhecido pelo termo original em inglês: Design Patterns, descrevem soluções para problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos.
Um padrão de projeto estabelece um nome e define o problema, a solução, quando aplicar esta solução e suas conseqüências.
Os padrões de projeto visam facilitar a reutilização de soluções de desenho - isto é, soluções na fase de projeto do software, sem considerar reutilização de código. Também acarretam um vocabulário comum de desenho, facilitando comunicação, documentação e aprendizado dos sistemas de software.

LINK: http://pt.wikipedia.org/wiki/Padr%C3%B5es_de_projeto_de_software#Padr.C3.B5es_GoF

aulas 14 e 15 (padrão alta coesão)

Este padrão é altamente relacionado ao padrão baixo acoplamento, ao se aplicar um, geralmente aplica-se o outro como resultado. Em termos de projeto, a coesão mede o quanto as responsabilidades de um elemento são fortemente relacionadas, um elemento com responsabilidades altamente relacionadas e que não executa um grande volume de trabalho, tem coesão alta, já os elementos que executam múltiplas funções, ou que executa diversas tarefas além de não ter nenhum relacionamento, possuem baixa coesão.

As classes com baixa coesão são:

· Difíceis de compreender pois não existe relação entre elas, ou muito pouca;

· Difíceis de reutilizar pois estão fortemente acopladas ou possuem granularidade alta;

· Difíceis de manter pois manutenção em uma classe mal relacionada e muito acoplada é praticamente impossível;

· Delicadas, além de serem constantemente afetadas por mudanças.

O principal defeito em um sistema com baixa coesão é ter classes com responsabilidades que deveriam ter sido delegadas a outros objetos.

aula 12 e 13 (acoplamento de controle, dados globais, dados internos)

Acoplamento de controle:

Basicamente quando há passagem de flags de controle entre objetos de forma que um objeto controle as ações do outro objeto, ou melhor:

• Objeto a manda uma mensagem para objeto b
• b usa um parâmetro da mensagem para decidir o que fazer

A solução para este tipo de acoplamento é decompor as operações das classes em múltiplas operações.

Acoplamento de dados globais:

• Dois ou mais objetos compartilham estruturas de dados globais
• É um acoplamento muito ruim pois está escondido
• Uma chamada de método pode mudar um valor global e o código não deixa isso aparente
• Um tipo de acoplamento muito ruim

Acoplamento de dados internos:

• Um objeto altera os dados locais de um outro objeto
• Ocorrência comum:
• Friends em C++
• Dados públicos, package visibility ou mesmo protected em java
• Use com cuidado!

aulas 10 e 11 (acoplamento de dados)

Dentro do padrão baixo acoplamento há algumas divisões quanto aos tipos:

• Acoplamento de dados
• Acoplamento de controle
• Acoplamento de dados globais
• Acoplamento de dados internos

O acoplamento de dados ocorre quando a saída de um objeto é a entrada de outro ou quando há uso de parâmetros para passar itens entre métodos.

Exemplificando:

Há grande acoplamento entre as classes Aluno e ListaOrdenada, de acordo o princípio do padrão baixo acoplamento, a classe ListaOrdenada está fazendo uma comparação, mas dentro de um grande sistema ela teria que fazer comparação de qualquer elemento, e não apenas de uma matrícula, como é esse caso.

aula 8 e 9 (padrão baixo acoplamento)

O objetivo geral deste padrão é atribuir responsabilidade de maneira que o acoplamento permaneça fraco.

Acoplamento quer dizer junto, agregado, ou seja, na linguagem de análise e projeto, é o quanto uma classe está ligada a outra, ou seja, quanto uma classe depende de outra, tem conhecimento ou depende dos elementos desta classe.

Um sistema com baixo acoplamento tem independência, com isso, reduz o impacto nas mudanças que poderão vir a ocorrer.

Os principais benefícios do baixo acoplamento são:

· Não é afetado por mudanças

· È simples de entender isoladamente

· È conveniente para reutilização

aula 6 e 7 (padrão criador)

Um objeto é uma instância de uma classe, portanto em uma conjunto de classes, ou seja, um sistema, haverá diversos objetos. Um objeto é criado a partir de uma chamada de procedimento conhecidas como mensagens que uma classe envia a outra, pois bem, o ponto onde queremos chegar é este. Qual classe é responsável por passar uma mensagem a outra para que seja criada uma instância da mesma? Sabemos que em um projeto é útil ter um princípio geral para atribuições de responsabilidades de criação. Sendo essas responsabilidades bem atribuídas, o projeto apresentará acoplamento fraco, mais clareza, encapsulamento fraco e reutilização.

O objetivo básico do padrão criador é encontrar um criador que necessite ser conectado ao objeto criado em qualquer evento. Escolhê-lo como criador garante um acoplamento fraco.

Segundo o padrão criador, uma classe é responsável por criar instâncias de outra se uma das seguintes condições se aplicar:

a. B agrega objetos da classe A.

b. B contém objetos da classe A.

c. B registra instâncias da classe A.

d. B usa muitos objetos da classe A.

e. B possui os dados usados para inicializar A.

Aula 5

O projeto GRASP tem como objetivo principal definir padrões.Padrões são documentos da boa praticas catalogos com problemas e soluções.Estudaremos 5 padrões GRASP:

Padrões GRASP:

Especialista na informação
Criador
Coesão alta
Acoplamento fraco
Controlador

RESPONSABILIDADE são atribuida pela UML obrigando e definindo os objetos as suas responsabilidades que são elas OBRIGAÇÃO DE FAZER e OBRIGAÇÃO DE CONHECER.

OBRIGAÇÃO DE CONHECER:

Todo objeto ou software se comunicam e enviam mensagens entre si ,pois eles devem se conhecer, tanto o que é publico ou privado.

OBRIGAÇÃO DE FAZER:

Se um objeto precisa de uma informação que esta em outro objeto este pode iniciar uma ação no objeto e ter de retorno a informação necessaria que ele precisa bem como controlar e coordenar atividades em outros objetos.

Especialista na informação
Atribui responsabilidade a quem compete resolver , perguntando a quem sabe e indicando a classe que tem a competencia necessaria para retornar a informação.

AULA 4 "Padrões"

Os padrões de projeto de software ou padrões de desenho de software, também muito conhecido pelo termo original em inglês: Design Patterns, descrevem soluções para problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos. Um padrão de projeto estabelece um nome e define o problema, a solução, quando aplicar esta solução e suas conseqüências.
Os padrões de projeto visam facilitar a reutilização de soluções de desenho - isto é, soluções na fase de projeto do software, sem considerar reutilização de código. Também acarretam um vocabulário comum de desenho, facilitando comunicação, documentação e aprendizado dos sistemas de software.
Padrões GRASP
• GRASP = General Responsability Assignment Software Patterns.
• Descrevem princípios fundamentais de atribuição de responsabilidade a objetos.
Os padrões GRASP fornecem uma abordagem sistemática para a atribuição de responsabilidades às classes do projeto.

AULA 3 "Diagramas"

Diagrama de sequência (ou Diagrama de Sequência de Mensagens) é um diagrama usado em UML (Unified Modeling Language), representando a seqüência de processos (mais especificamente, de mensagens passadas entre objetos) num programa de computador. Como um projeto pode ter uma grande quantidade de métodos em classes diferentes, pode ser difícil determinar a seqüência global do comportamento. O diagrama de seqüência representa essa informação de uma forma simples e lógica. o Diagrama de Seqüência é uma das ferramentas UML usadas para representar interações entre objetos de um cenário, realizadas através de operações ou métodos (procedimentos ou funções).
Um Diagrama de colaboração é definido pelo UML (Unified Modeling Language). O Diagrama de Colaboração exibe uma interação, consistindo de um conjunto de objetos e seus relacionamentos, incluindo as mensagens que podem ser trocadas entre eles. O diagrama de sequência e colaboração são isomórficos.
O diagrama mostra de maneira semelhante ao diagrama de seqüência, a colaboração dinâmica entre os objetos. Se a ênfase do diagrama for o decorrer do tempo, é melhor escolher o diagrama de seqüência, mas se a ênfase for o contexto do sistema, é melhor dar prioridade ao diagrama de colaboração.

AULA 1 e 2

A orientação a objetos, também conhecida como Programação Orientada a Objetos (POO) ou ainda em inglês Object-Oriented Programming (OOP) é 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 de 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.
Na programação orientada a objetos, implementa-se um conjunto de classes que definem os objetos presentes no sistema de software.
• Classe representa um conjunto de objetos com características afins. Uma classe define o comportamento dos objetos, através de métodos, e quais estados ele é capaz de manter, através de atributos. Exemplo de classe: Os seres humanos.
• Objeto é uma instância de uma classe. Um objeto é capaz de armazenar estados através de seus atributos e reagir a mensagens enviadas a ele, assim como se relacionar e enviar mensagens a outros objetos. Exemplo de objetos da classe Humanos: João, José, Maria.
• Atributos são características de um objeto. Basicamente a estrutura de dados que vai representar a classe. Exemplos: Funcionário: nome, endereço,telefone, CPF, ....; Carro: nome, marca, ano, cor, ...; Livro: autor, editora, ano. Por sua vez, os atributos possuem valores. Por exemplo, o atributo cor pode conter o valor azul.
• Métodos definem as habilidades dos objetos. Bidu é uma instância da classe Cachorro, portanto tem habilidade para latir, implementada através do método deUmLatido(). Um método em uma classe é apenas uma definição. A ação só ocorre quando o método é invocado através do objeto, no caso Bidu. Dentro do programa, a utilização de um método deve afetar apenas um objeto em particular; Todos os cachorros podem latir, mas você quer que apenas Bidu dê o latido. Normalmente, uma classe possui diversos métodos, que no caso da classe Cachorro poderiam ser sente(), coma() e morda(). • Mensagem é uma chamada a um objeto para invocar um de seus métodos, ativando um comportamento descrito por sua classe. Também pode ser direcionada diretamente a uma classe (através de uma invocação a um método estático).