Paradigma Orientado a Objetos

Programação Java
#1

Estava estudando Programação orientado a objeto mais claramente engenharia de softwares orientado a objetos e cheguei a algumas duvidas.
Tudos os livros que li fala das vantagens (principalmente reuso) mas nao consegui observar alguns pontos! Se alguem puder responder agradeço desde ja!

:arrow: Todos sabem que a engenharia de softwares orientado a obejtos tem suas grandes vantagens, principalmente reuso, mas quais são suas falhas,Desvantagens??
:arrow: Um obejto composto se implementa atraves de Polimorfismo (ou sobrecarga de metodos)?
:arrow: Alguem poderia passar algum link que contem sintaxe para troca de mensagens entre objetos!!
ex: Mensagem [ObjetoReceptor,OperaçãoIncluirVenda, {Produto, Valor}];
Mensagem [OBjetoEmissor, {Venda Incluida}];
:arrow: Tem uma parte da O.O. que fala em reestruturação de hierarquia de classes, que diferença tem em usar isso?? (overriding, acho que é assim que escreve)
:arrow: Qual outras linguagens alem de Java Utiliza O.O.?

Nossa quanta duvida devo ser nebam mesmo :(.

:oops: Beijunda e desde Já Agradeço!

#2

Smaltalk, C++, …

#3

Cara, acho que vc esta desesperadamente precisando aprender Smalltalk :wink:

Editado:

Alias, esqueca Smalltalk. Tente dar uma olhada no Python assim que tiver um tempinho, e (item obrigatorio) veja a Io:

:arrow: http://www.iolanguage.com

#4

Bom dar minhas opiniões sobre o assunto.

A falha que eu acredito que seja a maior, é quando os princípios da OOP não são utilizadas corretamente, assim invés de facilitar, organizar e reutilizar códigos, você acaba escrevendo códigos repetidos, várias classes, monte de sujeira que fica uma loucura pra dar manutenção (eu já programei assim, quem nunca fez essas coisas? :wink: ).
A OOP não é 100% perfeita para todos os casos, existem algumas funcionalidades que a OOP não cobre ou seja muito dificil de implementar usando apenas ela, e nesse ponto que entra a AOP (Programação orientada a Aspecto), um exemplo clássico é a geração de logs.

A troca de mensagens são feitas através dos métodos que estão na interface do objeto, ou seja, aqueles que podem ser acessíveis pelos outros objetos. Um exemplo seria um Bean em java, onde seus atributos são privates e os métodos getters e setters são públicos. As trocas de mensagens são feitas através desses métodos públicos.

Sobre o objeto composto eu não entendi muito bem sua pergunta, mas eu entendo objeto composto por métodos de outros objetos, e assim a herança de classes entra em ação.

O Daniel já deu exemplos de outras linguagens que utilizam OO, agora uma outra (não me atirem pedras), é o C# da plataforma .NET

#5

[quote=“cv”]Cara, acho que vc esta desesperadamente precisando aprender Smalltalk :wink:

Editado:

Alias, esqueca Smalltalk. Tente dar uma olhada no Python assim que tiver um tempinho, e (item obrigatorio) veja a Io:

:arrow: http://www.iolanguage.com[/quote]

Caramba cv, de onde tu tira essas linguagens??? :lol:

#6

Gostei da respsota do Manchester :slight_smile:

Hoje temos compiladores muito bons, ams não perfeitos. Geralmente OO aidna é mais lento, mas assim como como procedural é mais lento que Assembly, que é mais lento que linguagem de máquina, assim como JVM é mais lento que VM do SO, essas coisas… nada que valha a pena se preocupar num abiente moderno.

Um objeto composto é formado de outros objetos. Considere um…ahhmm… Computador. O objeto compotador tem um objeto CPU, objeto MemoriaPrincipal, etc. Tudo faz aprte do objeto Computador, ok?

Acho qeu já responderam, não é?

Com sobrescrita de método, você pode alterar como os métodos herdados são executados. Se sua superclasse tinha uma implementação de um método que não te servia, você escreve seu próprio e coloca no lugar deste.

Respondida também, não?

Uma dica: comece com programação OO, não com análise, design ou a própria ‘engenharia de software’ em si. É estranho dizer a um futuro engenheiro que sua primeira aula é levantar um muro, mas assim você pega melhor os conceitos…

[]s

#7

Aew galera, Brigado pelas dicas, analisei todas as respostas e chequei em alguns livros. Esta claro as ideias agora.

Brigado

#8

Eu ia criar um tópico novo para expor a minha questão, mas, depois de fazer uma pequena busca no fórum, achei melhor “[color=red]ressuscitar[/color]” este tópico aqui.

Minha questão é sobre “Paradigma OO versus linguagens script”. Uma dificuldade que venho enfrentando com linguagens script orientadas a objetos (na verdade, só com Python, embora haja dificuldades similares em Ruby e Smalltalk, pelo que eu tenho lido), tem a ver com as regras de visibilidade de métodos e atributos (public, protected, private).

Aparentemente, nessas linguagens script, as regras de visibilidade ou parecem não existir, ou são implementadas de maneira limitada. Por exemplo, em Python, um atributo cujo nome começa com dois _'s comporta-se, de maneira limitada, como um atributo privado (na prática, classe.__atributo é convertido para classe._classe__atributo, de modo que ele pode ser acessado — e modificado — diretamente por este último nome).

Inclusive, pelo que eu tenho observado, alguns programadores destas linguagens manifestam verdadeiro repúdio às regras de visibilidade, dizendo que são “frescura de programador C++ e/ou Java”. Mas, se não estou errado, regras de visibilidade estão previstas no próprio paradigma OO, não sendo particularidades de C++ ou Java.

Eu até aceitaria a justificativa de que o fato dessas linguagens serem dinamicamente tipadas dificultaria a implementação de regras de visibilidade.

Gostaria de saber a opinião de vocês. Seria realmente complicado implementar regras de visibilidade em linguagens script? Ou será que isso realmente não seria interessante para tais linguagens, como defendem alguns dos seus “programadores afetos”?

Também gostaria de um esclarecimento: regras de visibilidade estão previstas no paradigma OO?

#9

As regras de visibilidade de Ruby sao praticamente iguais as do Java (a diferenca eh que nao tem “default”, mas tem public, protected e private, e eles funcionam mais ou menos do mesmo jeito que em Java).

Se voce me perguntar se uma linguagem OO precisa de regras de visibilidade, a resposta eh nao… mas que ajuda, ajuda :slight_smile:

O intuito todo eh forcar o encapsulamento, mas se a equipe nao vai fazer besteira, restricao de acesso eh claramente opcional - e essa eh a ideia do pessoal do Python e Smalltalk.

#10

complementando: comof alei aqui algumnas vezes, regras de visibilidade são para poupar quem escreve a classe cliente de detalhes inúteis a ele, não são nem sequer para segurança :wink:

#11