É a força de projeto OO na semântica ou encapsulamento?

Question

O projeto orientado a objetos (OOD) combina dados e seus métodos. Este, tanto quanto eu posso ver, alcança duas grandes coisas: ele fornece encapsulamento (então eu não ligo para o que os dados não seja, apenas como eu obter valores que eu quero) e semântica (que relaciona os dados junto com os nomes, e sua métodos consistentemente utilizar os dados como inicialmente previsto).

Então, onde se encontra a força de OOD? Em constrast, atributos de programação funcional a riqueza para os verbos, em vez dos substantivos, e assim tanto encapsulamento e semântica são fornecidos pelos métodos, em vez das estruturas de dados.

Eu trabalho com um sistema que está na extremidade funcional do espectro, e continuamente por muito tempo para a semântica e encapsulamento de OO. Mas eu posso ver que o encapsulamento de OO pode ser uma barreira à extensão flexível de um objeto. Então, no momento, eu posso ver a semântica como uma força maior.

Ou é encapsulamento a chave para todo o código de valor?

Edit: eu quero dizer especificamente o tipo de OO encapsulamento fornece aqui. changeColor(door,blue) se torna door.changeColor(blue).

Answer 1

Você parece estar usando uma definição bastante estreita de “encapsulamento”. Será que eu estaria certo em presumir que você define encapsulamento a ser, “Combinando os dados com métodos?”

Se eu estiver errado, por favor ignore o resto deste post.

O encapsulamento não é um termo vago; na verdade, ele é definido pela Organização Internacional de Normalização. Modelo de Referência da ISO do Open Distributed Processing - define os seguintes cinco conceitos:

Entidade:. Qualquer concreto ou abstrato coisa de interesse

Objeto: Um modelo de uma entidade. Um objecto é caracterizado pelo seu comportamento e, duplamente, por seu estado.

Comportamento (de um objeto.): Uma coleção de ações com um conjunto de restrições sobre quando eles podem ocorrer

Interface:. Uma abstracção do comportamento de um objecto que consiste de um subconjunto das interacções de esse objecto, juntamente com um conjunto de restrições sobre quando pode ocorrer

encapsulamento:. A propriedade de que a informação contida em um objeto só é acessível através de interações nas interfaces suportadas pelo objeto

Nós podemos fazer ainda uma proposta auto-evidente: como algumas informações é acessível através dessas interfaces, algumas informações devem ser escondidos e inacessíveis dentro do objeto. As propriedades tais exposições de informação é chamado de ocultação de informações, que Parnas definido, argumentando que os módulos devem ser projetados para esconder ambas as decisões difíceis e decisões que são susceptíveis de alteração, consulte um dos grandes papéis de computação:

http://www.cs.umd.edu/ classe / spring2003 / cmsc838p / desenho / criteria.pdf

É importante notar que não é apenas os dados que estão escondidos-informação:. É algum subconjunto de comportamento associado com o objeto que é difícil ou susceptível de alteração

Em seu post, você parece estar dizendo que a diferença entre o encapsulamento em OO e na programação funcional decorre de gerenciamento de dados, mas pelo menos de acordo com a ISO e Parnas, gerenciamento de dados não é a chave para encapsulamento. Então, eu não vejo por encapsulamento em programação funcional precisa ser diferente daquela em OO.

Você menciona, além disso, em seu post que programação funcional fornece encapsulamento, “... pelos métodos em vez das estruturas de dados.” Isso, eu acho, é uma diferença de escala e não a da absoluta. Se eu usar a palavra, “Object,” em vez de “estrutura de dados” (mais uma vez, por favor, deixe-me saber se eu estou interpretando mal), então você parecem encontrar significado no encapsulamento de OO pelo objeto e encapsulamento de programação funcional pelo método.

No entanto, pela definição ISO acima, um objeto é qualquer coisa que eu quiser modelo. Assim, as classes podem ser encapsulados dentro de um pacote, desde que algumas dessas classes de contribuir para a interface do pacote (ou seja, as classes públicas do pacote) e alguns estão escondidos-informação (as classes privadas no pacote).

Da mesma forma, os métodos são encapsulados dentro de uma classe - alguns métodos sendo público e alguns privado. Você pode até mesmo levar este um entalhe inferior e dizer que as sequências de código McCabian seqüencial são encapsulados dentro de métodos. Cada forma de um gráfico de nodos encapsulados dentro de regiões encapsulados; e todos estes gráficos formar uma pilha gráfico. Assim programação funcional pode bem encapsulados no nível da função / arquivo, mas isso não é diferente do método gráfico / classe de OO, e essencialmente nenhuma diferença a partir do gráfico classe / pacote de OO ou.

Além disso, nota que a palavra Parnas usa acima: mudança. ocultação de informações diz respeito a potenciais eventos, tais como a mudança de decisões de design difícil no futuro. Você pergunta onde a mentira de força de OO; bem, o encapsulamento é certamente uma força de OO, mas a questão torna-se então, “Onde é que de encapsulamento força mentira?” ea resposta é um dos clareza retumbante: chagestão ESL. Particularmente, o encapsulamento reduz a carga máxima potencial de mudança.

O conceito de “acoplamento Potencial”, é útil aqui.

“Coupling”, em si é definido como: “Uma medida da força de associação estabelecido por uma conexão de um módulo para outro,” em outro dos grandes papéis de computação:

http://www.research.ibm.com/journal/ sj / 382 / stevens.pdf

E, como diz o jornal, em palavras nunca desde melhorado, “conexões Minimizando entre os módulos também minimiza os caminhos pelos quais mudanças e erros propagam em outras partes do sistema, eliminando assim desastroso‘ ondulação,’efeitos, onde as mudanças em um erros parte causa no outro, necessitando alterações adicionais em outros lugares, dando origem a novos erros, etc.”

Como definido aqui, no entanto, existem duas limitações que podem ser facilmente levantadas. Em primeiro lugar, o acoplamento não mede as ligações intra-módulo, e essas ligações intra-módulo pode dar origem a apenas como muitos, “Ripple”, efeitos como conexões entre os módulos (o papel não definir, “Coesão”, para relacionar intra-módulo elementos, mas isto não é definido em termos de conexões entre os elementos (ou seja, referências aos rótulos ou endereços) com a qual o acoplamento foi definido). Em segundo lugar, o acoplamento de qualquer programa de computador é um dado, em que os módulos estão ligados ou; há pouco espaço dentro da definição de acoplamento para gerenciar as mudanças potenciais das quais Parnas fala.

Ambos os problemas são resolvidos, até certo ponto, com o conceito de acoplamento potencial: o número máximo possível de conexões Formable entre todos os elementos de um programa. Em Java, por exemplo, uma classe que é um pacote-privadas (o acessor padrão) dentro de um pacote não pode ter conexões formadas sobre ele (ou seja, não fora das aulas pode depender dele, a reflexão não obstante), mas uma classe pública dentro de uma lata pacote têm dependências sobre ela. Esta classe pública contribuiria para o acoplamento potencial, mesmo se nenhum outras classes dependem dele no momento -. Aulas pode depender de que no futuro, quando as mudanças de design

Para ver a força de encapsulamento, considerar o princípio do ónus. O princípio do ónus assume duas formas.

A forma forte afirma que a carga de transformar um conjunto de entidades é uma função do número de entidades transformadas. Os forma fraca estados que a carga máxima potencial de transformar uma coleção de entidades é uma função do número máximo de entidades transformada.

A carga de criar ou modificar qualquer sistema de software é uma função do número de classes criadas ou modificadas (aqui se usa, “Classes”, presumindo um sistema OO, e estão em causa com encapsulamento ao nível da classe / pacote; nós poderia igualmente nos preocupamos com o nível de programação funcional função / arquivo). (Note que o “fardo”, é o desenvolvimento de software moderno é geralmente custo ou tempo, ou ambos.) As classes que dependem de uma classe particular, modificados têm uma maior probabilidade de serem afetadas do que as classes que não dependem da classe modificado.

O fardo potencial máximo uma classe modificada pode impor é a impactante de todas as classes que dependem dele.

Reduzir as dependências em uma classe modificada, portanto, reduz a probabilidade de que a sua actualização terá impacto sobre outras classes e assim reduz a carga potencial máximo que essa classe pode impor. (Isto é pouco mais que uma re-afirmação do “Estruturado design,” papel.)

A redução do número máximo potencial de dependências entre todas as classes em um sistema, por conseguinte, reduz a probabilidade de que um impacto de uma classe particular vai causar alterações de outras classes, e, assim, reduz a carga máxima potencial de todas as actualizações.

O encapsulamento, reduzindo o número máximo de Dependencies entre todas as classes, por conseguinte, reduz a forma fraca do princípio do ónus. Isso tudo é coberto pela “teoria Encapsulation”, que tentativas de matematicamente provar tais afirmações, usando acoplamento potencial como os meios lógicos de estruturação de um programa.

Note, no entanto, que quando você pergunta: “Será encapsulamento a chave para todo o código que vale a pena?” a resposta certamente deve ser: não. Não existe uma chave única para todo o código de valor. O encapsulamento é, em certas circunstâncias, apenas uma ferramenta para ajudar a melhorar a qualidade do código para que ele pode tornar-se, “vale a pena.”

Você também escreve que, “... o encapsulamento pode ser uma barreira à extensão flexível de um objeto.” Sim, certamente pode: é na verdade projetado para ser uma barreira contra a extensão das decisões de design de um objeto que são difíceis ou susceptíveis de mudança. Esta não é, no entanto, que se pensa ser uma coisa ruim. Uma abordagem alternativa seria ter todas as classes públicas e tem um programa de expressar o seu acoplamento máximo potencial; mas, em seguida, a forma fraca do princípio do ónus afirma que as atualizações serão cada vez mais caro; Estes são os custos contra os quais as barreiras à extensão estão a ser medido.

Finalmente, você fazer a comparação interessante entre o encapsulamento e semântica, e que, na sua opinião, a semântica de OO são a sua maior força. Eu não sou nenhum semanticista quer (eu não sabia nem uma palavra existia antes da boa Senhor Ramsey fez alusão a ele em seu comentário), mas eu presumo que você quer dizer “Semântica,” no sentido de “o significado, ou um interpretação do significado, de uma palavra “, e muito, basicamente, que uma classe com um, woof () método deve ser chamado de um cão.

Há grande força, de facto, esta semântica.

O que é curioso para mim é que você pit semântica contra encapsulamento e olhar para um vencedor; Eu duvido que você vai encontrar um.

Na minha opinião, existem duas forças que motivam encapsulamento:. Semântica ea lógica

encapsulamento Semantic significa apenas encapsulamento baseado no significado dos nós (para usar o termo geral) encapsulados. Então, se eu te disser que eu tenho dois pacotes, um chamado, 'animal', e um chamado 'mineral', e, em seguida, dar-lhe três classes Cão, Gato e Cabra e perguntar em quais pacotes essas classes devem ser encapsulado, então, dado nenhuma outra informação, você seria perfeitamente direito a alegação de que a semântica do sistema sugeriria que as três classes ser encapsulados dentro do 'animal,' pacote, ao invés do 'mineral.'

A outra motivação para encapsulamento, no entanto, é lógica, e em particular o estudo de acoplamento potencial, acima mencionado. teoria Encapsulation realmente fornece equações para o número de pacotes que devem ser usados ??para encapsular um número de classes a fim de minimizar o acoplamento potencial.

Para mim, o encapsulamento como um todo é o trade-off entre esta abordagem semântica e lógica: Eu vou permitir o acoplamento potencial dos meus programas para subir acima do mínimo, se isso faz com que o programa semanticamente mais fácil de entender; mas os níveis enormes e desperdício de acoplamento potencial será um aviso de que minhas necessidades de programa a ser estruturada-re não importa quão semanticamente óbvio que é.

(E se o bom Senhor Ramsey ainda está lendo, você ou seus amigos semanticista poderia me dar uma palavra melhor para a “semântica”, fase que estou usando aqui? Seria bom para usar um termo mais apropriado. )

Saudações, Ed.

Answer 2

O encapsulamento e abstração resultantes são claramente os principais pontos fortes de OO. As "coisas" predicado que "ações" pode ser invocado sobre eles, então substantivos assumir uma importância semântica maior do que verbos.

Em última análise, é difícil imaginar a concepção de um sistema complexo de uma forma consistente e sustentável, sem algum nível de encapsulamento.

Answer 3

Como um programador Lisp, cujo sistema de objeto sem dúvida fornece nenhuma delas, eu digo:. Nenhuma das opções acima

jwz:. "O modelo de objeto pseudo-Smalltalk perde e que funções genéricas (adequadamente limitado pela não-external-substituições regra) win"

Eu acho que os atributos desejáveis ??que você e outros listar aqui (encapsulamento, modularidade, etc.) não são tão inerente OO como você pensa. Eles são muitas vezes apresentadas juntamente com OO Java-estilo, mas não puramente a conseqüência disso.

Answer 4

Isolando Complexidade é IMO o principal objetivo de qualquer projeto:. Encapsular funcionalidade atrás de uma interface que é simples de utilização do que a própria funcionalidade

OO fornece vários mecanismos para isso - a menção dois oyu:

Encapsulation permite criar uma superfície personalizado que é independente da execução efectiva. (Parafraseando, "meio mais simples diferente").

Semântica permite a entidades modelo que representam elementos do domínio do problema, então eles são mais fáceis de entender.

---

Qualquer projeto de atingir um determinado tamanho se torna um exercício de gestão da complexidade. Eu aposto uma reivindicação que ao longo dos anos, a programação tem desnatado ao longo dos limites de complexidade que # aprendi a gerir.

Eu não têm se interessou em programação funcional por anos, mas no meu entender ele pode ser melhor descrito pelo significado de um matemático das palavras poderoso, elgant, amd bonitas. "Beautiful" e "elegante", neste contexto, tentar descrever uma idéia brilhante para a verdade ou a estrutura relevante de um sistema complexo, olhando para ele de um ponto de vista onde é surpreendentemente simples. ele aceita a complexidade como um dado, e tenta navegar ele.

A flexibilidade que você menciona é no meu entender a capacidade de alterar o POV de acordo com suas necessidades - mas isso é contrário aos encapsulamento:. O que é um detalhe sem sentido de uma posição pode ser a única relevante em outro

OO, OTOH, é os reducionistas aproximar: mudamos POV, indo para um nível superior. Em "OO velho", há um uma única hierarquia de POVs, interfaces são - neste modelo - uma maneira de modelar diferentes POVs.

Se assim posso dizer, a força de OO está sendo mais adequado para "pessoas normais".

Answer 5

Alguma forma de modularidade é a chave para qualquer projeto escalável. As limitações dos seres humanos impede as pessoas de "grokking" demasiada informação de uma só vez, por isso temos de problemas subdividem em gerenciáveis, pedaços de coesão, tanto para fornecer uma base para a compreensão um grande projeto , bem como uma forma de subdividem as atribuições de trabalho de um grande projeto entre muitas pessoas.

Como escolher a "divisão" mais eficaz / "partição" de um grande projeto para atingir os objetivos acima? A experiência tem mostrado que OO é o grande vencedor aqui, e eu acho que muitas pessoas concordam que dois atributos-chave de OO que o tornam bom nisso são:

• Encapsulated : cada classe encapsula um "segredo" - um conjunto de específicas da implementação suposições-que-é-provável de se ter de trocar-over-time sobre sua implementação - e expõe uma interface que é agnóstico para estes pressupostos; camadas essas abstrações encapsulados torna possível arquitetar um design robusto onde os componentes / implementações podem ser facilmente trocados em face das mudanças previstas.
• Substantivo centrado : na maioria dos domínios, os seres humanos parecem melhor na primeira decomposição de um modelo de domínio pelo pensamento sobre os substantivos / dados de um domínio, seguido por identificar os verbos de apoio que estão associados com cada substantivo .

Em relação programação funcional (FP) versus OO, eu tenho Blogged sobre isso, mas brevemente acho que FP é mais sobre técnicas de implementação passo que OO é mais sobre a estrutura do programa e design, e, assim, os dois são complementares, com OO ser mais dominante no 'grande' extremo da escala e FP sendo mais dominante no 'pequeno' final. Ou seja, em um grande projeto, a estrutura de alto nível é melhor descrito pelo design de classe OO, mas muitos dos detalhes de nível de módulo (implementações, e detalhes das formas das interfaces dos módulos) são melhor forma de FP influências.

Answer 6

A força de design orientado a objeto é proporcional ao quanto ligação tardia ocorre no design. Esta é a noção de Kay de OO, não a noção Nygaard. Alan Kay escreveu :

OOP para mim significa que apenas mensagens, locais retenção e proteção e esconderijo do processo do estado, e extrema atrasado-ligação de todas as coisas. Pode ser feito em Smalltalk e LISP. Lá são, possivelmente, outros sistemas nos quais isso é possível, mas eu não estou ciente de -los.

Grande parte das ignora literatura tarde obrigatório em favor da ideia de C ++ da orientação a objetos.

Answer 7

Vamos dar uma passo para trás e olhar para isso de um nível superior. As vantagens de qualquer mentira recurso de linguagem na capacidade de expressar sucintamente o problema / solução de uma forma mais natural em relação ao domínio do problema.

A mecânica de OOP são facilmente implementados em C simples, com estruturas e ponteiros de função. Você pode até obter um pouco de OOP sensação fazê-lo dessa maneira. No entanto, expressões idiomáticas OOP não são tão próximo em tal ambiente. Quando não há suporte ao idioma real para OOP, em seguida, a expressividade do paradigma vem de fora, e a forma como uma implementos língua uma idéia tem um impacto muito real sobre o que é "disse" e como. Por exemplo, veja as diferenças de código usando fechamentos / lambdas em Lisp, Python, Ruby, etc.

Assim, no final não é sobre os componentes e conceitos subjacentes, mas sim como eles estão juntos e usados ??que fazem OO em C ++ o que é.

Answer 8

O encapsulamento em conjunto com Polimorfismo. A capacidade de aulas na maioria das linguagens OOP para implementar uma ou mais interfaces teve o maior impacto sobre o desenvolvimento do meu software. Este recurso permite-me definir com precisão a interação entre dois objetos.

Não só definir as interações mas documentá-lo de modo que anos mais tarde eu posso voltar a essa seção do código e ver o que está acontecendo com clareza.

Esta característica é a principal razão pela qual eu prefiro usar linguagens OOP sobre linguagens funcionais. software enquanto muito poderoso eu encontrei escrito em linguagens funcionais para ser uma dor de manter quando o ciclo de manutenção é medida em décadas. (Software AutoLisp encontrados em AutoCAD)

Answer 9

IMHO, OO significa simplesmente objetos que interagem com outros objetos. Encapsulamento significa simplesmente abstrair um conceito. Então, você cria um soquete e .Connect () para alguma coisa. Como ele se conecta, você realmente não me importo (que é basicamente a minha definição de encapsulamento).

E, programação funcional pura pode usar objeto para se comunicar .. mas esses objetos precisam ser imutável. Então, novamente IMHO, FP pode facilmente usar conceito OO; linguagem imperativa, como C ainda pode usar o conceito de OO .. por exemplo, um arquivo para cada "classe" com uma seção privada, que não deve ser usado.

Answer 10

A sua questão lê como Você deseja obter os benefícios de um casa através da análise de um tijolo.

Ter a capacidade de fornecer o contexto semântico e encapsulamento são apenas as capacidades básicas de uma classe em OO. (Como uma lata de tijolos suportar uma certa força e reivindicar um determinado espaço.)

Para continuar a analogia: Para obter o máximo de tijolos, apenas colocá-los juntos. o mesmo se aplica a classes e objetos.

são um monte de padrões de projeto que pode ser usado para OO programação. A maioria deles recorrer às capacidades "encapsulamento" e "Semântica", que você mencionou.

Alguns desses padrões são ainda uma resposta para o terceiro parágrafo da sua pergunta:

• Se você deseja estender o comportamento de uma classe existente, você pode criar uma classe derivada.
• Se você deseja estender ou alterar o comportamento de um objeto existente, você pode considerar o padrão decorador .

Answer 11

O verdadeiro poder de mentiras OO em polimorfismo, em vez de encapsulamento. Encapsulamento, até certo ponto, é possível e é usado em linguagens funcionais, mas polimorfismo seria muito estranho se implementado em linguagem funcional.

(Leia "padrão de design" por bando dos quatro para entender o poder de OO).

@Phil, a diferença que você mencionou, se eu entendi corretamente, é entre a forma como o programa de dados invoca / método: em oo, lá primeiro é um objeto / instância e, em seguida, os dados / método do objeto é invocado através do objecto; no funcional, o método está diretamente invocado.

No entanto, olhando para a implementação de um programa funcional, vemos que os dados e o método são envolvidos (em um arquivo, mas não em uma classe). Por exemplo, um programa C tem o arquivo de cabeçalho que declara as funções acessíveis por outro arquivo, e os dados é uma dados privados se só é acessível através destas funções declaradas. Enquanto um programador é suficiente cuidado, a maior parte do encapsulamento em OO pode ser implementado em programas funcionais. (Herança Mesmo está disponível usando alguns truques de ponteiro.)