Faz conceito arquitetura n camadas pausa OO de encapsulamento

Question

Eu tenho um aplicativo de camada n com camada de apresentação, camada de negócios, DAL e Business Objects camada. Separando os objetos e a operação de escrita sobre os objetos quebrar o objeto conceito de encapsulamento orientado.

Answer 1

No. Considere o que significa "encapsulamento":. Os detalhes da implementação de uma classe são escondidos por trás da interface (mensagens ou métodos) da classe

Na verdade, você pode derivar a arquitetura n-tier diretamente de princípios OO e da Lei de Parnas: um módulo deve encapsular o que é susceptível de mudança. A camada de apresentação encapsula os detalhes da criação de uma interface "visível"; a camada intermediária do modelo do próprio negócio; eo back-end os detalhes de acesso ao armazenamento de dados persistente.

Answer 2

Veja este exemplo, tirada este artigo :

public class Position
{
  public double distance( Position position )
  {
    // calculate and return distance...
  }

  public double heading( Position position )
  {
    // calculate and return heading...
  }

  public double latitude;
  public double longitude;
}

De acordo com o mesmo artigo este é um bom exemplo de encapsulamento, porque os dados e operações que realizam em que os dados são empacotados. Note-se que o encapsulamento aqui faz esconderijo não dados garantia ou proteção.

Em contraste, Steve McConnell no código completo (2ª. Ed., Seção 6.2, Bom Encapsulation) argumentam que o encapsulamento está quebrado, porque os dados membro está exposto.

Na sua situação, se seus objetos de dados e os objetos manipulá-los são separados, mas não têm campos públicos, então encapsulamento é quebradas de acordo com a primeira definição, mas não necessariamente no segundo caso. Portanto, temos duas visões contrastantes. Um diz ocultação de dados não é uma parte de encapsulamento, a outra fonte diz ocultação de dados é uma parte vital de encapsulamento.

Os dados esconderijo pode ser visto como uma parte de ocultação de informações que é o princípio que afirma que você deve esconder decisões de design complexos e fontes de mudança. O consenso geral parece ser que encapsulamento é visto como uma manifestação de ocultação de informações, incluindo dados escondendo.

Ou, como puts Wikipédia -lo:

O termo encapsulamento é frequentemente usado alternadamente com informações se escondendo. Nem todos concordam com a distinções entre os dois embora; pode-se pensar em esconder informações sendo o princípio e encapsulamento sendo a técnica. Um módulo de software couros informações por encapsular o informação para um módulo ou outra construção que apresenta uma interface.

Mas ... a referência que se segue presente número é o mesmo artigo de onde eu tirei o primeiro exemplo, por isso mesmo Wikipedia está misturando as coisas aqui. Além disso, o uso da palavra "distinções" parece errado aqui.

É um pouco manco ter que dizer isso no final, mas a terminologia para encapsulamento e ocultamento de informações está sobrecarregado, por isso tudo depende da fonte. No seu caso eu iria ficar com a definição de encapsulamento como "detalhes de implementação se escondendo atrás de uma abstração". Portanto, você não está necessariamente quebrar o encapsulamento.

Answer 3

Isso é realmente um grande AP ponto!

Em alguns casos, eu concordaria que quebrar uma única operação em vários objetos, de fato, afetar adversamente o encapsulamento. Na verdade, eu acho que isso é um grande problema que eu vi em muitas arquiteturas web.

Por outro lado, certas coisas são úteis para se decompor, como como um objeto para enviar consultas ao banco de dados, etc.

Eu acho que existe um argumento a ser feito, em muitos casos, para melhor "encapsular" uma página web, de modo que mais da funcionalidade está contido com um único objeto ou menos objetos. Assim, uma abordagem mais "page-centric", em vez de dispersar a lógica por vastas multidões de classes.

Eu acho que esta é uma questão vital nós sempre temos que nos perguntar com cada sistema nós projetamos - quanto ao abstrato? Quanto a manter específico? Como efetivamente decompor o sistema em classes.

Answer 4

Os dois não são os mesmos. Uma arquitetura é mais referindo-se a módulos (grupos de classes). Refere-se ao encapsulamento que esconde o funcionamento interno de uma classe. Você pode ter os dois se você projetar seu sistema bem o suficiente.

O que você pode precisar de ter cuidado com é em definir claramente a separação de responsabilidade. Contanto que você é claro sobre o que cada módulo / camada é para, e específico sobre o que cada classe faz (e que cada método da classe faz), então você deve ser capaz de ter um bom design.

Estou apenas especulando aqui, mas você pode estar interessado no fachada design padrão ao projetar uma interface para um módulo.

Com relação ao seu comentário abaixo, a lógica deve ser definitivamente na própria classe empregado. Eu gostaria de questionar a lógica em ter uma camada separada para objetos de negócios. Muitas vezes, é uma tentação para definir classes como "Funcionário" porque modelar objetos do mundo real ou conceitos. No entanto, a sua motivação para a definição de uma classe não deve ser "modelar um objeto do mundo real".

Você deve definir o propósito do seu módulo (por que você tem uma camada de lógica de negócios? Para conter toda a lógica de negócios.) E, em seguida, colocar o que você precisa lá. Se a classe "Funcionário" é a classe que precisa de lógica de negócios calcular, então ele deve ir na classe de lógica de negócios. Se não, então ele deve ir em seu negócio objetos classe (independentemente do que é para). Se ele precisa fazer duas coisas diferentes, e, portanto, poderia caber em duas camadas, em seguida, considerar separando-a em duas classes - lembre-se de que seus objetos não precisam modelar as coisas do mundo real. Robert C Martin sugere a definição de suas classes de tal forma que os limites das classes são os limites de uso.