Encapsulamento

A idéia do encapsulamento é proteger o código. O cliente não precisa saber como é feito, ele só precisa saber que é feito aquele procedimento.

Uma explicação fácil do Maccorati:

Outro bom exemplo:

mas isso é feito pra esconder o código do usuário ou de outro programador?
No caso de outro programador ele não teria que saber como o código funciona para poder usá-lo?

Ei entendi como usar o encapsulamento, só estou tentando entender o porque de usa-lo, alguem poderia fornecer um exemplo prático do uso do mesmo?

Outra coisa, isso é exclusivo da linguagem Java? Eu comecei a aprender a programar com Python, oque seria encapsular em Python?

Kazdum:

Galera eu já li vários tópcios aqui, ja vi as tele aulas sobre oassunto na XTi e também to lendo o Head First Java.
Enfim, encapsulamento é somente um jeito de “validar” oque vai ser definido numa classe?

Não, é muito mais. Segundo Page-Jones:

Ou seja, é um conceito muito maior do que o uso de getters e setters ou o uso de modificadores de acesso (público, privado, protegido). Uma vez que você entende que um objeto é composto de estado + comportamento e que num sistema OO objetos interagem uns com os outros, a ideia do encapsulamento é que o um objeto somente possa ser alterado por meio da sua interface. Você efetivamente não deve saber como o objeto é representado internamente.

Estas validações que você se refere são importantes. A elas damos o nome de invariante da classe. Estude também sobre pré-condições e pós-condições.

O usuário da classe Velocidade não precisa saber como ela é representada internamente e isto traz muitas vantagens. Você pode representar o valor da velocidade em quilômetros/hora, milhas/hora ou qualquer unidade que você desejar. Isto traz um ganho muito grande em manutenibilidade, uma vez que você pode alterar a representação interna do objeto e garantir que o sistema todo não quebre. Ainda, a tua classe Velocidade pode ter métodos que convertam este valor para as diversas unidades que você precisa.

O encapsulamento é uma das maiores vantagens de OO, podemos isolar o atributo da classe, podemos alterar o atributo da forma que quisermos dentro da classe, incluir tratamentos do dado dentro dos métodos, ou criar uma regra de negócio para manipulação daquele dado, ou até mesmo mudarmos o nome do atributo em questão sem intervir nas classes que usam os métodos getters e setters, e outra coisa importante, não devemos criar getter e setter pra todos os atributos devemos saber se ele realmente irá precisar, por exemplo, em um atributo talvez eu precise somente recuperar o valor dele, assim eu usaria somente o método get, e além do mais o controle sob seu código fica extremamente maior.

Aí você vê como a Orientação a Objetos é análoga às nossas relações concretas.

Digamos que você precisa fazer uma casa. Você procura e faz contato com um pedreiro(instancia uma classe), e requisita o serviço de construir uma casa e vê que o pedreiro precisa que um parâmetro seja passado: o material de construção(chamou o método e passou parâmetro) e como retorno o pedreiro te deu a casa pronta…

Note que você não precisa sequer pensar em como é que o pedreiro fez isso, você apenas pediu pra ele fazer.

Partindo pro lado da programação, vemos que o encapsulamento propõe regras: Um objeto precisa fazer somente aquilo que é restrito a ele(se o pedreiro precisar da ajuda de um servente, ele que se vira e arranja um, o cliente não precisa correr atrás, afinal isso é problema somente do pedreiro).

E quem requisita métodos de uma classe, não precisa ficar sabendo o que acontece lá dentro, apenas passa os parâmetros necessários e cabou-se! Só nos importamos com o resultado, não queremos complicar as coisas e aprender como o pedreiro levanta uma parede, só queremos ela.

No começo é complicado mesmo pra entender esses conceitos e uma certa aplicação para os mesmos. Mas depois que você começa a vivenciar e se deparar com código mal feito, onde uma classe acaba tendo que assumir serviço de outra, você começa a pensar: “Porque o cara não fez assim? Ele poderia ter encapsulado isso aqui, e a implementação do método desta classe seria muito mais fácil e rápida”.

A principal proposta da Orientação a Objetos é assegurar sistemas duráveis e de manutenção fácil! E aí que entra o encapsulamento(não só ele, também outros conceitos), pois ele torna o código mais legível(você vai ler apenas chamadas a métodos e se tiver algo de errado toda a lógica do negócio vai estar com quem deve conter ela.

E oque é encapsulamento em outras linguagens?
Em Python por exemplo, eu poderia criar uma classe com várias funções(métodos) e a partir do momento que eu importasse para o meu código eu poderia usar qualquer função que eu quisesse sem nem saber como ela realmente funciona, por exemplo:

a = soma(5,5)
a = 10

Seria mais ou menos isso?

Kazdum:

E oque é encapsulamento em outras linguagens?
Em Python por exemplo, eu poderia criar uma classe com várias funções(métodos) e a partir do momento que eu importasse para o meu código eu poderia usar qualquer função que eu quisesse sem nem saber como ela realmente funciona, por exemplo:

a = soma(5,5)
a = 10

Seria mais ou menos isso?

Isso mesmo colega.

Não sou entendido de Python, acho que outra pessoa pode te explicar melhor essa parte.

Mas é justamente essa a sacada do encapsulamento, pra quem chama o método só interessa o resultado, não há necessidade de saber como ele chega naquilo…

E oque é encapsulamento em outras linguagens?
Em Python por exemplo, eu poderia criar uma classe com várias funções(métodos) e a partir do momento que eu importasse para o meu código eu poderia usar qualquer função que eu quisesse sem nem saber como ela realmente funciona, por exemplo:

a = soma(5,5)
a = 10

Seria mais ou menos isso?

vou te dar um exemplo bem real.

imagina se você fosse usar uma classe complexa do java, que não usa encapsulamento e é tudo publico.

e quando colocasse la: Classe c = new Classe();

c.

na hora que você colocar o ponto em uma IDE com recurso auto-completar...eclipse, netbeans irá aparecer muita informação desnecessária, variaveis e métodos que deveriam estar acessiveis somente para processo da própria classe.

ai o programador que vai usar essa classe vai ter que olhar na documentação o que ele pode e o que ele não pode mecher, pq se mecher em algo que não devia vai dar m!@#$%

um exemplo de set complexo usado pela classe JLabel:

public void setText(String text) {

        String oldAccessibleName = null;
        if (accessibleContext != null) {
            oldAccessibleName = accessibleContext.getAccessibleName();
        }

        String oldValue = this.text;
        this.text = text;
        firePropertyChange("text", oldValue, text);

        setDisplayedMnemonicIndex(
                      SwingUtilities.findDisplayedMnemonicIndex(
                                          text, getDisplayedMnemonic()));

        if ((accessibleContext != null)
            && (accessibleContext.getAccessibleName() != oldAccessibleName)) {
                accessibleContext.firePropertyChange(
                        AccessibleContext.ACCESSIBLE_VISIBLE_DATA_PROPERTY,
                        oldAccessibleName,
                        accessibleContext.getAccessibleName());
        }
        if (text == null || oldValue == null || !text.equals(oldValue)) {
            revalidate();
            repaint();
        }
    }

o programador precisa saber como funciona pra usar o JLabel ? não... então é encapsulamento

não confunda com criar uma função para algo complexo, não é só isso...

Kazdum:

E oque é encapsulamento em outras linguagens?
Em Python por exemplo, eu poderia criar uma classe com várias funções(métodos) e a partir do momento que eu importasse para o meu código eu poderia usar qualquer função que eu quisesse sem nem saber como ela realmente funciona, por exemplo:

a = soma(5,5)
a = 10

Seria mais ou menos isso?

Encapsulamento é um termo independente de linguagem de programação. Na verdade, tem mais a ver com o paradigma de programação. Antes da orientação a objetos, utilizava-se rotinas, procedimentos, o que for. Isto é um exemplo de encapsulamento de instruções. O exemplo que você nos deu foi basicamente este, encapsulamento das instruções. Não sabemos como a soma foi feita, mas sabemos o resultado.

Para entender o encapsulamento na orientação a objetos, você primeiro precisa assumir um sistema Orientado a Objetos. Ao invés de pensar em funções, pense em objetos. Como eu mencionei anteriormente, um objeto é composto de estado + comportamento, e a ideia do encapsulamento é possibilitar acesso ao objeto somente a partir da sua interface (e não falo da interface do java aqui!). Vamos a um exemplo simples, já que falávamos de velocidade nos posts anteriores.

Um objeto Carro, que tem o atributo velocidade. A ideia é simples, ao invés de um objeto externo alterar a velocidade do carro (carro.setVelocidade(100)), ele deveria pedir para o objeto carro aumentar: carro.acelerar(), carro.reduzir(). Como a velocidade é representada internamente, não se sabe. Como o carro aumenta a velocidade, também não se sabe. A implementação (como fazer) está oculta e a representação interna da informação também.

Isto é independente de linguagem, independente de modificador de acesso. Você pode fazer um sistema sem encapsulamento em Java, python, javascript, whatever. O inverso é verdadeiro também. A questão é você pensar bem nos objetos que você tem, qual comportamento deve pertencer a qual objeto, e que cada objeto deve ser responsável por alterar o seu estado (por meio de métodos possivelmente).

Me parece que vc tá confundindo getters, setters, modificadores de acesso e coisas do tipo com encapsulamento. Por isto a confusão em relação a linguagens.

Um modificador de acesso (público, privado, protegido) é uma construção interessante, mas você pode pensar em encapsulamento sem estes modificadores. Os getters e setters, idem.

Em python, quando se quer definir um atributo ou método privado, normalmente utilizamos um __ na frente. Ele não é privado de verdade, é uma convenção, e isto faz parte da filosofia da linguagem. Se você acessar o objeto, sabe que pode estar fazendo algo que o autor do componente não sugeriu que fosse feito. Talvez pelo fato de Python suportar properties, não seja comum o uso de getters e setters. Você pode definir restrições por meio de properties, embora eu tenha visto isto pouco.

Perceba que o exemplo que eu dei para você, do objeto carro, não depende de modificador de acesso (público ou privado), não depende de getter & setter e não depende de linguagem. Encapsulamento é um conceito do paradigma, estamos falando de orientação a objetos. O ponto é você criar um objeto carro e não permitir que os objetos externos alterem o estado do carro a torto ou a direito, e sim utilizem a interface definida pelo encapsulamento.

eu ja acho que é parte fundamental no encapsulamento,

ou talves eu tenha entendido o conceito de forma errada.

eu ja acho que é parte fundamental no encapsulamento,

ou talves eu tenha entendido o conceito de forma errada.

Python é uma linguagem que suporta o paradigma OO e não tem modificadores de acesso. Em alguma versões (acho que nas primeiras não) ele suporta properties, mas grande parte dos programadores Python simplesmente deixa tudo público e usa o caracter ‘_’ nos atributos privados.

O que garante o encapsulamento não é o modificador de acesso, até pq em Java nós podemos burlar ele por meio de Reflection. Quem garante o encapsulamento são os desenvolvedores. O developer A cria um componente com objetos bem projetados e pensa em encapsulamento. Ele entende que alguns métodos e atributos da sua classe devem ser públicos, outros não. Se ele codificar isto em Java, ele usa os modificadores de acesso. É a maneira Java de resolver o problema. Se ele fizer em python, provavelmente vai utilizar ‘_’ na frente do nome do atributo que ele quer que seja ‘privado’. Cabe ao developer B, que usa os componentes do A, manter o padrão e não tentar burlar o mecanismo de modificadores (Java) ou fazer acessos diretos a objetos que começam com _ (Python).

Em várias versões do Javascript, que suporta OO por meio de protótipos, também não há modificadores de acesso. Normalmente se usa closures para simular este efeito, entretanto alguns desenvolvedores também adotam a convenção do ‘_’.

O encapsulamento pode ser garantido mesmo sem estas convenções, basta que se use documentações explicitando o que deve ou não ser usado. Mas claro que recursos e convenções auxiliam bastante neste aspecto.

Hmm então o objeto Carro encapsulado não utizilaria de um outro objeto para mudar sua velocidade(setVelocidade) ele mesmo mudaria através do carro.acelerar()
Seria isso?

já to entendendo melhor, é que estou começando a aprender sobre orientação a objetos também, e sempre lia sobre esse Encapsulamento, achei que era algo mais amedrontador doque realmente é

Ainda falta Polimorfismo e Herança
ohh boy

ate os nomes são complicados :twisted:

Kazdum:

Hmm então o objeto Carro encapsulado não utizilaria de um outro objeto para mudar sua velocidade(setVelocidade) ele mesmo mudaria através do carro.acelerar()
Seria isso?

já to entendendo melhor, é que estou começando a aprender sobre orientação a objetos também, e sempre lia sobre esse Encapsulamento, achei que era algo mais amedrontador doque realmente é

Ainda falta Polimorfismo e Herança
ohh boy

ate os nomes são complicados :twisted:

Sim, este é um pequeno exemplo, claro que isto depende do sistema.

O importante é sempre lembrar que objetos interagem entre si, e se um objeto for muito dependente do outro, você cria um código macarrônico. O objeto A altera o estado de B diretamente, ou seja, ele sabe como B funciona. Se precisar mudar B, certamente precisará mudar A. O encapsulamento reduz este tipo de problema.