Como pensar em Orientação a Objetos

[Beto A. 0]

Sim, se faz realmente necessária, afinal, a Empresa contrata Profissional, se não dissermos o que ela contrata, ela poderá acabar contratando qualquer coisa. Não queremos isso.

 

 

 

Estilo Java??? De onde você tirou isso?

 

Obrigado por ter tirado a dúvida!

Opa, foi apenas uma confusão... estou vendo Java esse semestre na faculdade :)

[JCMais 75]

JB, você usa o UML2Tools para criar os diagramas?

[João Batista Neto 448]

Opa, foi apenas uma confusão...

 

Então tome muito cuidado, veja:

 

C#

namespace iMasters {
using System;

public interface Profissional {
}
}

 

namespace iMasters {
using System;

public class Diretor :Profissional {
	public Diretor () {
	}
}
}

 

namespace iMasters {
using System;

public class Gerente :Profissional {
	public Gerente () {
	}
}
}

 

namespace iMasters {
using System;
using System.Collections.Generic;

public class Empresa {
	private List<Profissional> profissionais;

	public Empresa () {
		profissionais = new List<Profissional>();
	}

	public void contrata( Profissional profissional ) {
		profissionais.Add( profissional );
	}
}
}

 

Em Java:

package iMasters;

public interface Profissional {
}

 

package iMasters;

public class Diretor implements Profissional {
}

 

package iMasters;

public class Gerente implements Profissional {
}

 

package iMasters;

import java.util.ArrayList;
import java.util.List;

public class Empresa {
private List<Profissional> profissionais;

public Empresa() {
	profissionais = new ArrayList<Profissional>();
}

public void contrata( Profissional profissional ) {
	profissionais.add( profissional );
}
}

 

Actionscript 3 (ECMA 262 Edição 4)

package iMasters {
public interface Profissional {
}
}

 

package iMasters {
public class Diretor implements Profissional {
}
}

 

package iMasters {
public class Gerente implements Profissional {
}
}

 

package iMasters {
public class Empresa {
	private var profissionais :Vector.<Profissional>;

	public function Empresa() {
		profissionais = new Vector.<Profissional>();
	}

	public function contrata( profissional :Profissional ) :void {
		profissionais.push( profissional );
	}
}
}

 

Eu poderia ilustrar o código em mais algumas outras linguagens, mas não vem ao caso. O fato é que não estamos falando sobre "Estilo Java", estamos falando sobre estilo orientado a objetos.

 

;)

[Humberto Rodrigues 0]

Antes de mais nada, parabéns pelo alto nível do tópico. Faltam tópicos deste nível na internet.

Eu li, praticamente, todos os posts. Só não entendi bem uma coisa:

Vão pegar o problema inicial e desenvolver uma solução em conjunto, é isto?

 

E mais uma vez: parabéns a todos!

[João Batista Neto 448]

Antes de mais nada, parabéns pelo alto nível do tópico. Faltam tópicos deste nível na internet.

 

Realmente! Parabéns para todos os membros que estão participando, o nível do tópico está fantástico graças a contribuição de cada um de vocês!

 

Vão pegar o problema inicial e desenvolver uma solução em conjunto, é isto?

 

Sim, já está acontecendo.

 

O @João Prado vai nos dar uma força com o design, em breve começaremos a desenvolver a GUI da aplicação.

 

;)

[Humberto Rodrigues 0]

Realmente! Parabéns para todos os membros que estão participando, o nível do tópico está fantástico graças a contribuição de cada um de vocês!

 

 

 

Sim, já está acontecendo.

 

O @João Prado vai nos dar uma força com o design, em breve começaremos a desenvolver a GUI da aplicação.

 

;)

 

Então cheguei tarde de mais. Pensei em ajudar. Mas tem como acompanhar o código?

[João Batista Neto 448]

Então cheguei tarde de mais. Pensei em ajudar. Mas tem como acompanhar o código?

 

Claro que não chegou tarde, sua ajuda será muito bem vinda.

 

Criamos um repositório no github, no perfil do iMasters Developer :seta: https://github.com/iMastersDev/

 

Para fazer o clone:

git clone git://github.com/iMastersDev/iMasters-Form.git

 

:D

[Beto A. 0]

Entendi o seu ponto João.

 

Eu já tinha visto e feito dessa forma em C#, com coisas que foram desenvolvidas ano passado na faculdade, e em Java também.

 

Obrigado mais uma vez pelo esclarecimento!

 

E, também gostaria de ajudar e participar do desenvolvimento da aplicação, vai fazer muito bem para os meus conhecimentos tanto de PHP quanto de OO.

 

Forte abraço.

[Henrique Barcelos 290]

Bom, vou dar uma olhada em como se trabalha com GIT...

Alguém sabe se tem integração direta com o Eclipse?

 

João, gostaria de já ir implementando a base para o CRUD (apenas as classes base envolvendo o banco de dados).

[JCMais 75]

Bom, vou dar uma olhada em como se trabalha com GIT...

Alguém sabe se tem integração direta com o Eclipse?

 

Eclipse Marketplace =)

[João Batista Neto 448]

Era uma vez, em um grande fórum de tecnologia, um grande número de membros que postavam suas dúvidas e eram ajudados por outros membros. Cada tópico que um membro postava, abria margem para discussões, aprimoramentos, esclarecimentos e, até, mudanças em pontos de vista que, até então, eram, de certa forma, equivocados...

 

Se você não entendeu onde quero chegar, então você, definitivamente, não entende nada de controle de versão. Porque controle de versão é exatamente isso, uma história, a história do seu código no decorrer do tempo. A grande diferença entre o git e os outros vários controles de versão, é que no git, cada membro possui uma cópia completa da história em seu próprio ambiente de trabalho, exatamente ao contrário do fórum, onde a história dos tópicos ficam armazenados em um servidor do fórum.

 

Como toda história, ela possui um início:

 

$ git init
Initialized empty Git repository in /home/neto/umahistoria/.git/

 

Ao iniciar uma história, ela é completamente vazia, é como se tivéssemos comprado um livro cheio de páginas em branco. Mesmo que façamos o seguinte:

 

$ echo "Falando sobre git no Fórum iMasters" >README

 

Nossa história continuará vazia, isso porque o arquivo README ainda não foi adicionada nessa história. Precisamos adicionar o README no índice da história e, então, começar a escrever sua página.

 

$ git add README

 

Isso fará com que README vá para o índice da história, mas a página referente ao README ainda estará vazia porque não gravamos essa página.

 

$ git commit -m "Gravando a primeira página"
[master (root-commit) 452d86e] Gravando a primeira página
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 README

 

Cada mudança que façamos nas páginas dessa história precisam, então, ser gravadas, se não fizermos commit, não gravaremos nossas mudanças, por exemplo:

 

$ echo "Mudando o conteúdo" >README 
$ cat README 
Mudando o conteúdo

 

Agora, vamos ver o status do repositório:

 

$ git status
# On branch master
# Changes not staged for commit:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#   	modified:   README
#
no changes added to commit (use "git add" and/or "git commit -a")

 

Como esperado, o arquivo está modificado mo meu diretório de trabalho, mas essas mudanças ainda não foram gravadas no repositório local. Isso significa que posso descartar todas as mudanças que fiz, fazendo checkout da versão do repositório, por exemplo:

 

$ cat README 
Mudando o conteúdo
$ git checkout -- README 
$ cat README 
Falando sobre git no Fórum iMasters

 

Então, sempre que fazemos mudanças em um diretório de trabalho, precisamos gravar essas mudanças no repositório local:

 

$ echo "Mudando o conteúdo" >README 
$ cat README 
Mudando o conteúdo
$ git commit README -m "Gravando mudanças do README no repositório local"
[master f108bbd] Gravando mudanças do README no repositório local
1 files changed, 1 insertions(+), 1 deletions(-)

 

Até agora, temos o seguinte:

1. Um diretório de trabalho.

2. Usamos git add para adicionar o conteúdo desse diretório no índice.

3. Usamos git commit para adicionar ao repositório local.

4. Usamos git checkout para obter uma versão do repositório local para o diretório de trabalho (perdendo modificações que não foram commitadas).

 

Quando Linus Torvalds começou a desenvolver o git, ele tinha basicamente os seguintes requisitos:

 

1. Utilizar CVS como modelo do que não se deve ser. Se houvesse dúvidas quando a determinada implementação, fazer exatamente o oposto.

2. Suportar um fluxo de trabalho distribuído, como o BitKeeper (sistema de controle de versão que utilizavam para o núcleo do Linux).

3. Sistema de segurança muito forte, para evitar corrupção, maliciosas ou não.

4. Altíssima performance.

 

O ponto de vista de Linus sobre CVS e, consequentemente, SVN, era o seguinte:

 

For the first 10 years of kernel maintenance, we literally used tarballs and patches, which is a much superior source control management system than CVS is, but I did end up using CVS for 7 years at a commercial company and I hate it with a passion. When I say I hate CVS with a passion, I have to also say that if there are any SVN (Subversion) users in the audience, you might want to leave. Because my hatred of CVS has meant that I see Subversion as being the most pointless project ever started. The slogan of Subversion for a while was "CVS done right", or something like that, and if you start with that kind of slogan, there's nowhere you can go. There is no way to do CVS right.

 

Bom, um dos grandes pontos do git era ser distribuído, ou seja, cada desenvolvedor tem uma cópia de todo o código e todo a história e, com isso, operações de merge seriam muito rápidas, realmente rápidas.

 

Master é a ramificação principal, outros desenvolvedores podem fazer clone dessa ramificação (ou qualquer outra, o correto é não se trabalhar no master) e trabalhar em cima dela, pode também criar sua própria ramificação, enfim. Vimos que para gravar uma modificação no repositório local, utilizamos git commit. Logo após terminarmos nossas modificações em nosso repositório local, podemos querer mandá-las para o repositório remoto e, para isso, usamos git push.

 

 

Então, basicamente, trabalhar com git é fazer:

 

1. Criamos um repositório com git init ou clonamos um repositório com git clone.

2. Fazemos nossas mudanças e então usamos git add para adicionar novos arquivos no índice (se tiver novos arquivos) e fazemos git commit para gravar as mudanças.

3. Terminadas as mudanças, fazemos git push para enviar essas mudanças para o remote.

4. Como muitos desenvolvedores podem estar contando suas próprias histórias, devemos estar sempre atualizando a nossa utilizando git pull.

 

Acho que ficou mais simples de se entender agora, que acham?

[Bruno Augusto 417]

... porque quando crescer, quero ser como você!

Ótima explicação. :clap:

 

Instalar e configurar é fácil, mas faltava o bê-a-bá da coisa.

 

Me responde três coisas:

 

1. Quem controla o repositório remoto?
    
   Suponhamos que dez pessoas façam commit no projeto, mas duas delas mexeram no mesmo arquivo.
    
   A mudança que a segunda pessoa fez afeta parte do que a primeira fez. Ambas "commitam" e quando a primeira pessoa vai continuar vê que parou de funcionar.
    
   Obviamente ela vai continuar trabalhando no branch dela, mas no final das contas, com for fazer o... merge, né? Não vai dar zica?
    
   
2. Não consigo pensar num exemplo melhor. Um framework modular, como ZF. É correto dizer que cada módulo (DB, Session, Paginate, Acl...) é um branch?
    
   
3. Branches pode ter branches aninhados?
    
   Assim um módulo DB, por exemplo, tem ramificações de trabalho um para cada submódulo e, cada submódulo N branches, para cada modificação crucial ainda não efetivamente incluída no pacote DB final e que mais tarde, junto com todos os outros fará parte do master.
   

[JCMais 75]

Então usando o GitHub o ideal seria efetuar uma fork do respositório ( no caso https://github.com/iMastersDev/ ) e trabalhar em cima dela? Aí depois envia os arquivos modificados para o repositório de origem.

[João Batista Neto 448]

1. Quem controla o repositório remoto?

 

Normalmente, em locais como github, temos um administrador. Na prática, qualquer um que tenha permissões de push no repositório remoto pode fazer operações de push nele. Ficou sabendo do que aconteceu recentemente, sobre o russo Egor Homakov ter feito commit no branch master do repositório do rails?

 

Ele injetou sua própria chave pública ssh na lista de administradores do repositório do framework e, com isso, pôde controlar o repositório remoto. Então, qualquer um que tenha permissões nesse repositório, pode controlá-lo.

 

Suponhamos que dez pessoas façam commit no projeto, mas duas delas mexeram no mesmo arquivo.

 

A mudança que a segunda pessoa fez afeta parte do que a primeira fez. Ambas "commitam" e quando a primeira pessoa vai continuar vê que parou de funcionar.

 

Obviamente ela vai continuar trabalhando no branch dela, mas no final das contas, com for fazer o... merge, né? Não vai dar zica?

 

Não vai dar "zica" porque, ao mesclar duas histórias, o(s) responsável(eis) por mesclar as histórias farão a revisão. Porém, é importante notar que git pull é uma prática que deve ser seguida sempre. Antes de iniciar qualquer modificação em um código, o desenvolvedor deve fazer git pull para obter a última versão do branch que está trabalhando para, assim, não ficar com código defasado e sujeito a inconsistências que poderão ocasionar em operações de merge muito complexas.

 

Outro ponto é que o desenvolvimento não se dá no branch master, ou seja, temos um branch dev, por exemplo, onde os desenvolvedores vão fazendo commit/push/merge/pull de lá. Quando esse branch alcança um determinado objeto e está estável, ele é mesclado com o master.

 

Não consigo pensar num exemplo melhor. Um framework modular, como ZF. É correto dizer que cada módulo (DB, Session, Paginate, Acl...) é um branch?

 

Branch, ou ramificação, é como se fosse uma linha de desenvolvimento. DB, Session, Paginate, Acl e outros podem sim, serem branches diferentes. Mas usamos branches, principalmente, quando estamos trabalhando em linhas de desenvolvimento diferentes. Imagine que tenhamos uma web app, nessa web app temos a versão web que o usuário usará através de um navegador. Nesse caso, podemos ter um branch chamado service, onde trabalharemos em uma linha relacionada a um serviço REST.

 

Branches pode ter branches aninhados?

 

Assim um módulo DB, por exemplo, tem ramificações de trabalho um para cada submódulo e, cada submódulo N branches, para cada modificação crucial ainda não efetivamente incluída no pacote DB final e que mais tarde, junto com todos os outros fará parte do master.

 

Sim, podemos ter um branch dev, dentro de dev podemos ter um branch web, outro service, etc. Sempre que um branch cumprir seu ciclo de vida, podemos fazer merge com outros branches e, finalmente, fazer um merge no master.

 

Então usando o GitHub o ideal seria efetuar uma fork do respositório ( no caso https://github.com/iMastersDev/ ) e trabalhar em cima dela? Aí depois envia os arquivos modificados para o repositório de origem.

 

Ao fazer fork no github, você estará criando uma cópia de um repositório no seu próprio perfil. Com seu repositório no seu perfil do github, você faz um clone e trabalha nele.

 

1. Fork => Github cria um remote para você, que é um clone do repositório original.

2. Clone => Você vai clonar seu remote e trabalhar nele. Você poderá criar seus branches, fazer commit/push até alcançar seu objetivo.

3. Pull Request => Como eu mostrei no post anterior, pull é o ato de obter uma atualização de um determinado remote. No caso do Github, ao fazer um pull request, você está dizendo: Repositório X, atualize seu repositório com minhas atualizações que elas são legais. Com isso, o administrador do repositório X analisará seus commits e, se for o caso, fará um pull do seu remote.

[JCMais 75]

Ficou sabendo do que aconteceu recentemente, sobre o russo Egor Homakov ter feito commit no branch master do repositório do rails?

 

https://github.com/rails/rails/commit/b83965785db1eec019edf1fc272b1aa393e6dc57 O cara até que tem senso de humor :seta: https://github.com/rails/rails/issues/5239, mas foi suspenso do GitHub.

 

Ao fazer fork no github, você estará criando uma cópia de um repositório no seu próprio perfil. Com seu repositório no seu perfil do github, você faz um clone e trabalha nele.

 

1. Fork => Github cria um remote para você, que é um clone do repositório original.

2. Clone => Você vai clonar seu remote e trabalhar nele. Você poderá criar seus branches, fazer commit/push até alcançar seu objetivo.

3. Pull Request => Como eu mostrei no post anterior, pull é o ato de obter uma atualização de um determinado remote. No caso do Github, ao fazer um pull request, você está dizendo: Repositório X, atualize seu repositório com minhas atualizações que elas são legais. Com isso, o administrador do repositório X analisará seus commits e, se for o caso, fará um pull do seu remote.

 

Entendi, mas no nosso caso, iremos trabalhar com um clone do repositório principal, ou cada um faz um fork e trabalha no seu repositório, e no fim envia um Pull Request para o repositório de origem? Ou cabe à quem for colaborar decidir isto?

[João Batista Neto 448]

Entendi, mas no nosso caso, iremos trabalhar com um clone do repositório principal, ou cada um faz um fork e trabalha no seu repositório, e no fim envia um Pull Request para o repositório de origem? Ou cabe à quem for colaborar decidir isto?

 

Cada um fará um fork e trabalhará em seu próprio repositório, fazendo commit/push. Quando tiverem alcançado algum objetivo, façam um pull request no iMasters-Form.

[Bruno Augusto 417]

Mais uma questão.

 

E na possibilidade de o commiter ter mais conhecimento dobre o assunto que o Admin? COmo que este julgará em prol ou em contra o commit antes do merge?

[JCMais 75]

Mais uma questão.

 

E na possibilidade de o commiter ter mais conhecimento dobre o assunto que o Admin? COmo que este julgará em prol ou em contra o commit antes do merge?

 

A comunidade de desenvolvedores colaborando no projeto pode comentar no Pull Request. Se determinado Commit vai contra algo que o administrador do projeto espere, mas vá em direção à aquilo que a comunidade espera, resta o mesmo ter bom senso.

[João Batista Neto 448]

E na possibilidade de o commiter ter mais conhecimento dobre o assunto que o Admin? COmo que este julgará em prol ou em contra o commit antes do merge?

 

Vou organizar um time, com conhecimentos específicos em áreas específicas. Por exemplo, o William Bruno conhece muitas vezes mais do que eu sobre CSS, eu nem me atrevo a discutir CSS com ele. Certamente o William será um membro do time, com poderes para merge no master.

 

Teremos também membros no time, com poderes no master, para julgar coisas referentes ao server-side, webstandards, SGBD, etc.

[João Prado 64]

Boa tarde negada, vamos trabalhar?

 

 

Pelo o que o João me explicou sobre o projeto eu preparei o layout de visualização do formulário e de edição.

 

Vou postar apenas os links para não poluir o tópico:

 

Visualização - http://www.pradoarts.com.br/imastersform/view.jpg

Edição - http://www.pradoarts.com.br/imastersform/edit.jpg

Especificações (se faltou alguma coisa me avisem por favor) - http://www.pradoarts.com.br/imastersform/details.png

Arquivo completo editável - http://www.pradoarts.com.br/imastersform/imastersform.png

 

 

 

O layout segue um estilo simples e se encaixa com o padrão do iMasters.

 

Como o João me disse que a ideia dele é fazer um editor estilo WYSIWYG, eu fiz de uma forma que a visão que o criador do formulário tem ao editar seja praticamente a mesma visão que tem a pessoa que esta respondendo ao formulário.

 

 

Tentei não ousar muito nos campos de formulário, deixei bem simples e de fácil entendimento.

 

No caso de alguém tentar enviar o formulário sem preencher os campos obrigatórios, a página rola até o campo que precisa ser preenchido e o fundo fica neste tom pastel, que volta ao branco após alguns segundos.

 

 

A parte de edição será exibida quase igual a visualização, exceto pelas opções de edição que aparecem no hover de cada área de pergunta, e as opções de adicionar/excluir pergunta que estão lá no final.

 

 

Espero que tenham gostado, estou aberto a qualquer sugestão para melhoria destes layouts e para a criação do layout da página de resultados.