Legado de paradigmas anteriores

Linguagens pr�-POO (em especial as que comportavam a programa��o estruturada)

forneceram o seguinte legado � POO:

Vari�veis portam informa��o formatada dentre um n�mero pequeno de TDs

embutidos/padr�o/default e estruturas de dados derivados destes TDs b�sicos.
Procedimentos/m�todos/fun��es/rotinas, que podem receber uma entrada, retornar
uma sa�da, e manipular dados.
Uso das estruturas de controle.
Modularidade: procedimentos agrupados em arquivos e m�dulos, com espa�os
distintos de nomes para que os identificadores n�o colidam (i.e., uso de
namespaces).

Novas caracter�sticas

Os atributos e m�todos podem ser referentes a uma classe (e todas as suas

inst�ncias) ou a uma �nica inst�ncia. O v�nculo dos atributos aos m�todos, de forma
a manter uma interface bem definida para opera��o sobre os dados, e a evitar
corrup��o dos dados, � chamado de encapsulamento. O encapsulamento foi respons�vel
pelo conceito de 'ocultamento de dados', central para a POO. O encapsulamento pode
ser realizado atrav�s de conven��es (em Python, underscores demarcam m�todos e
atributos protegidos e privados), ou via recursos da linguagem (em Java ou C++, um
m�todo privado s� � acessado pela pr�pria classe). Encapsulamento incentiva o
desacoplamento.

Quando um objeto cont�m outros objetos, diz-se que h� composi��o de objetos. A

composi��o de objetos � usada para representar uma rela��o 'tem um', usualmente uma
meron�mia. J� a heran�a (quase sempre suportada pelas linguagens que utilizam
classes) apresenta rela��es '� um' (i.e. '� um tipo de'), ou seja, rela��es de
hiperon�mia cujo resultado final � a �rvore taxon�mica. Na heran�a, tipicamente
todos os atributos e m�todos da classe pai/m�e est�o tamb�m dispon�veis na classe
filha, embora seja comum que algumas caracter�sticas sejam substitu�das. Assim, a
heran�a permite reuso facilitado de caracter�sticas e muitas vezes reflete rela��es
do mundo real de forma intuitiva. Ambas a 'composi��o de objetos' e a 'heran�a'
constituem hierarquias entre as classes e objetos na POO.

Heran�a m�ltipla ocorre quando uma classe � filha de mais de uma classe. Mixin pode
ser considerado um tipo especifico de heran�a, embora haja uma diferen�a crucial: a
classe da qual s�o herdadas as caracter�sticas n�o � considerada pai/m�e.

Polimorfismo � quando alguma rotina pode ser chamada para objetos diferentes. Por
exemplo, assuma que a fun��o retornaCorPrincipal() possa ser chamada tanto em um
objeto da classe Imagem quanto da classe Video. O polimorfismo � um tipo de
abstra��o que simplifica c�digos externos � hierarquia de classes e uma separa��o
forte das responsabilidades (separation of concerns).

H� orienta��es diversas para a POO, muitas de reconhecida complexidade. Por

exemplo, o princ�pio da composi��o sobre heran�a advoca que a composi��o de objetos
� preferida � heran�a. O princ�pio aberto/fechado advoca que classes e fun��es deve
ser 'abertas p extens�o mas fechadas para modifica��o'.

Subtipos comportamentais fortes (ou princ�pio de substitui��o de Liskov, LSP do

ingl�s Liskov substitution principle) s�o filhos que mant�m todas as
caracter�sticas dos pais. Dito de outra forma, seja 's' tal que todas as
propriedades dos objetos t da classe T est�o tamb�m presentes no objeto s da classe
S, em que S � subtipo de T. Tal 's' � chamado de subtipo comportamental forte,
subtipo forte, subtipo de Liskov, e varia��es semelhantes.
Cr�ticas � POO
As cr�ticas mais recorrentes � POO podem ser resumidas em: 1) n�o satisfazer os
objetivos de reusabilidade e modularidade, e 2) a �nfase demasiada em design e
modelamento de software em detrimento de outros aspectos
(computabilidade/algoritmos).

N�o h� consenso de que a POO realmente seja �til para modelar a realidade, tampouco
se modelar a realidade � um objetivo pertinente. A premissa de que 'a POO �
apropriada para modelar sistemas complexos com comportamentos complexos', contrasta
com o renomado princ�pio KISS. Linguagens naturais n�o compartilham da estrat�gia
usual na POO: 'priorizar coisas ao inv�s de a��es', o que leva muitas vezes a
representa��es contorcidas.[4] A POO muitas vezes � realizada sem uma representa��o
transparente do fluxo de controle (ordem das instru��es), o que tem se tornado uma
desvantagem com a relev�ncia, acentuada nos �ltimos anos, do processamento
paralelo. Outras cr�ticas usuais incluem: a POO � 'intrinsecamente menos eficiente'
que o c�digo procedural, em geral demora mais para compilar, e tende a ser
extremamente complexa.

Veja tamb�m: PE vs POO.

Cr�ticas de programadores not�rios

Joe Armstrong: "O problema com linguagens orientadas a objetos � que voc� tem todo
esse ambiente impl�cito que elas levam consigo. Voc� queria uma banana mas o que
voc� conseguiu foi um gorila segurando a banana e uma selva inteira."[5]

Alexander Stepanov: "Dizer que tudo � um objeto � simplesmente dizer nada."

Steve Yegge: "Por que voc� percorreria tamanhas dist�ncias para coloca uma parte da
fala [substantivos] em um pedestal?"[6]

Eric Steven Raymond: "A POO encoraja programas com muitas camadas e destr�i a
transpar�ncia."[7]

Rob Pike: "A POO constitui os n�meros romanos da computa��o."[8]

Conceitos t�picos da POO
Cliente, servidor e mensagens

Da passagem de mensagens entre objetos: o cliente (um objeto) emite uma mensagem
para o servidor (outro objeto) em que solicita um servi�o (i.e. que uma rotina
qualquer seja executada) que pode implicar a emiss�o/retorno de uma resposta ao
cliente. Um servidor pode ser cliente de outros (sub-)servidores. Esta resposta
pode ser s�ncrona (quando o cliente aguarda a resposta do servidor para executar
qualquer outra instru��o) ou ass�ncrona (envolvendo paralelismo de atividades).

Um exemplo simples: um instituto (cliente), solicita um buffet para uma empresa

especializada (servidor). Esta empresa (agora cliente) solicita salgados e sucos de
outras empresas (sub-servidores). O instituto pode ficar paralisado enquanto n�o
chega o buffet (envio s�ncrono de mensagem) ou continuar suas atividades (envio
ass�ncrono de mensagem). Neste �ltimo caso, o instituto deve ser capaz de lidar com
a interrup��o das atividades (ou parte delas) assim que chegar o buffet.

A exist�ncia/espera de uma resposta pode ser inerente ao modelo de envio da

mensagem ou ser realizada atrav�s do disparo de uma nova mensagem pelo servidor.
Responsabilidades

A um servidor e seus m�todos s�o atribu�das responsabilidades espec�ficas. No

exemplo anterior, a empresa de buffet n�o deve entregar um brinquedo, e a comida
deve ser apropriada (n�o apenas v�rias barras de chocolate, por exemplo).
Uma responsabilidade que todos os servidores tem � a de manter seus dados
consistentes. Idealmente, n�o deve ser poss�vel tornar inconsistentes os dados de
um objeto. Um objeto tem a responsabilidade de manter uma boa interface para se
comunicar com outros objetos.

Outra responsabilidade gen�rica e usual � a de que as opera��es tenham um sentido

razo�vel. Por exemplo, se um cliente envia uma mensagem que satisfaz alguma pr�-
condi��o, � obriga��o do m�todo ativado retornar um resultado que reflita a p�s-
condi��o.
Modularidade centrada nos dados

A modularidade de um programa � uma medida que reflete o quanto ele � composto por
partes separadas (chamadas de m�dulos). Na POO, a modularidade � preferencialmente
(ou basicamente) centrada das TADs, o que pode ser chamado de modularidade centrada
nos dados e possui as seguintes caracter�sticas:

um m�dulo � constru�do encapsulando dados que representam um �nico conceito.

Alto grau de coes�o.
A visibilidade (dos atributos e m�todos) pode ser controlada.
O m�dulo pode ser utilizado com um tipo de dado.

Reuso

Enquanto na PE h� bibliotecas de rotinas (procedure libraries), na POO h�

bibliotecas de classes, que podem (at� certo ponto, em geral, etc) serem
compreendidas com conjuntos de TADs reutiliz�veis. Desafios para a reusabilidade:

Descobrimento: onde est� o componente e como acess�-lo?

Entendimento: o que o componente oferece e como encaixa em um programa?
Modifica��o: quando e como o componente deve ser modificado?
Integra��o: como organizar e usar o componente em conjunto com outros
componentes.

Nota: a modifica��o deve ser usada com cuidado. A modifica��o direta da rotina ou
objeto implica dificuldades quando alguma vers�o nova da biblioteca � utilizada.
Preferencialmente, as modifica��es devem ser feitas de forma modular, i.e.
separando as contribui��es locais das originais. Na POO, a heran�a ameniza este
problema. Veja tamb�m o aberto/fechado.
A��o nos objetos

As a��es devem sempre ser realizadas atrav�s de algum objeto.

'N�o pergunte o que um sistema faz, pergunte o que ele faz a que' (Meyer[2])

A��es em geral:
implementadas por chamadas de procedimentos.
com frequ�ncia, mas n�o sempre, parametrizadas (com par�metros de entrada).
A��es em objetos:
ativadas via mensagens.
uma mensagem sempre possui um objeto receptor
uma mensagem � similar a uma chamada de procedimento com ao menos um
par�metro
uma mensagem ativa uma opera��o (um m�todo).
o objeto receptor identifica a opera��o apropriada (busca/lookup de
m�todo)