Primeiro Projeto PHP Orientado a Objeto.

[angelorubin 142]

Para ser uma classe basta ter isso:

class NomeClasse{
}

Sim, o que você citou pode ser considerada uma classe (sem propósito, mas uma classe).

[Enrico Pereira 299]

Programe para interfaces, não para implementações, é o segredo! Uma boa OO depende de semântica de verbo.

[Rodolfo TI 6]

Programe para interfaces, não para implementações, é o segredo! Uma boa OO depende de semântica de verbo.

Pode comentar um pouco mais sobre isso ?

 

Vi os conceitos de SOLID achei interessante e esses também devem ser, vou dar uma pesquisada mas se tive rmaterial posta aí ?

 

Antes de continuar com o diagrama de classes pensei em fazer um caso de uso ? seria melhor para continuar definindo as classes ?

 

Criei o projeto no github mas não consigo instalar o software deles.

[Stratocaster 85 10]

Enrico, concordo 100% contigo... A flexibilidade é gigante.

 

Mas como eu disse e vejo muitos aqui não compreendem algumas questões por causa da fraca tipagem do PHP.

 

Seria interessante você explicar melhor o uso das interfaces.

[Vinicius Rangel 208]

Programe para interfaces, não para implementações, é o segredo! Uma boa OO depende de semântica de verbo.

Isso vem do ensinamento do grande mestre Neto.

 

a interface bem programada permite a você nunca mais ter que editar aquele code mesmo querendo adicionar novas funcionalidades a ferramenta, alguns chamam isso de código perfeito.

 

Um exemplo básico que passam bastante.

Veiculo seria uma interface.

 

e Teria os métodos básicos de andar, parar etc..

e caso você queria um veiculo do tipo carro você criaria um novo objeto carro.

E todo objeto do tipo veiculo seria amarrado a essa interface e sempre que for precisar de um veiculo em qualquer lugar você não vai chamar o carro e a moto você vai chamar um veiculo pois é o que o sistema precisa.

A principio o sistema não precisa saber qual veiculo ele quer.

 

esse é a ideia de uma interface.

[Enrico Pereira 299]

Pode comentar um pouco mais sobre isso ?

 

Vi os conceitos de SOLID achei interessante e esses também devem ser, vou dar uma pesquisada mas se tive rmaterial posta aí ?

 

Antes de continuar com o diagrama de classes pensei em fazer um caso de uso ? seria melhor para continuar definindo as classes ?

 

Criei o projeto no github mas não consigo instalar o software deles.

 

Você não precisa do software deles, vc precisa de git, github é apenas um servidor de GIT, sistema de controle de distribuído. Git não é complicado, mas vc só aprende na prática.

 

SOLID são 5 princípios, não muito difíceis de entender. Grande mestre Neto tem hangouts que falam sobre isso, além de posts. Procure no fórum.

[Vinicius Rangel 208]

@offtopic

 

 

 

Grande mestre Neto

O hangout do cara é animal.

[Rodolfo TI 6]

Você não precisa do software deles, vc precisa de git, github é apenas um servidor de GIT, sistema de controle de distribuído. Git não é complicado, mas vc só aprende na prática.

 

SOLID são 5 princípios, não muito difíceis de entender. Grande mestre Neto tem hangouts que falam sobre isso, além de posts. Procure no fórum.

 

Ok, o farei, não tenho postado por falta de tempo ,vo trabalhar na interface, enquanto isso estou tendo problemas com o github, instalar configurar e tal, mas já estou de olho nos tutoriais, só se não conseguir mesmo peço um help.

 

@Edit: Descobri o problema com o github, a conexão com a internet onde trabalho utiliza proxy, acredito que por este motivão não consigo conectar ao servidor.

 

ao digitar os comandos:

 

 

ssh git@github.com

ou

 

git -T git@github.com

 

retorna um erro

 

ssh github.com no address associated with name

 

Estou pesquisando pra ver se encontro alguma solução e se realmente esse é o problema.

 

 

Obrigado mais uma vez.

[Evandro Oliveira 331]

Entendi, estou lendo e re-lendo tudo que disse para maior compreensão, quando comentar começar pelo começo seria não ir direto ao diagrama de classes? começar por outro ponto,? se sim qual ?

Você começa definindo o que você quer

Eu quero gerenciar formações e quais funcionários passam por elas

 

Depois, você define como você quer

Um gerente cadastra funcionários, instrutores, formações e turmas

Instrutores podem ministrar formações para as turmas

Funcionários/Participantes devem confirmar/cancelar a participação na turma

 

Veja que, se você transformar isso num desenho, você já está de frente para um caso de uso.

 

Quando perguntei se classes para ser classes rsrsrs..

 

Queria dizer o seguinte, se uma classe tem apenas métodos e nenhum atributo é uma definição correta isso pode existir ?

Pode existir: Sim.

É uma definição correta: Até onde eu sei, não.

 

Veja

<?php
 
class Classe
{
    public function metodo1 ()
    {}
 
    public function metodo2 ()
    {}
}
 
$instancia1 = new Classe;
$instancia2 = new Classe;
 
var_dump($instancia1->metodo1());
var_dump($instancia1->metodo2());
var_dump($instancia2->metodo1());
var_dump($instancia2->metodo2());

 

Em momento algum [inline]$instancia1[/inline] e [inline]$instancia2[/inline] produzem resultados diferentes. Se elas não produzem resultados diferentes, eu não vejo motivo para que sejam instâncias diferentes. Se não precisamos de instâncias, podemos nos utilizar dos métodos estáticos

 

class Classe
{
    public static metodo1()
    {}
 
    public static metodo2()
    {}
}
 
var_dump(Classe::metodo1());
var_dump(Classe::metodo2());

 

Pelo conceito, ainda há alguma coisa errada, uma vez que classes existem para ser instanciadas. Mas existem alguns raros casos onde é admissível o uso de classes estáticas.

 

Pra evitar confusões, sempre que for definir uma classe, pergunte-se "Qual problema ela resolve"? Ter todas as suas funções globais envolvidas numa nova estrutura não é bem a solução de um problema.

 

class ExemploDeClasseQueNaoResolveProblemaNenhum
{
    public function conectaNoBanco()
    {
        mysql_connect();
    }
 
    public function executaQuery($query)
    {
        return mysql_query($query);
    }
 
    ...
}

 

Antes de continuar com o diagrama de classes pensei em fazer um caso de uso ? seria melhor para continuar definindo as classes ?

Se você acredita que pode ser elucidativo, que pode encontrar possíveis problemas ou buracos descobertos, faça.

 

Você não precisa do software deles, vc precisa de git, github é apenas um servidor de GIT, sistema de controle de distribuído. Git não é complicado, mas vc só aprende na prática.

Facilita pra quem não tem intimidade com a linha de comando. Inclusive, se o objetivo do projeto é praticar o desenvolvimento em OO, poderíamos focar apenas nisso ao invés de incluir complexidades alheias ao problema.

 

 

Ok, o farei, não tenho postado por falta de tempo ,vo trabalhar na interface, enquanto isso estou tendo problemas com o github, instalar configurar e tal, mas já estou de olho nos tutoriais, só se não conseguir mesmo peço um help.

 

@Edit: Descobri o problema com o github, a conexão com a internet onde trabalho utiliza proxy, acredito que por este motivão não consigo conectar ao servidor.

 

ao digitar os comandos:

 

 

ssh git@github.com

ou

git -T git@github.com

retorna um erro

ssh github.com no address associated with name

Estou pesquisando pra ver se encontro alguma solução e se realmente esse é o problema.

 

 

Obrigado mais uma vez.

 

[inline]git config --global http.proxy ENDERECO:PORTA[/inline]. Era pro cliente do Github já ter verificado isso mas, enfim.

 

 

Seria interessante você explicar melhor o uso das interfaces.

TL;DR

 

 

Por um breve momento, esqueça tudo que você sabe sobre programação. Esqueça que você sabe programar. Esqueça Orientação a objetos, procedures, funções, variáveis, esqueça.

 

Olhe o mundo à sua volta. Você está rodeado de objetos. Neste momento, olhando para um Monitor/Tablet/Celular. Se estiver sentado, há grandes chances de estar utilizando uma cadeira, um banco ou um sofá.

 

Você identifica objetos pelo que eles são capazes de fazer

O seu monitor/tablet/celular exibe informações visuais

A cadeira/banco/sofá te permite que você se sente com mais conforto

 

Ainda, você identifica as propriedades de algum objeto pelo que ele é capaz de fazer

Uma pessoa forte é capaz de mover coisas pesadas

Uma pessoa inteligente é capaz de solucionar problemas complexos

Um computador é capaz de se ligar à rede elétrica, portanto ele é elétrico

Uma bicicleta permte-se ser pedalada ou empurrada. Ela é mecânica

 

Não precisamos abrir um aparelho de som para descobrir que ele funciona à base de eletricidade. Apenas vemos que o mesmo possui um plug que se encaixa na tomada.

 

Não precisamos ver o motor de um carro ou as pastilhas nos discos dos freios para saber que eles funcionam. Apenas pisamos nos pedais de aceleração ou freio e os mecanismos internos se acionam.

 

Os mecanismos de aceleração de um carro antigo diferem dos de um carro moderno, com injeção eletrônica inteligente.

Os mecanismos de freio de um carro antigo diferem dos de um carro moderno, com ABS.

 

Mas em todos os casos, os mecanismos são acionados por pedal. A interface não muda, nós não temos problemas. Diversas montadoras podem implementar a mecânica de formas diferentes a fim de obter melhor performance, melhor autonomia, menos ruído. Desde que hajam pedais, nós, motoristas, não precisamos nos preocupar em aprender como as coisas funcionam.

 

O que não é verdade, por exemplo, quando falamos da transmissão. Estamos acostumados com o câmbio em hastes e, quando nos deparamos com um shift paddle, precisamos nos adequar à nova interface.

 

O verbete principal da Wikipedia descreve diversos cenários onde a palavra Interface aparece, mas todos eles convergem para uma ideia comum:

Interface é a forma de interação entre dois elementos

 

Agora podemos lembrar que sabemos programação. Podemos voltar ao conceito de OO e atender ao pedido citado:

 

Seria interessante você explicar melhor o uso das interfaces.

 

Interfaces descrevem a forma como os objetos vão interagir.

 

Veja, se pegarmos meu último diagrama postado

e dermos uma interface para cada um dos participantes implementar, desde que todas as regras das interfaces sejam seguidas, quando juntarmos todo o trabalho, o sistema tem que funcionar. Nós nunca nos vimos pessoalmente, nunca trabalhamos juntos, não decidimos se vamos armazenar os dados em banco de dados, se vai ficar na memória, se vai ficar em arquivos no disco porque isso não nos interessa! Essa é a mágica. Se seguirmos as interfaces, poderemos variar as implementações de diversas formas (assim como variamos as montadoras de veículos) e tudo continua funcionando como deveria (acionando os pedais).

 

 

[Enrico Pereira 299]

Em momento algum [inline]$instancia1[/inline] e [inline]$instancia2[/inline] produzem resultados diferentes. Se elas não produzem resultados diferentes, eu não vejo motivo para que sejam instâncias diferentes. Se não precisamos de instâncias, podemos nos utilizar dos métodos estáticos

 

Nunca, nunca, jamais, nunquinha, isso vai causar acoplamento. Métodos estáticos servem APENAS para criação de objetos. Isso é o câncer da OO, estáticos ..

[Evandro Oliveira 331]

Nunca, nunca, jamais, nunquinha, isso vai causar acoplamento. Métodos estáticos servem APENAS para criação de objetos. Isso é o câncer da OO, estáticos ..

Rebato o grifo do apenas

<?php


interface Printable {
    /**
     * @param \string [$printer] Path to printer to use. Supress to use the
     * default one.
     */
    public function doPrint($printer = null);

    public function setDefaultPrinter($printer);

    public function getDefaultPrinter();
}

abstract class PrintableInstance implements Printable {
    private static $defaultPrinter = '/dev/lp0';

    public final static function setDefaultPrinter($path) {
        if (!touch($path)) {
            throw new RuntimeException("Cannot use '{$path}'");
        }
        PrintableInstance::$defaultPrinter = $path;
    }

    public final static function getDefaultPrinter() {
        return PrintableInstance::$defaultPrinter;
    }
}

Mas concordo com a rejeição quanto ao uso de estáticos

Pelo conceito, ainda há alguma coisa errada, uma vez que classes existem para ser instanciadas. Mas existem alguns raros casos onde é admissível o uso de classes estáticas.

[Enrico Pereira 299]

Vc disse raros casos, poderia citar algum? Esse acima acho que não é um caso.

[Evandro Oliveira 331]

Adoraria ver sua implementação deste caso.

 

Não que eu concorde, mas é comum ver implementações de Registry como sendo ou uma classe estática ou um Singleton. Não vejo motivos para não poder ter mais de um Registry, mas é um padrão bem difundido e aceito.

 

A classe [inline]System[/inline] do Java é estática. Quem te garante que o objeto global [inline]window[/inline] do navegador não é um estático??

 

Uma reimplementação das estruturas de núcleo do PHP (ini_get/set, por exemplo) poderiam ter mais de uma instância com que objetivo, se [inline]$php_core->setMaxExecutionTime(300);[/inline] afetaria todas as outras instâncias??

 

SessionHandler do PHP é inteiramente estática e eu não vejo um cenário onde você vá manipular a sessão como instâncias diferentes.

 

Estamos destoando do tópico e imprimindo uma complexidade desnecessária. Estou perfeitamente disposto a discutir isso por mensagem ou um tópico em separado, conforme você julgue conveniente.

[Enrico Pereira 299]

Ok, eu não uso e não gosto, digo, detesto, mas cada um com sua opinião. Mas Registry aí eu já discordo dele, mas ... prosseguir tópico

[Rodolfo TI 6]

E aí meus amigos, desculpe a demora em responder, estou muuuuito agarrado com o trabalho e não consigo desenvolver o projeto.

 

Me surgiu a seguinte dúvida numa aula de análise e desenvolvimento de sistemas, começamos a aprender o diagrama de atividades e não vejo este ser muito usado no inicio de desenvolvimento de sistemas ? Existe um motivo para isso ?

 

Pelo meu tempo ser curto, deveria marcar como resolvido e mais tardeamente criar outro tópico, gostaria que a moderação me tirasse essa dúvida para que possa contribuir com a organização do fórum.

 

 

Pensei em desenvolver o diagrama de atividades para retratar melhor o funcionamento do sistema.

 

AInda estou com dificuldades no github, mas é falta de tempo pra mexer tb, grande abraço.

[angelorubin 142]

Bom dia,

 

Se o tempo lhe permite, porque não utilizar o diagrama?

[Rodolfo TI 6]

Bom dia,

 

Se o tempo lhe permite, porque não utilizar o diagrama?

 

Outras etapas contribuíriam melhor para o desenvolvimento ? Preciso otimizar o tempo.

[Evandro Oliveira 331]

Veja, como programador, me contentaria com um diagrama de interfaces.

Como BD Admin, precisaria de um Diagrama de entidades, é o que todo mundo chama de diagrama de classes, mas eu não vejo motivo para enumerar propriedades privadas de uma classe, pelos motivos já explicitados anteriormente.


Tentando explicar um pouco melhor...

Comumente, faz-se isso:

Veja que eu, como implementador, posso chamar a propriedade salt pelo nome que eu quiser, uma vez que ela será específica da minha implementação.

Um programador só precisa de

Em contrapartida, para desenvolvimento de entidades, um BD Admin não precisa de métodos. Trataremos de stored procedures mais adiante. Aqui, sim, precisamos do relacionamento entre os "objetos"

Para descrever comportamentos podemos nos valer dos casos de uso:

Quando faço A, acontece B. Isso ajudaria a decidir o que pode ir na programação e o que deve se tornar uma procedure de BD.

 

Enquanto as permissões ajudam na implementação, eventos ajudam no desenvolvimento do banco.

[Henrique Barcelos 290]

Concordo com o Evandro quanto ao uso de static, se bem aplicado, é uma mão da roda.

Nesse exemplo citado, se temos uma dependência externa e, muitas vezes, utilizamos a MESMA funcionalidade, ao invés de criarmos um objeto para cada vez que utilizamos uma determinada operação, além de economizar memória, economizamos linhas de código.

 

Nada existe por acaso, tudo bem uma utilidade, até GOTO pode ser útil dependendo do contexto, só não dá pra abusar.

 

 

Outras etapas contribuíriam melhor para o desenvolvimento ? Preciso otimizar o tempo.

Olha, ao que me parece não é algo muito complexo. Tudo bem que você está fazendo seu PRIMEIRO projeto, mas exatamente por isso: não se preocupe com o resultado final por hora.

 

Programação é algo que só se aprende na prática, você vai fazer errado 10 vezes até acertar. Uma hora você fica calejado e acerta de primeira. Planejamento é sim muito importante, mas esse modelo de planejar tudo primeiro e só depois implantar está totalmente defasado.

 

Sem medo do código, na hora da implementação, se houver necessidade de alterar o planejamento inicial, faça sem nenhum remorso. Diagramas UML, documentos de requisitos, etc, etc, etc. são muito bonitinhos na teoria, na hora de programar mesmo é que a coisa pega.

[Enrico Pereira 299]

Estático pode ser bem aplicado, quando você usa para criação de objectos, exemplo:

 

<?php

interface DatabaseConnectionInterface
{
    // ..
}

class MySQL implements DatabaseConnectionInterface
{
    // ..
}

class SQLite implements DatabaseConnectionInterface
{
    // ..
}

class Conn
{
    protected $database;

    public function __construct(DatabaseConnectionInterface $database)
    {
        $this->database = $database;
    }

    public static function createFromMySQL()
    {
        return new static(new MySQL);
    }

    public static function createFromSQLite()
    {
        return new static(new SQLite);
    }
}

 

 

Caso contrário geraria acoplamento.