#encapsulamento

O que é Encapsulamento em Java? O encapsulamento é um dos pilares fundamentais da programação orientada a objetos (POO) e desempenha um papel essencial na construção de aplicações bem estruturadas, seguras e fáceis de manter. Em termos simples, o encapsulamento refere-se ao ato de esconder os detalhes internos de um objeto e expor apenas o que é necessário para o seu uso. Essa prática promove a…

Pensando orientado a objetos

     É bastante comum que quem esteja iniciando no mundo da programação orientada a objetos(POO) ainda pense de forma estruturada, não estou dizendo que POO é a melhor forma de se programar, existem outros paradigmas (paradigma é a representação de um padrão a ser seguido.) que são usados, cada um tem suas vantagens e desvantagens na sua proposta. Como então deixar de pensar de forma estruturada…

Encapsulamento x Acoplamento Energético

[su_frame align=”right”]http://swf.tubechop.com/tubechop.swf?vurl=mNDxAczrQGw&start=529&end=561&cid=8196597[/su_frame] “O encapsulamento é uma coisa, é a pessoa fica encapsulada, fica dentro de uma bolha, agora acoplamento áurico ou energético a pessoa que entra e faz assimilação com outra reciprocamente. esse é que é o caminho.

As coisas são mais ou menos parecidas, mas são diferentes, elas se…

2:  wat

3: AI MEU DEUS

Quando falamos sobre design em orientação a objetos, estamos basicamente falando sobre responsabilidade e relacionamento. Com responsabilidade quero dizer algo que alguma coisa faz e com relacionamento quero dizer como alguma coisa utiliza aquilo que outra coisa faz. O Design de Software Orientado a Objetos trata especificamente da forma com que os objetos se relacionam, ou seja, como expor a responsabilidade dos objetos de forma que outros objetos possam se relacionar.

Do ponto de vista do Design de Software Orientado a Objetos, não importa, exatamente, como alguma coisa é feita. Pelo contrário, o objetivo é justamente evitar esse conhecimento sobre a implementação, encapsulando o que é específico para permitir que trabalhemos com a definição conceitual daquilo que precisamos utilizar. Por exemplo, é comum uma aplicação precisar trabalhar com um SGBD. Se nossos objetos tiverem conhecimento específico de que estamos, na verdade, trabalhando com MySQL, então é provável que os comportamentos relacionados a esse SGBD influenciem o comportamento de nossos objetos - Isso, do ponto de vista de design, é ruim.

Grande parte do design orientado a objetos envolve API, ou seja, a forma com que expomos as responsabilidades. API significa interface que, por sua vez, significa aquilo que vemos e podemos trabalhar com. O grande porém, é podemos ter APIs públicas e APIs privadas do ponto de vista do objeto referencial. Voltando ao exemplo do SGBD, as questões específicas referentes à conexão, são irrelevantes para objetos de alto nível, que vão apenas consumir a base. Porém, questões como essas podem ser altamente relevantes para objetos de baixo nível, se estivermos desenvolvendo algo como a PDO, do PHP, que abstrai a comunicação com vários SGBDs relacionais.

Tipos de APIs

Algumas tecnologias permitem a elaboração dessas APIs de forma diferente, como friend class em C++, protected class em Java, etc. Mas independentemente da forma como é construída, existem três tipos de APIs:

API pública

Objetos de alto nível não devem ter conhecimentos sobre as responsabilidades dos objetos de baixo nível. Quanto mais conhecimento os objetos de alto nível tiverem sobre os de baixo nível, mais complexo será manutenção desse código. A API pública deve ser a mais refinada e abstrata possível. Ao definir essa API, devemos pensar no conceito que o objeto representa.

Como exemplo de refinamento conceitual, a PDO do PHP é um excelente exemplo, pois permite que utilizemos os mesmos métodos de interface, independentemente do SGBD que estamos trabalhando.

API protegida

A API protegida é, ao mesmo tempo, pública e privada, dependendo do referencial. Internamente, para os objetos que fazem parte da hierarquia, essa API é pública. Assim, métodos com responsabilidade de baixo nível são acessíveis, permitindo que reutilizemos código comum para aquela responsabilidade. Por exemplo, se mais do que um SGBD possuir uma forma comum para estabelecer conexão, então o método de conexão pode ser protegido.

API privada

A API privada é visível apenas para o objeto que a define. Isso significa que a responsabilidade dos métodos que compõem essa API são tão específicos para aquela implementação, que não devem ser expostos. Isso chama-se encapsulamento e é extremamente para garantir a abstração.

Violação do encapsulamento

A exposição de uma API privada para um participante que não deveria ter conhecimento sobre ela, viola o encapsulamento, que viola a abstração ao permitir conhecimento específico sobre a implementação. É claro que você, como um desenvolvedor responsável, dirá que tomará cuidado com esse conhecimento. Mas o fato é que muito provavelmente o conhecimento específico afetará seu código e, se isso ocorrer, você terá problemas se precisar variar o participante que detém determinada responsabilidade.