É uma função um exemplo de encapsulamento?

Question

Ao colocar a funcionalidade em uma função, isso por si só constituem um exemplo de encapsulamento ou você precisa usar objetos para ter encapsulamento?

Eu estou tentando entender o conceito de encapsulamento. O que eu achava que era se eu ir de algo como isto:

n = n + 1

que é executado em estado selvagem como parte de um grande corpo de código e, em seguida, eu levo isso, e colocá-lo em uma função como esta, então, tenho encapsulado que a lógica disso em um método:

addOne(n)
    n = n + 1
    return n

Ou é mais o caso que é apenas o encapsulamento se eu estou escondendo os detalhes de addOne do mundo exterior? - como se é um método de objeto e eu usar um modificador de acesso de private / protected

Answer 1

Talvez você esteja confuso abstração com encapsulamento, o que é entendido no contexto mais amplo da orientação a objetos.

O encapsulamento inclui adequadamente todos os três do seguinte:

• Abstraction
• Implementação Hiding
• Divisão de Responsabilidade

A abstração é apenas um componente de encapsulamento. No seu exemplo você abstraída a funcionalidade adicionando a partir do corpo principal do código em que residiram. Você faz isso através da identificação de alguns pontos comuns no código - o reconhecimento de um conceito (adição) sobre um caso específico (acrescentando o número um para a variável n). Devido a essa capacidade, abstração torna um componente encapsulado - um método ou um objeto -. Reutilizável

Igualmente importante para a noção de encapsulamento é a idéia de esconder implementação. É por isso que a encapsulação é discutido na arena de orientação por objectos. Implementação esconderijo protege um objecto a partir dos seus utilizadores e vice-versa. Em OO, você faz isso através da apresentação de uma interface de métodos públicos para os usuários de seu objeto, enquanto a implementação do objeto ocorre dentro métodos privados.

Isto serve dois benefícios. Primeiro, limitando o acesso ao seu objeto, você evitar uma situação em que os usuários do objeto pode deixar o objeto em um estado inválido. Em segundo lugar, do ponto de vista do usuário, quando eles usam o objeto que eles só são fracamente acoplada a ele -. Se você mudar a sua implementação, mais tarde, eles não são afetados

Finalmente, a divisão do responsility - no contexto mais amplo de um projeto OO - é algo que deve ser considerado para encapsulamento endereço corretamente. Não adianta encapsular uma coleção aleatória de funções - a responsabilidade precisa ser limpa e logicamente definido de modo que não é tão pouca sobreposição ou ambiguidade quanto possível. Por exemplo, se temos um objeto WC vamos querer parede fora de seu domínio de responsabilidades do nosso objeto de cozinha.

Em um sentido limitado, porém, você está correto que uma função, digamos, 'modulariza' algumas funcionalidades abstraindo-lo. Mas, como eu disse, 'encapsulamento' como um termo é entendido no contexto mais amplo da orientação a objetos para aplicar a uma forma de modularização que atende aos três critérios listados acima.

Answer 2

Eu serei o primeiro a discordar com o que parece ser a tendência resposta. Sim, uma função encapsula uma certa quantidade de implementação. Você não precisa de um objeto (que eu acho que você usa para significar uma classe).

Consulte Meyers também.

Answer 3

Claro que é.

Por exemplo, um método que opera apenas em seus parâmetros seria considerado "melhor encapsulado" do que um método que opera exclusivamente em dados estáticos globais.

O encapsulamento tem sido em torno de tempo antes OOP:)

Answer 4

Um método não é mais um exemplo de encapsulação do que um carro é um exemplo de boa condução. Encapsulamento não é sobre o synax, é uma questão de design lógico. Ambos os objetos e métodos podem apresentar bons e maus encapsulamento.

A maneira mais simples de pensar sobre isso é se as peles de código / abstrai os detalhes de outras partes do código que não têm a necessidade de saber / cuidado sobre a implementação.

Voltando ao exemplo do carro: ofertas Transmissão automática boa encapsulamento: Como um motorista que se preocupam com a frente / trás e velocidade. Transmissão Manual é ruim encapsulamento: Do ??ponto de vista do motorista o equipamento específico necessário para baixa / alta velocidade é geralmente irrelevante para a intenção do motorista .

Answer 5

Não, objetos não são necessário para encapsulamento. No sentido muito mais amplo, "encapsulamento" significa apenas "esconder os detalhes de vista" e, nesse sentido um método é encapsulando os seus detalhes de implementação.

Isso realmente não significa que você pode sair e dizer que seu código está bem concebido apenas porque você o dividiu-se em métodos, no entanto. Um programa que consiste de 500 métodos públicos não é muito melhor do que o mesmo programa implementado em um método 1000-line.

Na construção de um programa, independentemente de se você estiver usando o objeto orientado técnicas ou não, você precisa pensar sobre o encapsulamento em muitos lugares diferentes: esconder os detalhes de implementação de um método, escondendo dados de código que não precisam saber sobre ele, simplificando interfaces para módulos, etc.

Update:. Para responder à sua pergunta atualizado, tanto a "colocar o código em um método" e "usando um modificador de acesso" são maneiras diferentes de encapsular a lógica, mas cada um age em um nível diferente

Colocar código em um peles método das linhas individuais de código que compõem esse método para que os chamadores não precisa se preocupar com o que essas linhas são; eles só se preocupar com a assinatura do método.

Sinalizar um método em uma classe como (por exemplo) se esconde "privadas" que o método de modo que um consumidor do class não precisa se preocupar com isso; eles só se preocupam com os métodos públicos (ou propriedades) de sua classe.

Answer 6

É uma coisa de nível componente

Verifique este out:

Em ciência da computação, encapsulamento é o esconderijo dos mecanismos internos e estruturas de dados de um componente de software por trás de uma interface definida, de maneira tal que os usuários do componente (outras peças de software) só precisa saber o que o componente faz , e não pode tornar-se dependente dos detalhes de como ele faz isso. O objetivo é alcançar potencial de mudança:. Os mecanismos internos do componente pode ser melhorada sem impacto sobre outros componentes, ou o componente pode ser substituído por um diferente que suporta a mesma interface pública

(Eu não entendo muito bem a sua pergunta, deixe-me saber se esse link não cobrir suas dúvidas)

Answer 7

O conceito abstrato de meios de encapsulamento que você esconde os detalhes de implementação. Objeto-orientação é apenas um exemplo do uso de ecnapsulation. Outro exemplo é a linguagem chamada módulo-2, que usa (ou usado) módulos de implementação e módulos de definição. Os módulos de definição hid a aplicação real e, por conseguinte, fornecida encapsulamento.

O encapsulamento é usado quando você pode considerar algo uma caixa preta. Os objetos são uma caixa preta. Você conhece os métodos que eles fornecem, mas não como eles são implementados.

[EDIT] Quanto ao exemplo na questão atualização: isso depende de como estreita ou larga você define encapsulamento. Seu exemplo AddOne não esconde qualquer coisa que eu acredito. Seria informações esconderijo / encapsulamento se sua variável seria um índice de array e você chamaria o seu método MoveNext e talvez ter outro setValue função e getValue. Isso permitiria que as pessoas (juntamente talvez com algumas outras funções) para navegar no seu estrutura e configurar e obter variáveis ??com eles estando ciente de que você usar uma matriz. Se você linguagem de programação iria apoiar outros ou mais ricos conceitos que você pode mudar a implementação de moveNext, setValue e getValue com a mudança do significado e da interface. Para mim, isso é o encapsulamento.

Answer 8

Vamos simplificar isso um pouco com uma analogia: você gira a chave do seu carro e ele inicia. Você sabe que há mais do que apenas a chave, mas você não Have para saber o está acontecendo lá dentro. Para você, por sua vez, key = partida do motor. A interface da chave (isto é, por exemplo, a chamada de função) esconde a implementação do motor de arranque girando o motor, etc ... (a implementação). Isso é encapsulamento. Você está poupado de ter que saber o que está acontecendo sob o capô, e você está feliz por isso.

Se você criou uma mão artificial, por exemplo, que roda a chave para você, que de não encapsulamento. Você está transformando a chave com cruft intermediário adicional sem esconder nada. Isso é o que o seu exemplo me faz lembrar - não é encapsular detalhes de implementação, mesmo que ambos são realizados através de chamadas de função. Neste exemplo, qualquer um pegar o seu código não vai agradecer por isso. Eles, na verdade, é mais provável que clube você com a mão artificial.

Qualquer método que você pode pensar para esconder informações (classes, funções, bibliotecas dinâmicas, macros) pode ser usado para encapsulamento.

Answer 9

A encapsulação é um processo em que os atributos (membro de dados) e comportamento (função de membro) de uma objectos em combinados em conjunto como uma entidade única, referem-se como classe.

Answer 10

O Modelo de Referência do Open Distributed Processing - escrito pelo International Organization for Standardization - define os seguintes 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

Estes, irá apreciar, são bastante amplas. Vamos ver, no entanto, se colocando funcionalidade dentro de uma função pode logicamente ser considerados no sentido de encapsulamento nestes termos.

Em primeiro lugar, uma função é claramente um modelo de um 'coisa de interesse,' na medida em que representa um algoritmo que você (presumivelmente) deseja executado e que pertence algoritmo para algum problema que você está tentando resolver (e, portanto, é um modelo do mesmo).

Será que uma função tem comportamento? Certamente que sim: ele contém uma coleção de ações (que pode ser qualquer número de instruções executáveis) que são executados sob a restrição de que a função deve ser chamado a partir de algum lugar antes que ele possa executar. A função não pode espontaneamente ser chamado a qualquer momento, sem fator causal. Soa como legalese? Pode apostar. Mas vamos lavrar em, no entanto.

Será que uma função tem uma interface? Certamente que sim: ele tem um nome e uma coleção de parâmetros formais, que no mapa vez das instruções executáveis ??contida na função em que, uma vez uma função é chamada, a lista de nomes e parâmetro são entendidos para identificar exclusivamente a coleção de executável declarações a serem executados sem o chamado partido de especificar essas declarações reais.

Será que uma função tem a propriedade de que a informação contida na função só é acessível através de interações nas interfaces compatíveis com o objeto? Hmm, bem, ele pode.

Como algumas informações são acessíveis através de sua interface, algumas informações devem ser escondido e inacessível dentro da função. (A propriedade de 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 mudança.) Assim que a informação está escondida dentro de uma função?

Para ver isto, devemos primeiro considerar escala. É fácil afirmar que, por exemplo, classes Java pode ser encapsulado dentro de um pacote: algumas das classes será público (e, portanto, ser a interface do pacote) e alguns serão pacote-privadas (e, portanto, a informação escondida dentro do pacote) . Em teoria encapsulação, as classes de formar nós e os pacotes de formar regiões encapsulados, com o conjunto formando um gráfico encapsulado; o gráfico de classes e os pacotes é chamado o terceiro gráfico.

Também é fácil afirmar que as funções (ou métodos) em si são encapsulados dentro de classes. Mais uma vez, algumas funções serão públicas (e, portanto, fazer parte da interface do class) e alguns serão privada (e, portanto, a informação escondida dentro da classe). O gráfico de funções e classes é chamado o segundo gráfico.

Agora chegamos a funções. Se as funções estão a ser um meio de encapsulamento-se que eles devem conter algum público informações para outras funções e algumas informações que é dentro da função oculta-informação. O que poderia esta informação ser?

Um candidato é dado a nós por McCabe. Em seu papel de referência sobre a complexidade ciclomática, Thomas McCabe descreve o código-fonte em que, 'cada nó no corresponde gráfico a um bloco de código no programaonde o fluxo é seqüencial e os arcos correspondem aos ramos tomadas no programa. '

Vamos dar o bloco McCabian de execução sequencial como a unidade de informação que pode ser encapsulado dentro de uma função. Como o primeiro bloco dentro da função é sempre o bloco primeiro e único garantido para ser executado, podemos considerar o primeiro bloco a ser pública, na medida em que pode ser chamado por outras funções. Todos os outros blocos dentro da função, no entanto, não pode ser chamado por outras funções (exceto em linguagens que permitem saltar em funções meados de fluxo) e assim por estes blocos podem ser considerados de informação escondida dentro da função.

Tomar essas definições (talvez um pouco tênues), então podemos dizer sim: colocar funcionalidade dentro de uma função não constitui para encapsulamento. O encapsulamento de blocos dentro de funções é o primeiro gráfico.

Há uma caveate, no entanto. Você consideraria um pacote cujo cada classe foi pública a ser encapsulado? De acordo com as definições acima, ele faz passar no teste, como você pode dizer que a interface para o pacote (ou seja, todas as classes públicas), de fato, oferecem um subconjunto do comportamento do pacote para outros pacotes. Mas o subconjunto neste caso é o comportamento de todo o pacote, como há classes são escondidos-informação. Assim, apesar regorously satisfazer as definições acima, sentimos que não satisfaz o espírito das definições, como certamente algo deve ser a informação escondida para a verdadeira encapsulamento a ser reivindicado.

O mesmo é verdadeiro para o exampe você dá. Nós podemos certamente considerar n = n + 1 para ser um único bloco McCabian, como ele (e a instrução de retorno) é um único fluxo, sequencial de execuções. Mas a função em que você colocou esta contém, assim, apenas um bloco, e esse bloco é o bloco única pública da função e, portanto, não há blocos escondidos em informação dentro de sua função proposta. Por isso, pode satisfazer a definição de encapsulamento, mas eu diria que ele não satisfazer o espírito.

Tudo isso, é claro, é acadêmica a menos que você pode provar uma prestação como encapsulamento.

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, é a lógica.

A configuração de um sistema é a identificação precisa e exaustiva de cada nodo do sistema e a região encapsulado no qual ele reside; uma configuração específica de um sistema Java é - na terceira gráfico -. para identificar todas as classes do sistema e especificar o pacote no qual cada classe reside

Para encapsular logicamente um meio de sistema para identificar alguma propriedade matemática do sistema que depende de sua configuração e, em seguida, configure esse sistema para que a propriedade está matematicamente minimizado.

teoria Encapsulation propõe que todos os gráficos encapsulados expressar um número máximo de bordas (MPE). Em um sistema Java de classes e pacotes, por exemplo, o MPE é o número máximo de dependências de código fonte que pode existir entre todas as classes desse sistema. Duas classes dentro da mesma embalagem não pode ser um do outro e assim ambos podem potencialmente formar depdencies um sobre o outro escondido em informações. Duas classes de pacote-privadas em pacotes separados, no entanto, não podem formar dependências em um outro.

teoria Encapsulation nos diz quantos pacotes que devemos ter para um determinado número de classes para que o MPE é minimizado. Isso pode ser útil porque a forma fraca do princípio de Estados fardo que a carga máxima potencial de transformar uma coleção de entidades é uma função do número máximo de entidades transformados - em outras palavras, o código fonte mais potencial dependências você tem entre suas classes, quanto maior o custo potencial de fazer qualquer atualização particular. Minimizando o MPE minimiza assim o custo potencial máximo de atualizações.

Dada n classes e uma exigência de aulas p públicas por pacote, shows teoria de encapsulamento que o número de pacotes, r, devemos ter para minimizar o EMA é dado pela equação:. R = sqrt (n / p)

Isto também se aplica ao número de funções que você deve ter, dado o número total, n, de blocos McCabian em seu sistema. Funções sempre tem apenas uma quadra pública, como mencionamos acima, e assim a equação para o número de funções, r, para ter em seus simplifica sistema para:. R = sqrt (n)

Na verdade, poucos considerado o número total de blocos em seu sistema quando se pratica encapsulamento, mas é prontamente feito no nível da classe / pacote. E, além disso, minimizando MPE é quase inteiramente entuitive: ele é feito através da minimização do número de aulas públicas e tentando distribuir uniformemente as classes mais pacotes (ou pelo menos evitar ter a maioria dos pacotes com, digamos, 30 aulas, e um pacakge monstro com 500 aulas, caso em que o MPE interna deste último pode facilmente sobrecarregar o MPE de todos os outros).

Encapsulation envolve, assim, encontrar um equilíbrio entre a semântica e a lógica.

Tudo muito divertido.

Answer 11

na terminologia orientada a objeto estrito, poderíamos ser tentados a dizer não, uma função "mero" não é suficientemente poderosa para ser chamada de encapsulamento ... mas no mundo real a resposta óbvia é "sim, uma função encapsula algum código"

para os puristas de OO que se irritam com essa blasfêmia, considere uma classe anônima estático com nenhum estado e um método único; se a função AddOne () não é o encapsulamento, em seguida, nem é esta classe!

e apenas para ser pedante, encapsulação é uma forma de abstracção, não vice-versa. ; -)

Answer 12

Não é normalmente muito sentido falar de encapsulamento sem referência a propriedades em vez de apenas métodos - você pode colocar controles de acesso sobre métodos, certamente, mas é difícil ver como é que vai ser outro do que sem sentido, sem quaisquer dados escopo para o método encapsulado. Provavelmente você poderia fazer algum argumento validá-lo, mas eu suspeito que seria tortuosa.

provavelmente não Então, não, você está usando encapsulamento só porque você colocar um método em uma classe em vez de tê-lo como uma função global.