POO sobre:private, protected, abstract, static e interfaces

[Israel Elias 8]

To começando a estudar POO em PHP, e to com dúvidas sobre:

1) Atributos:(private, protected e static), quando e o por que de eu usar??

2) Métodos: (abstract, static), quando e o por que de eu usar??

3) Class: (interfaces, abstract), quando e o por que de eu usar??

Eu sei como declarar, mas não entra na minha cabeça de quando e o por que de usar (private, protected, abstract, static e interfaces) em atributos, métodos e class??

Me ajudem ae pessoal

[Enrico Pereira 299]

Public, protected e abstract são formas de visibilidade para atributos e métodos:

public = acessível através do objeto, da classe que definiu e das classes que herdam a classe que definiu

protected = acessível através da classe que definiu e das classes que herdam a classe que definiu

private = acessível somente para a classe que definiu

 

Interfaces são contratos: http://php.net/manual/en/language.oop5.interfaces.php

Classes abstratas são classes que não podem ser instanciadas, são bases para outras classes que a herdarão. Métodos abstratos são métodos de classes abstratas sem nenhum comportamento.

 

Atributos estáticos são atributos que são atributos da classe, que não dependem de um objeto, ou seja, tornam o estado global e não do objeto (cuidado c/ eles).

Métodos estáticos são métodos que fazem parte da classe e não de um objeto. Geralmente são métodos de criação de objetos ou funções (usa-se nesse caso devido à ausência de autoloading para funções).

 

Mas você precisa entender OO como um todo, leia o manual do PHP e talvez este artigo possa clarear um pouco: http://net.tutsplus.com/tutorials/php/oop-in-php/

[cristianoolv 93]

Vá um passo de cada vez, esqueça as classes abstratas e interface, começa entendendo as questões de visibilidade...

[Israel Elias 8]

Vlw pela atenção ae pessoal, mas a minha dúvida não é como funciona (protected, private, static , abstract e outros ...), por que eu já sei o que eles fazem!

 

A minha dúvida seria de como usá-las no sistema, tipo por que proteger com protected um método ou atributo, por que fazer uma class ser abstract e assim vai??

[Evandro Oliveira 331]

tudo que não seja público e concreto é alheio à implementação e isso é uma coisa boa.

 

Uma vez que o concetio de orientação a objetos remete à reusabilidade, a sua modelagem deve definir como os objetos interagem entre si e não como eles são escritos/desenvolvidos.

 

Isso significa que uma modelagem OO descreve que uma porta pode receber uma tranca que usa uma chave para permitir ou inibir a abertura da porta. Veja que não descrevi e - neste momento - não nos interessa se a porta é de madeira ou de aço, se a chave é de bronze ou de ouro e qual o algoritmo de segredo que a fechadura está utilizando. Este tipo de detalhamento remete à implementação e particular de cada caso. Quem atende aos diversos casos independente da aplicação é a modelagem.

 

Começando pelo nível mais alto e abstrato da modelagem, temos as Interfaces. Em PHP, interfaces apenas descrevem métodos. Algumas outras liguagens ainda permitem que haja implementação nas interfaces mesmo que esta prática seja fortemente desencorajada.

 

Quando você confia numa interface, você sabe o que esperar de uma instância. Quando você pretende utilizar qualquer artefato elétrico, você procura ou o plugue de conectar a uma tomada, ou o compartimento de pilhas.

 

Partindo da modelagem indo em direção à implementação, temos as classes/métodos abstratos.

 

Métodos abstratos são métodos de interface dentro de classes abstratas. Ponto.

Classes abstratas servem para fazer o "meio de campo" entre as interfaces e suas implementações. Ao contrário do que geralmente ocorre quando não se tem muito domínio de OO, classes abstratas não servem para se antecipar às implementações. Muito pelo contrário, servem para definir uma implementação que sirva como última alternativa.

 

Atributos privados servem para garantir a integridade do estado da instância. Quando você inibe que uma propriedade seja modificada "de qualquer maneira", você garante a integridade do estado.

[Israel Elias 8]

Vlw Evandro Oliveira

 

Li a sua resposta, e deu pra entender um pouco do conceito

[Vinicius Rangel 208]

tipo por que proteger com protected um método ou atributo

Acho que esse ponto é mais conceitual do que outra coisa, o certo é apenas o proprio objeto mudar características ou comportamentos dele mesmo, então a visibilidade só vai garantir que ninguém a não ser o proprio objeto e seus herdeiros (dependendo de qual visibilidade foi usada) possam fazer tais alterações.

 

 

por que fazer uma class ser abstract

Esse já é o mais alto nível, a parte complicada e complexa então não vai adiantar muito um texto conceituando um monte de coisa por que você vai se perder e também o Evandro já explicou muito bem apesar de que achei muito técnico para uma explicação para alguém que esta aprendendo,

 

Primeiro entenda o que é o OO antes de codar, o exemplo da Porta/Chave tem ilustrado com o código aqui no fórum para você pegar o conceito de interface mas nada disso vale se vc não pegar o básico, até por que abstrações são tensas.

[William Bruno 1501]

Vou explicar da forma que eu entendi quando estava estudando pela primeira vez.

 

O que é Orientação a Objetos ?

Programar orientado a objetos é "fazer um objeto usar o outro", sem precisar conhecer ou saber como ele faz tal coisa. A única coisa que ele sabe, é que dada uma entrada, espera-se uma saída.

 

Fazemos isso o tempo todo, por exemplo, não sabemos como o rand() funciona, mas sabemos que ele vai nos devolver um número "aleatório", e isso basta. A complexidade para gerar isso, não nos interessa.

 

Para mim, OO foi criado não apenas para "reusabilidade", pois isso sempre existiu, em diversos outros paradigmas. OO foi criado para que programadores diferentes que não se conhecem possam trabalhar juntos, sem afetar gravemente o trabalho do outro.

 

Quando vc projeta uma Classe, vc define a forma com que os outros programadores vão usá-la, e cabe a você declarar ela de maneira que os outros usem corretamente (pense que eles não tem acesso ao seu código, apenas a interface de uso dela).

 

 

Quando usar public, protected ou private ?

Use public quando outro objeto B precisar usar um método do objeto A.

Essa é a interface de uso, o que vc expõe ao mundo. O que os outros objetos vão conhecer sobre o objeto A.

 

Use protected quando você for usar herança, e os filhos precisem alterar ou invocar algum método da superclasse. Só isso. Não tem nada demais começar com um método private, e depois perceber que vc vai ter que usar herança, e depois mudar de private para protected, isso é normal. (desde que o poliformismo faça sentido aqui)

 

Use private quando você tiver um método ou propriedade que não faz sentido ser acessada por ninguém mais que o próprio objeto que a declarou. Por exemplo, um objeto GarrafaTermica, a propriedade temperatura é um estado desse objeto, e ninguém pode alterar isso sem passar pelas validações dela, logo, temperatura é private.

 

Assim como num DAO, ninguém mais fora o próprio DAO precisa saber como conseguir os dados, então o método "getData()" é private do DAO, mas os métodos: "listUsers()" ou "listUsersByCPF()" são públicos, pois outros objetos da aplicação vão usar isso, sem saber como o DAO conseguiu os dados, pois não interessa a eles. O que interessa é o dado já listado e separado de acordo com o que eles queriam.

 

Existem até autores que recomendam que vc comece codando tudo como private, e depois ir liberando conforme precisar.

 

Não se atentem a implementação que sugeri, sei que não é a única nem a melhor forma de fazer, apenas quis expor o conceito com algo "mais real" do que Feijoada e Animais.

 

Quando usar interfaces ?

Você vai usar esses caras quando dado um conjunto de objetos, com comportamentos semelhantes, vc for padronizar a maneira como eles serão usados.

Lembra que falei que OO foi criado para programadores que não se conhecem, nem se conversam, e nem tem acesso ao código um dos outros poderem trabalhar juntos(no pior caso) ?

Então, quando vc definir numa interface alguma coisa, o próximo objeto daquele tipo, vai ser obrigado a implementar a mesma forma de uso, para não quebrar e não despadronizar a aplicação.

 

Sobre interfaces, leia:

http://wbruno.com.br/php/afinal-e-interface-oop/

 

Quando usar abstract ?

De maneira bem grossa, qndo vc tiver uma interface de uso em que todos os objetos da cascata possuirão um mesmo comportamento, como não podemos implementar nada na interface, implementamos na abstrata e os outros herdão diretamente dela.

Cuidado aqui, muito cuidado. É altamente recomendado (na maioria dos casos) que vc use composição, e separe esse comportamento em outra classe menor utilitária, do que sair herdando tudo por ai, sem controle.

 

Todos gostam de explicar herança, mas ninguém fala que não é a bala de prata. Use com cautela.

Eu por exemplo, usei herança aqui, pois fazia muito sentido: [class Statusblog extends WordPress]

http://wbruno.com.br/php/exemplo-pratico-de-orientacao-objetos-php-diferencas-vantagens-em-relacao-a-um-codigo-estruturado/

[Israel Elias 8]

Li todos os post e tive o seguinte aprendizado sobre abstract

criei um script voltado sobre abstract veja abaixo:

 

corrijam me se estiver errado!

 

<?php
// class abstract contendo ações de uma pessoa
abstract class acoes{
    abstract public function Atacar();
	abstract public function Defender();
	abstract public function Correr();
}
// class pessoa que extende acoes, essa class define atributos e comportamento de uma pessoa
class pessoa extends acoes{
    private $nome,$idade;
	public function __construct($st_nome = null,$st_idade = null){
	    if(!is_null($st_nome))
		    $this->nome = $st_nome;
			
	    if(!is_null($st_idade))
		    $this->idade = $st_idade;			
	}
	public function getDadosPessoa(){
	    $apresentarPerfil = "-=-=-=-=-=-( Perfil )=-=-=-=-=-=-=-<br />";
		$apresentarPerfil .= "<b>Nome:</b> ".$this->nome."<br />";
		$apresentarPerfil .= "<b>Idade:</b> ".$this->idade."<br />";
		$apresentarPerfil .= "-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=<br />"; 
		echo $apresentarPerfil;
	}
	public function Atacar(){
	    echo "<b>Acao:</b> aahh toma um soco<br />";
	}
	public function Defender(){
	    echo "<b>Acao:</b> escudo de plata ativado<br />";
	}
	public function Correr(){
	    echo "<b>Acao:</b> Vou correr o mais rapido possivel ... ahh canseii<br />";
	}
}
//instanciada a class pessoa
$o_israel = new pessoa("Israel",24);
$o_israel->getDadosPessoa();
$o_israel->Atacar();
$o_israel->Defender();
$o_israel->Correr();

[Evandro Oliveira 331]

 

 

<?php
// class abstract contendo ações de uma pessoa
abstract class acoes{
    abstract public function Atacar();
	abstract public function Defender();
	abstract public function Correr();
}

 

 

Errado. Isso é uma interface. Se você só descreve métodos sem nenhuma implementação, você não precisa de uma classe abstrata.

// class pessoa que extende acoes, essa class define atributos e comportamento de uma pessoa

class pessoa extends acoes{

Errado. Parei aqui e me recuso a comentar o resto. Herança é algo que passa de pai para filho, dentro de uma mesma linhagem. Uma [inline]pessoa[/inline] não é da linhagem de [inline]acoes[/inline].

[cristianoolv 93]

Procure usar um padrão de nomeclatura igual o java e escreva em ingles, vai evitar ter nomes tipo acoes...

Quanto a classes abstratas são bem uteis para refatoração de codigo, no seu caso ela não faz sentido nenhum, e ainda cria um problema que o camarada de cima citou....

 

<?php

    interface Actions{
        public function run();
        public function attack();
        public function defend();
    }

    class Person implements Actions{

        private $name;
        private $age;

        public function __construct($name,$age) {
            $this->name = $name;
            $this->age = $age;
        }

        public function toString(){
            return "Nome: $this->name <br> Idade: $this->age anos";
        }

        public function run(){
            return "Correndo...";
        }

        public function attack(){
            return "Atacando....";
        }

        public function defend(){
            return "defendendo....";
        }


    }

Veja o codigo mais limpinho sem acoes ou aberrações do tipo...

[Israel Elias 8]

Vlw pessoal pela força ae, é errando que se aprende rs ..

 

* Pelo que eu entendi classes abstratas deve seguir uma mesma linhagem de herança tipo: a class laranja herda a class fruta -> (uma classe abstrata)

* E dentro o que falou o Evandro Oliveira as classes abstratas são como as interfaces só que com implementações, é isso??

classes abstratas não servem para se antecipar às implementações. Muito pelo contrário, 
servem para definir uma implementação que sirva como última alternativa.

* Nesse trecho o Evandro Oliveira fala que implementações das classes abstratas são de última alternativa?? me de um exemplo simples e claro sobre essa última alternativa

[Evandro Oliveira 331]

* Pelo que eu entendi classes abstratas deve seguir uma mesma linhagem de herança tipo: a class laranja herda a class fruta -> (uma classe abstrata)

Grande garoto! Agora sim.

 

* E dentro o que falou o Evandro Oliveira as classes abstratas são como as interfaces só que com implementações, é isso??

Não são como. Cada uma tem seu lugar cativo e sua função. Algumas linguagens permitem implementação dentro das interfaces. E aí? Tanto faz? Interfaces garantem polimorfismo. Classes abstratas garantem linhagem, uma vez que confiam na herança.

* Nesse trecho o Evandro Oliveira fala que implementações das classes abstratas são de última alternativa?? me de um exemplo simples e claro sobre essa última alternativa

abstract class minhaClasseAbstrata
{
    public function meuMetodoSuperImportante()
    {
        echo "Alguém esqueceu de implementar isso aqui. Mas - pra não dar erro - estou fazendo esta mensagem ser impressa.";
    }
}

Um exemplo um pouco menos ordinário:

interface Basket
{
    public function add ($item);
    public function remove ($item);
}

abstract class BasketballBasket implements Basket
{
    final public function remove($item)
    {
        throw new BadMethodCallException(
            "Basketball baskets doesnot hold items!"
        );
    }

retirado daqui

[Israel Elias 8]

To começando a enxerga esse trem interface e absctract, finalmente :)

 

Já vi muitos exemplo na net onde e feito uma class abstract para a conexão com banco de dados.

Nesse caso aonde vem aquela questão de mesma linhagem de herança para a class filhas que extenderem a class conexão??

Tipo se eu tenho um objeto contatoModel qual é a linhagem de herança sobre a class abstrata conexão??

vejo isso como uma necessidade da class contatoModel sobre a classe conexão, e não como uma herança passada de pai para filho!

[Vinicius Rangel 208]

 

Tipo se eu tenho um objeto contatoModel qual é a linhagem de herança sobre a class abstrata conexão??

vejo isso como uma necessidade da class contatoModel sobre a classe conexão, e não como uma herança passada de pai para filho!

contatoModel é DB?

Não, ninguém é um banco de dados.. (nesse caso)

Ela usa DB, só por que ela usa não significa que elas devem ter relação.

[Enrico Pereira 299]

Quando você escreve este código:

 

class ContatoModel extends Database {}

 

Você está na verdade falando:

um ContatoModel é um Database

 

Mas na verdade, o que você quer é:

class ContatoModel {
    private $db;

    public function __construct(Database $db) {
        $this->db = $db;
    }
}

 

Que significa:

 

um ContatoModel precisa de um Database

[Israel Elias 8]

@Vinicius Rangel

essa pagina contatoModel serve para a modelagem de dados, to usando o critério do MVC(model, View e Controller)

 

@Enrico Pereira

Vlw entendi agora, mas lembrando que fiz essa pergunta por que já vi outras pessoas fazendo dessa maneira como descrevi la em cima e fiquei na dúvida se e certo ou errado

[Vinicius Rangel 208]

essa pagina contatoModel serve para a modelagem de dados, to usando o critério do MVC(model, View e Controller)

Eu disse a mesma coisa que o enrico, de uma forma diferente e sem exemplos, logo não entendi o que vc disse ai..

[Israel Elias 8]

A pagina contatoModel ficaria todo o processo de validação, de puxar na 'tabela' BD contatos. Resumindo todo processo de informação que depois e passado para a pagina contatosView

[Enrico Pereira 299]

essa pagina contatoModel serve para a modelagem de dados, to usando o critério do MVC(model, View e Controller)

 

o M, o V e o C são tiers, que têm layers.

 

Model é a tier mais importante de uma aplicação, que é dividida em persistência, lógica, filtro, validação, etc.

Não crie uma classe "model" para tratar todas essas preocupações porque fazendo isso, você está criando uma "godclass", que viola um dos princípios básicos da orientação a objetos: o princípio da responsabilidade única.

 

Os controllers só vão chamar a model e enviar a view, sem ter lógica envolvida. A view, seria a camada de exibição, que não deve ter muita lógica envolvida (a lógica é na parte da model).

 

Há 5 princípios da orientação a objetos, conhecidos pelo acrônimo S.O.L.I.D.: SRP, OCP, LSP, ISP e DIP.

Existe bastante material disponível sobre isso, sugiro a pesquisa.

 

Além de tudo, separe as preocupações. Você está apenas modelando a persistência e as validações, ESQUEÇA o controller, ESQUEÇA a view. A grande vantagem da orientação a objetos é a abstração.

 

E frisando, model não significa uma classe só, nem o controller; a view também não significa apenas um arquivo html. Ao invés de focar em M, V e C, foque-se em separação de preocupações (SoC).