Primeiro Projeto PHP Orientado a Objeto.

[Rodolfo TI 6]

 

Então quero ajudar sem participar

Relaxa meu caro, sabe alguma ferramenta pra trabalhar a interface, quando eles se referem a isso se referem aos protótipos ? Ou a interface mesmo ? quer será utilziado pelo sistema ?

 

Sabe dizer ?

[Vinicius Rangel 208]

http://forum.imasters.com.br/topic/393238-142-metodos-de-interface-e-polimorfismo/

 

interfaces são objetos.

[Rodolfo TI 6]

identifique os elementos(classes/atores) suas responsabilidades e como são as interações entre eles.

 

Então deveria fazer o caso de uso primeiro ? Ligo diretamente atores ao caso de usos ?

[Evandro Oliveira 331]

Muito bom, é interessante ir postando a evolução ?

Crie um projeto no github

 

A idéia é a seguinte

 

Tenho um funcionário, ele por der gerente e instrutor de uma formação, mas isso não faz com que ele deixe de ser funcionário, nessa situação aplica-se o conceito de herança ? correto ?

Aplicaria, mas tenho outra abordagem

 

Como seria dada a relação das classes Formação e Funcionário, em banco de dados seria nada mais que N para N e no digrama de classe ?

Um funcionário pode ter N formações? Se sim, N para N.

 

O gerente será responsável pos cadastrar as formações, o instrutor por leciona-las, e o funcionário sem caracteristicas de gerente ou de instrutor irá participar das mesmas.

Responsabilidade, na maioria das vezes, está relacionada a permissão. Pensar desta forma vai te permitir uma maior flexibilidade quando for passar o seu diagrama de classes para um banco de dados relacional, se for o caso.

 

Você só permite entrar em uma sala para lecionar quem fizer parte do seu plantel de instrutores. Você só permite utilizar um crachá quem fizer parte do seu grupo de funcionários e assim por diante.

 

Por favor, descreva, com um pouco mais de clareza, atuantes e suas características e ações. Repetições são muito bem vindas. São elas que vão nos ajudar a encontrar padrões e compartilhar código.

 

Um exemplo do que eu preciso

 

Tenho um gato que tem cor de olhos, cor de pêlos, anda, mia, arranha e se lambe

Tenho um cachorro que tem cor de olhos, cor de pêlos, anda, morde e late

Daqui extraímos

[Enrico Pereira 299]

http://forum.imasters.com.br/topic/393238-142-metodos-de-interface-e-polimorfismo/

 

interfaces são objetos.

 

Interfaces são tipos, que podem determinar métodos e argumentos. No futuro talvez tipo de retorno (sonho :joia: )

[Vinicius Rangel 208]

Interfaces são tipos, que podem determinar métodos e argumentos.

melhor colocação, vlw.

 

o Evandro sempre vem humilhar, mol errado isso.

[Rodolfo TI 6]

Crie um projeto no github

 

Aplicaria, mas tenho outra abordagem

 

Um funcionário pode ter N formações? Se sim, N para N.

 

Responsabilidade, na maioria das vezes, está relacionada a permissão. Pensar desta forma vai te permitir uma maior flexibilidade quando for passar o seu diagrama de classes para um banco de dados relacional, se for o caso.

ótimas concepções .

 

Passo 1 - Criar o projeto Github

Passo 2 - Verificar classes , relacionamentos entre elas e melhorar o diagrama, dessa forma irei definir melhor as responsabilidades e explicar melhor minhas dificuldades

Passo 3 - Analisar as permissões quanto as atividades

 

 

SOLID são os 5 principais princípios de OO, os design patterns respeitam eles.

Mandou muito bem dei uma lida aqui e realmente é muito bom, vou parar e analisar com mais calma.

 

o Evandro sempre vem humilhar, mol errado isso.

 

@offTopic: Nós aqui de embaixadinha e o mano vai e manda um bicleta. X.x

 

Nesse momento estou na faculdade e vou apresentar um trabalho adivinha de que ? OO

 

Ahahaá, to enrolado, mas vamo néssa, por este motivo não vou postar o diagrama agora mas em breve estarei trabalhando nisso, valeu rapaziada!

[angelorubin 142]

Bom dia,

 

Quando eu falei sobre o exemplo de herança, era exatamente o que o evandro esta mostrando, agora montei aqui, desta forma eu compreendi, claro que cada um terá facilidade de entender com um exemplo as vezes simples e outros compreenderão com um exemplo não tão simples.

 

 

O que eu pude entender é que quando temos uma superclasse fica facil notar a aplicação de herança (pelo menos para mim), agora e quando não é tão obvio assim, como fazemos? esta é minha duvida !

 

*Rodolfo se eu estiver atrapalhando mais que contribuindo é só falar, ok?

[Vinicius Rangel 208]

Entender o conceito de herança é teoricamente simples.

 

Só que existem as interfaces também que é fundamental para um código Orientado a Objeto pelo menos no PHP me parece e é difícil conciliar quando é um e quando é outro, vejo muitas pessoas se confundindo e eu mesmo me confundo as vezes pq quando eu penso de mais parece que tudo se encaixa melhor na interface o que esta errado.

[Rodolfo TI 6]

 

O que eu pude entender é que quando temos uma superclasse fica facil notar a aplicação de herança (pelo menos para mim), agora e quando não é tão obvio assim, como fazemos? esta é minha duvida !

 

*Rodolfo se eu estiver atrapalhando mais que contribuindo é só falar, ok?

 

Eu entendi esse exemplo mais como um exemplo de polimorfismo pois tens o método retirar tanto na superclasse quanto nas subclasses e quanto é assim a classe executa o método interno a ela que geralmente tem caracteristicas diferentes do da superclasse.

 

Mas opa, polimorfismo é um conceito de herença ? errado estou ?

 

Cara ta show, ta ajudando sim fique tranquilo.

 

vejo muitas pessoas se confundindo e eu mesmo me confundo as vezes pq quando eu penso de mais parece que tudo se encaixa melhor na interface o que esta errado.

 

Pois é, eis aqui mais um deles, não consegui diferenciar um do outro, :coolio:

 

Tive problema em criar o projeto do github, quando eles falam:

 

Initialize this repository with a README

 

Devo escolher em php ?

 

ali pelo que entendo serão algumas definições de sistema correto ?

 

Abaixo segue o diagrama com algumas atualizações, surgiu uma dúvida uma classe para ser uma classe deve ter atributos ou pode ter apenas métodos ?

 

 

Dá um confere ainda estou um pouco confuso ? rsrs

 

Vamo lá definir o problema, rsrsrs, Voltamos ao Levantamento de Requisitos / Análise de Requisitos

 

Este será um sistema para controlar formações

 

Essas formações serão cadastradas por um gerente e terão que ser fornecidas as seguintes informações:

 

Nome da formação, Ementa e esta terá um código unico ( não sei se o item código deve ser levado em consideração nesse modelo )

 

O gerente nada mais é que um funcionário, assim como o instrutor porém diferenciamos eles da seguinte forma:

 

Ambos terão informações como:

 

Id, Nome , Mail , Setor e um Nivel de acesso ( que definirá quem é instrutor e quem é gerente e quem é apenas um participante)

 

Algumas restrições são feitas quanto ao que estes podem fazer

 

O Participante pode efetuar Incrição nas formações ( a idéia mesmo é que o gerente definisse os participantes da formação, ele cadastrasse os participantes de uma formação e este deveria apenas confirmá-la, para que o gerente tenha informação que este funcionário confirmou a presença e irá fazer a formação)

 

O instrutor será responsável por ministrar as formações

 

O gerente deve cadastrar as formações , cadastrar os instrutores e cadastrar os funcionários ( isso mesmo ele é o GM da parada , @offtopic $tibia)

 

Ambos, podem participar de uma formação, ou seja todos eles podem ser participantes de uma formação.

 

-----------------------------//------------------------

 

Algumas dúvidas :

 

Onde definiria dentro de uma formação que o instrutor participa como instrutor e os outros como participantes ?

 

Os gerentes podem participar de formações e ser instrutores também., como isso será definido ?

 

Houve algum progresso do meu diagrama anterior para esse ?

 

Que conceitos devo estabelecer para dar melhor continuídade ao projeto?

 

-----------------------------//------------------------

 

Estou preparando o diagrama de Casos de Uso

 

"O diagrama de casos de uso procura, por meio de uma linguagem simples, possibilitar a compreensão do comportamento externo do sistema ( em termos as funcionalidades por ele ) por qualquer pessoa, tentando apresentar o diagrama por intermédio de uma perspectiva do usuário." ( GUEDES, Gilleanes - UML2 Uma abordagem Prática)

 

Acho que se levarmos em consideração estamos na fase de levantamento de requisitos e análise, de certa forma seguinto o processo unificado e fazendo os dois ao mesmo tempo portando estamos no processo de Concepção.

 

Para quem não conhece o PROCESSO UNIFICADO DE DESENVOLVIMENTO , ajuda e muito!

[Stratocaster 85 10]

Muitos programadores não entendem o conceito de Interface por causa da tipagem fraca do PHP

[shini 318]

vc tem formação agora falta a turma:

 

turma:

id

formacao

instrutor

nome (por exemplo noite 1, noite 2, manha 3)

dataInicio

dataFim

participantes/funcionarios

 

 

a agenda apaga ela..... haha devo ter falado bobagem quanto a ela rs

[Rodolfo TI 6]

vc tem formação agora falta a turma:

 

turma:

id

formacao

instrutor

nome (por exemplo noite 1, noite 2, manha 3)

dataInicio

dataFim

participantes/funcionarios

assim ?

 

Aproveitei pra criar mais funções ao gerente, ta errado ?

 

[shini 318]

funcionario e formação, n se relacionam, é funcionario e turma.

formação não conhece turma mas o contrario.

na turma faltou a lista dos funcionarios/participantes.

[Rodolfo TI 6]

funcionario e formação, n se relacionam, é funcionario e turma.

formação não conhece turma mas o contrario.

na turma faltou a lista dos funcionarios/participantes.

 

E quanto aos participantes ? Não seria turma -> participantes ?

 

[angelorubin 142]

Boa tarde,

 

Uma opinião, quando eu aprendi a modelar (se é que aprendi), começava bem pelo básico mesmo, sem me preocupar com métodos, etc.

 

Seguia nessa sua linha, primeiro um levantameto de requisitos básico, identificando as entidades do problema, atributos e como eles se relacionam entre sí.

 

Com isso bem definido, partia adiante.

 

* Sugeri isso pois notei uma certa confusão sobre quais são as entidades identificadas no problema.

[Evandro Oliveira 331]

 

Eu entendi esse exemplo mais como um exemplo de polimorfismo pois tens o método retirar tanto na superclasse quanto nas subclasses e quanto é assim a classe executa o método interno a ela que geralmente tem caracteristicas diferentes do da superclasse.

 

Mas opa, polimorfismo é um conceito de herença ? errado estou ?

Não, polimorfismo é uma competência de OO. Está mais ligado às interfaces. Polimorfismo é quando uma instância se comporta como vários tipos.

 

 

Tive problema em criar o projeto do github, quando eles falam:

 

Initialize this repository with a README

Quer dizer que o repositório já vai ter um commit inicial, com um arquivo chamado README em branco

 

Devo escolher em php ?

 

 

ali pelo que entendo serão algumas definições de sistema correto ?

Sim e não. É um template de tipos de arquivos que não irão para o repositório. Inclui, por exemplo, os arquivos de miniaturas (thumbs.db) do Windows e as configurações de diretórios (desktop.ini/.DS_STORE - MAC)

 

 

Abaixo segue o diagrama com algumas atualizações, surgiu uma dúvida uma classe para ser uma classe deve ter atributos ou pode ter apenas métodos ?

Uma classe, para ser uma classe, basta ser uma classe!?!?

class Classe {}

 

Vamo lá definir o problema, rsrsrs, Voltamos ao Levantamento de Requisitos / Análise de Requisitos

 

Este será um sistema para controlar formações

 

Formações

 

Essas formações serão cadastradas por um gerente e terão que ser fornecidas as seguintes informações:

Gerente

 

Nome da formação, Ementa e esta terá um código unico ( não sei se o item código deve ser levado em consideração nesse modelo )

Formação possui nome, ementa

O gerente nada mais é que um funcionário, assim como o instrutor porém diferenciamos eles da seguinte forma:

Funcionário, Instrutor

Ambos terão informações como:

 

Id, Nome , Mail , Setor e um Nivel de acesso ( que definirá quem é instrutor e quem é gerente e quem é apenas um participante)

Gerente possui nome, email, setor

Instrutor possui nome, email, setor

Funcionário possui nome, email, setor

 

Algumas restrições são feitas quanto ao que estes podem fazer

 

 

O Participante pode efetuar Incrição nas formações ( a idéia mesmo é que o gerente definisse os participantes da formação, ele cadastrasse os participantes de uma formação e este deveria apenas confirmá-la, para que o gerente tenha informação que este funcionário confirmou a presença e irá fazer a formação)

Participante

Participante possui nome, email, setor e é capaz de confirmar a participação numa formação

 

O instrutor será responsável por ministrar as formações

Instrutor possui nome, email, setor e é capaz de ministrar formações

O gerente deve cadastrar as formações , cadastrar os instrutores e cadastrar os funcionários ( isso mesmo ele é o GM da parada , @offtopic $tibia)

O gerente possui nome, email, setor e é capaz de cadastrar instrutores e cadastrar funcionários

Ambos, podem participar de uma formação, ou seja todos eles podem ser participantes de uma formação.

Participante possui nome, email, setor e é capaz de confirmar a participação numa formação

Instrutor possui nome, email, setor e é capaz de confirmar a participação numa formação e ministrar formações

Gerente possui nome, email, setor e é capaz de confirmar a participação numa formação, ministrar formações, cadastrar instrutores e cadastrar funcionários

-----------------------------//------------------------

 

Algumas dúvidas :

 

Onde definiria dentro de uma formação que o instrutor participa como instrutor e os outros como participantes ?

Formação pode possuir o atributo Instrutor

Os gerentes podem participar de formações e ser instrutores também., como isso será definido ?

Eu pensei em papéis. Acho que não vai ser o caso.

Houve algum progresso do meu diagrama anterior para esse ?

Bastante.

Que conceitos devo estabelecer para dar melhor continuídade ao projeto?

O conceito comece do começo

 

assim ?

 

Aproveitei pra criar mais funções ao gerente, ta errado ?

Não, mas elas tem que ser descritas. Vamos brincar que você é o cliente e nós somos o time de desenvolvimento. Depois que entregamos o produto, você vem e diz "Ah, mas não faz tal coisa!". A resposta seria categórica: "Você não pediu!"

 

Como você disse que adicionou mais funções a um gerente, vou atualizar apenas a especificação do gerente

Gerente possui nome, email, setor e é capaz de confirmar a participação numa formação, ministrar formações, cadastrar instrutores, cadastrar funcionários, cadastrar formações, cadastrar turma, alterar as propriedades de uma turma, alterar as propriedades de um funcionário, alterar as propriedades de um instrutor, alterar as propriedades de uma formação, excluir uma turma, excluir uma formação e excluir um instrutor.

 

O mapeamento final ficaria assim:

 

Formação possui nome, ementa e Instrutor

Participante possui nome, email, setor e é capaz de confirmar a participação numa formação

Instrutor possui nome, email, setor e é capaz de confirmar a participação numa formação e ministrar formações

Gerente possui nome, email, setor e é capaz de confirmar a participação numa formação, ministrar formações, cadastrar instrutores, cadastrar funcionários, cadastrar formações, cadastrar turma, alterar as propriedades de uma turma, alterar as propriedades de um funcionário, alterar as propriedades de um instrutor, alterar as propriedades de uma formação, excluir uma turma, excluir uma formação e excluir um instrutor

 

Perceba que Participante, Instrutor, e Gerente possuem, todos, a mesma base. O que muda são suas especializações.

 

Instrutor é um Participante, que pode fazer mais coisas.

Gerente é um Instrutor que pode fazer mais coisas.

 

Estamos diante de um caso de uso de herança.

Isso não se aplicaria se, por exemplo, gerentes não pudessem atuar como participantes ou instrutores.

 

Transportando os atributos para métodos getter/setter, podemos definir as Interfaces dos nossos participantes

 

Formação

obterNome, definirNome, obterEmenta, definirEmenta, obterInstrutor, definirInstrutor

 

Participante

obterNome, definirNome, obterEmail, definirEmail, obterSetor, definirSetor, confirmarParticipacao

 

Instrutor

obterNome, definirNome, obterEmail, definirEmail, obterSetor, definirSetor, confirmarParticipacao, ministrar

 

Gerente

obterNome, definirNome, obterEmail, definirEmail, obterSetor, definirSetor, confirmarParticipacao, ministrar, definirInstrutor, definirFormacao, definirParticipante, definirTurma, excluirTurma, excluirFormacao, excluirInstrutor

 

Por questões semânticas, me utilizarei dos recursos de namespaces presentes no PHP 5.3. Se não for possível utilizar esta versão, me avise para que seja feito a renomeação das estruturas.

 

 

 

Algumas considerações a fazer:

Algum funcionário cadastrado não poderá fazer nada? Se a resposta for uma negativa, não há um motivo claro para separar Participante de Funcionário.

 

Com a chegada da turma, o panorama muda um pouco:

• Um instrutor não ministra uma Formação, ministra para uma Turma
• Um participante não confirma participação numa Formação, confirma ou cancela a participação numa Turma

Há, ainda, a ausência de métodos para cadastrar participantes e o instrutor da turma. Acredito que a turma possa receber seu instrutor logo no momento da construção

 

Os nomes diferem nos diagramas mas prevalece a sua escolha.

 

 

Edição devido aos novos posts

 

E quanto aos participantes ? Não seria turma -> participantes ?

 

 

Melhorou um pouco. Participantes deve ser uma Collection, não um inteiro.

[Rodolfo TI 6]

Transportando os atributos para métodos getter/setter, podemos definir as Interfaces dos nossos participantes

 

Formação

obterNome, definirNome, obterEmenta, definirEmenta, obterInstrutor, definirInstrutor

Participante

obterNome, definirNome, obterEmail, definirEmail, obterSetor, definirSetor, confirmarParticipacao

Instrutor

obterNome, definirNome, obterEmail, definirEmail, obterSetor, definirSetor, confirmarParticipacao, ministrar

Gerente

obterNome, definirNome, obterEmail, definirEmail, obterSetor, definirSetor, confirmarParticipacao, ministrar, definirInstrutor, definirFormacao, definirParticipante, definirTurma, excluirTurma, excluirFormacao, excluirInstrutor

Quando se refere a definir e obter é diferente de cadastrar e editar ?

 

Porque quando cadastrar uma formação ela obtêm os dados? correto ?

[Evandro Oliveira 331]

Quando se refere a definir e obter é diferente de cadastrar e editar ?

 

Porque quando cadastrar uma formação ela obtêm os dados? correto ?

 

Definir/obter = get/set

 

Não há motivo para separar a ação de criar da ação de editar.

 

Para editar uma turma:

 

$turma->setName('novo nome');

 

Não tem porque ser mais complexo que isso.

[Rodolfo TI 6]

Não tem porque ser mais complexo que isso.

 

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 ?

 

 

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 ?