Primeiro Projeto PHP Orientado a Objeto.

[Enrico Pereira 299]

Classes abstratas podem sim ter estado, mas classes não tem estado (não deveriam, não quero mais entrar no mérito dos estáticos) e sim objetos, apenas classes concretas podem ser instanciadas. Interfaces, traits e classes abstratas não podem ser instanciada.

 

Interface: um tipo que pode definir métodos obrigatórios, com parâmetros para cada um. Classes implementam elas, podem implementar múltiplas interfaces e uma interface pode estender interfaces. Mas nunca interfaces podem ter comportamento. Exemplo prático:

 

<?php

interface ConfigReaderInterface
{
    public function read($fileName);
}

class IniReader implements ConfigReaderInterface
{
    public function read($fileName)
    {
        return parse_ini_file($fileName);
    }
}

class JsonReader implements ConfigReaderInterface
{
    public function read($fileName)
    {
        return json_decode(file_get_contents($fileName));
    }
}

 

Veja, eu posso ter vários tipos de configuração, mas para que raios eu criei uma interface? Bem, nós necessitaremos de um contrato, pois precisaremos de ter certeza que exista o método read, que recebe um argumento, que seria um path. Vejamos o implementador:

 

 

class ConfigLoader
{
    protected $configs = [];

    public function loadFile($file, ConfigReader $reader)
    {
        $this->configs = array_replace_recursive($reader->read($file), $this->configs);
    }

    public function getConfigs()
    {
        return $this->configs;
    }
}

// Para implementar

$json = new JsonReader;
$ini  = new IniReader;

$parser = new ConfigLoader;
$parser->loadFile(__DIR__ . '/configs.ini', $ini);
$parser->loadFile(__DIR__ . '/configs.json', $json);

// Recuperando a configuração

$configs = $parser->getConfigs();

 

 

Agora nós flexibilizamos e desacoplamos o comportamento e as possibilidades. No parser, no método, loadFile eu tenho certeza que o 2 argumento terá que ser derivado de ConfigReader, logo sei que terá o método read com o $fileName como argumento, e essa é base da orientação a objetos, o relacionamento de objetos e a confiança.

 

Classes abstratas: classes não instanciáveis, servem como base para classes através de herança. Mas lembre-se, isso é quando você possui código duplicado em participantes comuns.

 

É inevitável que entramos em tipos de relacionamentos nessa altura do campeonato:

 

Herança: é um

Traits: comporta-se como um

Associação/Composição/Agregação: tem um

 

---

Associação:

- uma relação não dependente em ambas as partes

- ex: um zoológico possui animais, mas se um animal sair do zoológico, o zoológico não fecha, nem o animal morre, isso é ima associação

 

Composição:

- dependência total, sem essa dependência não funciona

- ex: homem não funciona sem cérebro, pois necessita dele, sem ele morre, e o cérebro necessita do homem, isso é uma composição

 

Agregação:

- dependência de uma das partes

- ex: carro não funciona sem roda, pois necessita dele, sem ele não anda, mas a roda pode ser usada para outros fins, isso é uma agregação

 

Logo, temos um exemplo clássico. Um usuário não pode estender um banco de dados, pois ele não é um, e nem comporta-se como, ele tem um, logo isto seria um relacionamento, neste caso agregação, pois o usuário dependerá do banco de dados, mas o banco de dados não dependerá do usuário.

 

Outro exemplo é um pessoa, que acabou de ficar bêbada, ela nunca fez isso, logo não é bêbada, não pode estender "Bebado", não tem um bêbado, mas comporta-se como um, logo a utilização seria trait. Mas são raros os casos disso, não me preocuparia com esse tipo neste momento.

 

E por fim, temos a herança, temos uma classe chamada Loja (seria abstrata, geralmente classes mães são abstratas), e temos LojasAmericanas, RicardoEletro, PontoFrio e outros estendendo Loja, pois elas são lojas.

 

Atenção: existe uma grande exceção, a clássica do retângulo e quadrado, veja: http://cafe.elharo.com/programming/a-square-is-not-a-rectangle/ (é java mas é OO também, da mesma forma).

 

Para saber mais sobre isso, veja o princípio da substituição de Barbara Liskov: http://pt.wikipedia.org/wiki/Princ%C3%ADpio_da_substitui%C3%A7%C3%A3o_de_Liskov

 

No final, sei que estendi muito sobre o assunto, mas acho que foi necessário, estou vendo pelos últimos tópicos que os problemas estão rodando em torno disto.

[Rodolfo TI 6]

Poutz, não sei nem como agradecer tanta boa vontade e empenho da parte de vocês, acredito eu , que somente me empenhando e aprendendo ao máximo para que possa lá na frente ajudar outras pessoas.

 

Sobre a classe turma e formação, estava pensando melhor, deixar somente a classe formação pode ser a melhor solução pois ali posso ter todas as informações referentes a uma formação.

 

Atributos como:

 

 

public class formacao{
fun_id // para saber o funcionário)
for_dataInicio
for_dataFim
for_cargaHoraria
for_nome
for_ementa
}

 

ainda é uma mera suposição, ainda estou lendo com atenção os ultimos 4 ou 5 posts, tentando ler e entender.

 

Mais uma vez obrigado.

 

Acredito que muitos itens discutidos nesse tópico merecem ser fixados, é uma ótima introdução.

 

@off|Topic: O curso de php é MUITO BOM, recomendo demais pra quem ta começando.

[Matheus Lucca Carmo 13]

Tava fora do fórum por falta de tempo , mas que bom que criaram esta discussão , vai me ajudar muito ! Estou acompanhando

[Enrico Pereira 299]

Bem, algo que me ajudou muito e vai ajudar voc é S.O.L.I.D., 5 princípios conhecidos de programação orientada a objetos, um bom código OO segue eles (99,99% para não generalizar) e também auxilia você a pensar como criar suas classes/interfaces.

 

SRP - Single responsibility principle

OCP - Open/closed principle

LSP - Liskov substitution principle

ISP - Interface segregation principle

DIP - Dependency inversion principle

 

Sim, eles são teóricos e complicados para entender, mas irão tornar seu código melhor e ajudar a pensar em seus diagramas. Existe muito material sobre eles, infelizmente pouquíssimos em PHP, mas como digo, OO é OO, independente de linguagem.

[matthee 3]

Velho se vc não estiver com muita pressa recomendo que leia o livro PHP Programando com Orientação a Objetos, esse livro além de te mostrar os conceitos, ele te mostra patterns para cada parte da aplicação, sendo ela na parte de acesso a dados ou da lógica de negocios, além das views é claro. O grande ponto desse livro é que além de ele te mostrar tudo isso, ele te da exemplos que você pode utilizar em uma aplicação por um bom período de tempo como uma mini API de manipulaçao SQL, acredito que vou utiliza-la por um bom tempo.

[Rodolfo TI 6]

Bem, algo que me ajudou muito e vai ajudar voc é S.O.L.I.D., 5 princípios conhecidos de programação orientada a objetos, um bom código OO segue eles (99,99% para não generalizar) e também auxilia você a pensar como criar suas classes/interfaces.

 

SRP - Single responsibility principle

OCP - Open/closed principle

LSP - Liskov substitution principle

ISP - Interface segregation principle

DIP - Dependency inversion principle

 

Sim, eles são teóricos e complicados para entender, mas irão tornar seu código melhor e ajudar a pensar em seus diagramas. Existe muito material sobre eles, infelizmente pouquíssimos em PHP, mas como digo, OO é OO, independente de linguagem.

 

É preciso mesmo consolidar esses conceitos, ainda me falta um pouco de tempo, mas vou ler com muita atenção, gosta de alguma literatura em especial a respeito desses conceitos ?

 

Velho se vc não estiver com muita pressa recomendo que leia o livro PHP Programando com Orientação a Objetos, esse livro além de te mostrar os conceitos, ele te mostra patterns para cada parte da aplicação, sendo ela na parte de acesso a dados ou da lógica de negocios, além das views é claro. O grande ponto desse livro é que além de ele te mostrar tudo isso, ele te da exemplos que você pode utilizar em uma aplicação por um bom período de tempo como uma mini API de manipulaçao SQL, acredito que vou utiliza-la por um bom tempo.

 

Vou verificar, já viu ele com bons preços em algum lugar ?

[matthee 3]

Eu estou lendo o ebook de graça velho, se quiser posto em algum lugar e te mando o link, só tem uma coisa que tem que prestar atenção quando ele começa descrever alguns padrões, a maioria deles funciona com muito pouco código é até bonito de ver, mas esses seriam usados para sistemas pequenos que não tem nenhuma possibilidade futura de implementação.

[Henrique Barcelos 290]

O tópico virou praticamente um hangout de orientação a objetos.

[Enrico Pereira 299]

O tópico virou praticamente um hangout de orientação a objetos.

 

Orientação a objetos é teórico, existe 1001 firulas a se explorar e comentar. Não é prático como mostrar hello world na tela, por isso os "pró-produtivos (sobrinhos/preguiçosos/chefes)" criticam.

[matthee 3]

HAHAHAHA, cara sério eu tento usar a frase do Einsten quando tem que pensar em OO, "Faça as coisas mais simples que você puder, porem não as mais simples", e também simplificar e implementar, herança só em casos típicos tipo conta corrente extends conta.

[Enrico Pereira 299]

Semântica > Simplicidade

[Rodolfo TI 6]

Semântica > Simplicidade

 

Gostei dessa citação.

 

A galera to agarrado, quero muito fazer o projeto rápido mas.... Minhas disciplians tão cada vez me segundo mais, pra quem fez algum curso relacionado a sistemas sabe do que to falando Estrutura de Dados... Matemática "DISCRETA" ... enfim

 

 

Falando da simplicidade alguns de nossos amigos falaram sobre a utilzação da classe turma...

 

 

A referencia que eles fazem é que seria melhor usar ou turma ou formação para armazenar o grupo de usuários que realiza uma formação por que idéia de quando criei a classe turma , seria poder ter uma tela que me informasse a formação e seus membros.

 

 

To trabalho no DER, acho que vai me ajudar também..

 

Desculpem a lentidão espero que entendam.

 

 

Devagar se vai ao longe, assim espero. RS.. Não tão devagar né ?

[shini 318]

sobre a turma, pense como a secretaria organiza os alunos nas formções.

[Rodolfo TI 6]

sobre a turma, pense como a secretaria organiza os alunos nas formções.

 

Com esse post me fez repensar um pouco os requisitos desse sistema.

 

Os usuários irão se cadastrar, menos um método ao gerente, toda vez que os requisitos mudarem, as análises das interfaces mudam ?

 

é normal nos primeiros projetos ter dificuldade em alinhar os requisitos a metodologia de desenvolvimento ?

 

Queria dar um gás maior nesse projeto, sábado pretendo fazer uma conferencia no skype e desenvolver em paralelo, se alguem quiser participar manda mp aí que agente combina.

[Evandro Oliveira 331]

é normal nos primeiros projetos ter dificuldade em alinhar os requisitos a metodologia de desenvolvimento ?

Nos primeiros, nos segundos nos terceiros...

Os usuários irão se cadastrar, menos um método ao gerente, toda vez que os requisitos mudarem, as análises das interfaces mudam ?

Desde que se siga o princípio de responsabilidade única, não.

 

Mas, veja que a alteração foi no comportamento do sistema. Antes você precisava, fisicamente, contratar um gerente. Este cadastraria os usuários. Agora não. Enquanto você faz a entrevista para contratar um gerente, os usuários já podem ir se cadastrando.

 

Você fisicamente removeu uma atribuição (responsabilidade) do gerente e a repassou ao usuário.

 

Como eu havia citado há alguns posts atrás, isso pode ser resolvido com um sistema de permissões/papéis.

 

Isso sim causaria uma enorme alteração na interface. Você teria apenas uma entidade (Operador) que implementaria diversas interfaces (cadastrar usuário, cadastrar turma, cadastrar formação, ...). Com base nas permissões de cada operador, a chamada dos métodos de ação retornariam sucesso ou falha.

[Rodolfo TI 6]

 

 

Mas, veja que a alteração foi no comportamento do sistema. Antes você precisava, fisicamente, contratar um gerente. Este cadastraria os usuários. Agora não. Enquanto você faz a entrevista para contratar um gerente, os usuários já podem ir se cadastrando.

 

 

Sim, agora o sistem funcionara da seguinte forma, os usuários irão se cadastra, o administrador do sistema irá definir quem são os gerentes, e estes poderão modificar os usuários, vou fazer o ER, isso mesmo do banco de dados que acho que ajuda a entender um pouco, existe alguma restrição no processo em desenvolver o banco antes de desenvolver o sistema em si.

[Evandro Oliveira 331]

existe alguma restrição no processo em desenvolver o banco antes de desenvolver o sistema em si.

Nenhuma. Em termos de agilidade, é recomendável que seja feito em paralelo. Mas é possível fazer qualquer um antes do outro.