Como foi o Visual Studio Summit 2013

Visual Studio Summit 2013 – Minhas impressões

No dia 25 de Março ocorreu a segunda edição do Visual Studio Summit realizado em São Paulo na sede da Microsoft. O Visual Studio Summit é um evento feito por desenvolvedores de software, pessoas de todas as partes do Brasil estavam presentes para se atualizar, aprender e conhecer as últimas novidades da plataforma de desenvolvimento Visual Studio.

Estive presente na primeira edição em 2012 como palestrante e nesta edição de 2013 além de palestrar fiz parte da organização/coordenação do evento. Foi uma experiência fantástica poder ajudar a realizar um evento deste porte, é muito mais trabalho que eu imaginava organizar um evento e estou muito satisfeito, pois deu tudo certo.

Alguns números sobre o evento

  • Palestrantes: 25
  • Staff apoio operação: 18
  • Staff Infra estrutura: 8
  • Palestras: 61 palestras
  • Total de horas de conteúdo: 31 horas 
  • Salas: 6 simultâneas e 2 de mini cursos.

O evento iniciou com o keynote do Ramon Durães – 2PC (realizador do evento) e Fernando Martin – Microsoft (gerente do produto Visual Studio).

A audiência foi muito alta, praticamente todos os auditórios lotaram, graças ao método de repetição das palestras em outro horário todos os participantes puderam assistir seus temas escolhidos sem precisar abrir mão de outro.

Todas as palestras foram entregues pontualmente, essa foi uma das nossas maiores preocupações em sinal de respeito aos palestrantes e espectadores. As palestras de 30 minutos foram desenvolvidas para entregar conteúdo de alto impacto. Rodando pelo evento ouvi muitos feedbacks positivos.

Um detalhe que me chamou muito a atenção, o público presente no evento foi de altíssimo nível técnico, profissionais da área que proporcionaram uma incrível troca de conhecimentos, dúvidas muito bem elaboradas, gostei muito de interagir com todos que tive a oportunidade.

Todas as palestras foram gravadas e serão disponibilizadas gratuitamente, em breve publicarei os links aqui.

Ao final do evento conversando com alguns funcionários da Microsoft foi revelado que este foi o maior evento realizado na sede da Microsoft, fico muito feliz por ter feito parte desse acontecimento.

Gostaria de agradecer a todos presentes, palestrantes e staffs, especialmente o time de MSP’s que foram indicados pela Microsoft para apoiar a realização do evento. Todos foram muito prestativos, educados e dedicados. Parabéns a vocês!

Aguardo você na próxima edição 🙂

Links para seguir

7 Dicas para fazer o seu currículo garantir uma entrevista de emprego

Currículo para entrevista

O currículo é o primeiro contato com o empregador. Siga estas dicas para fazer o seu currículo garantir uma entrevista de emprego.

Acredito que você já deva ter um currículo pronto, mas você já parou para pensar se ele está bem feito? Como ele se destaca entre os demais? Se ao menos ele expressa com exatidão o profissional que você é?

Eu analiso muitos currículos semanalmente e garanto a você, tem muito currículo mal feito rodando o mercado, portanto me motivei a escrever este artigo para ajudar você garantir que o seu currículo esteja alinhado com o seu perfil profissional e também com seu interesse em determinado cargo, e claro, conseguir o destaque que precisa para garantir o próximo passo, a entrevista de emprego.

Dica #1 – Escreva um documento bem estruturado

Número de páginas
Antes de começar a escrever estabeleça um foco. Duas páginas são suficientes, salvo o caso que você tenha muita experiência e realizações para contar, mesmo assim procure ficar nas duas páginas, com isso você evita que o seu futuro entrevistador fique entediado e pule partes do seu texto podendo perder alguma informação importante.

• Fonte
A escolha da fonte. Vamos deixar as excentricidades para outro momento e fazer uma escolha assertiva. Fundo branco, letra na cor preta, fonte Times New Roman, Arial ou Verdana tamanho de 10 a 12. Menor do que isto cansa, evite diminuir a fonte para o texto caber nas duas páginas, não tem como saber se a pessoa que vai ler seu currículo tem uma visão boa, não arrisque.

• Cabeçalho
Escreva na primeira linha o seu nome completo, não precisa escrever “currículo”, “curriculum vitae”, isto é desnecessário. Utilize uma fonte maior (tamanho 14 por ex.) utilize negrito como destaque também.

• Parágrafos e quebra de linha
Use parágrafos curtos, 5 linhas cada está bom.
Deixe um bom espaço entre uma linha e outra, assim você evita que a leitura seja cansativa.

currículo bem formatado

Dica #2 – Forneça informações importantes sobre você

• Dados pessoais
Logo abaixo do cabeçalho crie uma estrutura de informações, para economizar espaço utilize duas colunas, uma alinhada à direita e outra à esquerda.
Forneça informações como: Endereço completo, telefones de contato, idade, estado civil, número de filhos também é válido. Na outra coluna forneça informações de contato por meio eletrônico como: e-mail, web site, perfil do linkedIn, Twitter e Facebook.

Forneça o link de seu GitHub com seus projetos, forks e etc, é uma ótima forma de mostrar seu trabalho, algo que está sendo bem valorizado hoje em dia.

* Não forneça foto (a não ser que seja solicitada), números de documentos também são desnecessários.

** Atenção com o perfil de Twitter e Facebook, se você costuma postar informações que possa causar algum constrangimento melhor não informar. Aproveite e comece a prestar atenção nos seus perfis de redes sociais, algumas empresas fazem questão de lhe procurar e analisar o perfil antes de marcar uma entrevista.

*** Tenha um endereço de e-mail sério, endereços como gatinho_solteiro22@hotmail.com definitivamente não são adequados para contato profissional.

Objetivo profissional
Logo abaixo das suas informações pessoais coloque o seu objetivo profissional, seja direto, por exemplo, Objetivo: Analista de Sistemas Sênior.
Procure não colocar mais de um objetivo a não ser que sejam compatíveis, faça seu avaliador entender que seu objetivo é o mesmo da vaga em aberto.

* Procure alinhar o cargo desejado com o anúncio da vaga, isso irá facilitar bastante a análise.

** Caso você atue em mais de uma posição, por exemplo, Analista de sistemas e Coordenador de projetos, faça um formato de currículo para cada um deles, a única exceção é para caso sua vaga seja para atuar exatamente nessas duas direções.

Dica #3 – Seja objetivo em sua apresentação profissional

• Conhecimentos
Inicie com um breve texto, um resumo sobre sua experiência profissional, por exemplo:

“Atuando na área de XXX há mais de 10 anos, possui experiência com X, Y, Z tecnologias,   que foram aplicadas no setor financeiro e automobilístico, conhecimentos avançados em processos XPTO e XYZ”.

* Não faça resumos da sua própria personalidade, (esforçado, persistente, perfeccionista) tudo isso é um julgamento seu de você mesmo, não tem valor para o avaliador.

• Formação acadêmica
Informe dados de graduação, pós graduação, MBA, mestrado e doutorado, por exemplo:

Ciências da Computação – Universidade da Informática
Concluído em 01/08 Ou Cursando, conclusão em 01/14 

• Experiência profissional
Esta é uma das partes mais importantes, onde você já trabalhou diz muito sobre seu perfil, procure enfatizar suas principais tarefas e realizações, por exemplo:

TodoProjects Consulting
Analista de Sistemas Sênior
Período: 06/2010 – Atual
Desenvolvimento em .Net plataforma ASP.Net, liderança técnica de equipe, documentação de sistemas utilizando UML e práticas ágeis.
Neste período entreguei três projetos, sendo um deles um projeto de grande porte com duração de um ano.

Seja direto, procure não florear demais suas realizações e tarefas, foque nos pontos principais, pois com certeza durante a entrevista serão questionados mais detalhes sobre cada atuação.
Não é necessário informar todas as suas experiências, as três últimas costumam ser suficientes, no caso de dúvida, seus últimos 5 anos de experiência são suficientes.

Dica #4 – O que lhe destaca dos demais? O que mais trás na bagagem?

• Idiomas
O domínio de um idioma sempre é um fator que pode ser usado para decidir entre você e um outro candidato, para nossa área é fundamental o conhecimento do inglês (leitura pelo menos). Seja justo na avaliação do seu nível de idioma (básico, avançado, fluente) (leitura, escrita, conversação).

• Cursos complementares
Se você fez um curso de especialização em alguma ferramenta / metodologia / processo, forneça em detalhes, fazem muita diferença, informe a instituição de ensino e a data de conclusão. A carga horária também tem importância.

• Certificações
Forneça em detalhes suas certificações, isso prova que você estudou e comprovou que domina determinado conhecimento. Forneça um meio de acesso para consultar oficialmente estas certificações (por ex Transcript Id).

• Reconhecimentos
São prêmios concedidos por alguma atividade excepcional, em nossa área existem alguns, se você foi premiado com algum título não deixe de fornecer essa informação, com certeza destacará seu currículo entre os demais.

• Palestras, seminários, projetos pessoais
Palestras e seminários importantes para sua área merecem destaque também, eu julgo válido as dos últimos dois anos.
Projetos pessoais, qualquer projeto que envolva sua capacidade profissional vale ser informado, isto demonstra que você gosta do que faz e tem um potencial a ser explorado.

Dica #5 – Não minta, não invente, não aumente, você pode estragar tudo

• Conhecimentos que não consegue comprovar
Esta é uma parte muito importante, nunca minta, o papel aceita tudo o que você colocar, mas pode lhe levar a uma situação muito constrangedora.

Conhecimentos a serem informados são aqueles que realmente você possui algum domínio. É praticamente inevitável a vontade de colocar aquela sigla que todos andam comentando atualmente e você leu sobre em um artigo. Não faça isso.

Recentemente eu tive uma entrevista com um candidato que colocou uma verdadeira sopa de letrinhas no currículo, um profissional que entende de .Net, Java, C++, Python, Delphi, VB6 e etc, já é um pouco suspeito, obviamente existem pessoas com todos esses conhecimentos, mas são raras, ao questionar o candidato ele alegou que alguns conhecimentos eram acadêmicos e outros foram de pequenas experiências.

Isto não é domínio, todas as informações que davam credibilidade a ele passaram a ser duvidosas e isso é muito ruim, uma contratação só ocorre quando há uma confiança de que o candidato é realmente capaz de fazer o que se compromete a fazer.

Resumindo, apesar dos analistas de RH e consultorias de TI que não entendem nada de TI adorarem a sopa de letrinhas, muito cuidado, uma hora você será avaliado por um conhecedor do assunto e poderá perder pontos com ele.

• Cursos e certificações falsas
Pior do que não poder comprovar o conhecimento é não conseguir comprovar um curso ou uma certificação. As certificações possuem uma identidade, pois assim podem ser comprovadas, assim como os cursos, já houveram casos de um candidato ser demitido por justa causa e posteriormente processado, pois alegou possuir diploma universitário e após a contratação a empresa descobriu que não era verdade.

Dica #6 – Faça uma revisão minuciosa antes de enviar

• Ortografia
Sempre revise seu currículo após uma alteração, revise minuciosamente, um erro de ortografia por menor que seja vai saltar aos olhos do avaliador, cause uma ótima impressão entregando um currículo 100% de acordo com o Português.

• Referências
Referências são sempre bem vindas, mas atenção, seu amigo, vizinho ou parente não servem de referência. Uma boa referência é o seu antigo gestor ou um colega de trabalho. Para estas referências informe os meios de contato comerciais, assim você comprova que realmente são referências da sua ex-empresa.

• Pretensão salarial
Informe a pretensão salarial apenas se solicitado, ao final do currículo. Se houver mais de um modelo de contratação coloque sua pretensão para cada um.

Dica #7 – Ao enviar seu currículo entregue também uma carta de apresentação

• Formato do arquivo
Utilize o formato DOC ou PDF, preferencialmente PDF.
Não salve o seu arquivo como Curriculo.pdf, milhares de currículos chegam com esse nome e é mais difícil de pesquisar. Um arquivo Fulano_da_Silva_Curriculo.pdf facilita muito mais a vida do avaliador e por que não a sua também? Faça a diferença.

• Uma breve e cordial apresentação
Ao enviar o currículo escreva no corpo do e-mail uma apresentação, seja breve e cordial.
Não utilize o mesmo texto para todas as empresas, pesquise e cite algo sobre ela. Um exemplo:

Prezado(a),

Em busca de novas oportunidades envio em anexo meu currículo.
A vaga em questão me interessou bastante, acredito ser a oportunidade que estou buscando. O fato da empresa ser reconhecida entre as melhores empresas para se trabalhar é um atrativo muito grande para mim.

Atenciosamente,
Fulano da Silva. 

Evite frases de efeito “Gostaria de uma oportunidade para fazer o meu melhor por esta grande empresa”. Evite definições sobre sua personalidade ou características pessoais.

Dica Extra – Atenção com as consultorias de RH

A maioria das consultorias possuem um padrão de currículo, coisa que acho bom, porém ao adaptar o seu currículo para o modelo padrão da consultoria alguns escorregões podem ocorrer, portanto na hora da entrevista SEMPRE leve algumas cópias impressas do seu currículo original. Digo pela experiência de quem já passou por isso.

Para finalizar

Você pode fazer o download de um modelo de currículo, fique a vontade para usar e distribuir.

Espero que tenha aproveitado as dicas, são frutos de experiências minhas que passo para você com muito prazer.

Referências

  • Algumas informações complementares foram pesquisadas no Portal Exame

Primeiro Aniversário

Primeiro Aniversário do Blog.

primeiro aniversario

Estou muito satisfeito por completar 1 ano escrevendo conteúdos que ajudam as pessoas, interagindo com os visitantes e óbvio aprendendo demais. As vezes penso que sou eu a pessoa que mais aprende com esse blog.

As vezes me perguntam por qual motivo eu tenho esse blog, respondo com certeza, é para dividir conhecimento e ajudar as pessoas a se interessarem por esta maravilhosa área que é a de Desenvolvimento de Software.

Depois de algum tempo com o blog começaram a surgir coisas interessantes, conheci pessoas da área, recebi propostas para palestrar, propostas de emprego ou algum job pontual, mas a maior satisfação é receber o feedback de quem gostou e entrou em contato, é devido a esse feedback que gero motivação para escrever.

Por isso agradeço a cada visitante que acessou meu blog, especialmente aqueles que deixaram um comentário ou entram em contato comigo para conversar mais sobre o assunto. Isso me deixa muito satisfeito e fazem as horas que passo aqui escrevendo e pesquisando valerem a pena.

Vamos aos números do blog nesse primeiro ano:

  • 45 artigos escritos.
  • 143 comentários.
  • 19.384 visitantes únicos.
  • 48.154 page views
  • 3.568 última média mensal (Abril).

Fonte: Google Analytics.

Muito obrigado!!!
Desde o começo do ano estou com o desafio de escrever 50 artigos até 31 de Dezembro, com certeza muito motivado para conquistar esse desafio.

Abraços a todos.

SOLID – Open Closed Principle – OCP

Open Closed Principle, também conhecido como Princípio do Aberto Fechado.

OCP - Open Closed Principle

Este é o segundo princípio do SOLID e certamente o princípio mais polêmico, desconhecido e não utilizado.

Software entities (classes, modules, functions, etc.) should be open for 
extension, but closed for modification

Entidades de software (classes, módulos, funções, etc) devem estar abertas para extensão, mas fechadas para modificação.

Software é evolutivo, raramente um software é feito uma vez e nunca mais será modificado. Sendo assim onde esse princípio tenta chegar?

Extensibilidade

É uma das chaves da orientação a objetos, quando um novo comportamento ou funcionalidade precisar ser adicionado é esperado que as existentes sejam estendidas e e não alteradas, assim o código original permanece intacto e confiável enquanto as novas são implementadas através de extensibilidade. Criar código extensível é uma responsabilidade do desenvolvedor maduro, utilizar design duradouro para um software de boa qualidade e manutenibilidade.

Abstração

Quando aprendemos sobre orientação a objetos com certeza ouvimos sobre abstração, é ela que permite que este princípio funcione. Se um software possui abstrações bem definidas logo ele estará aberto para extensão.

Na prática

Vou usar um exemplo bem simples para podermos entender facilmente como funciona.
Observe esta classe:

public enum TipoDebito { ContaCorrente, Poupanca }

public class Debito
{
    public void Debitar(int valor, TipoDebito tipo)
    {
        if (tipo == TipoDebito.Poupanca)
        {
            // Debita Poupanca
        }
        if (tipo == TipoDebito.ContaCorrente)
        {
            // Debita ContaCorrente
        }
    }
}

É uma classe de débito em conta que valida o tipo da conta para aplicar a regra de negócio correta para conta corrente e para conta poupança. Agora vamos supor que surgiu um novo tipo de débito em conta (conta investimento), logo seria necessário modificar a classe.

Qual é o problema de um IF a mais?
Se modificarmos a classe colocando mais um IF de validação, além de ter que substituirmos esta classe na publicação da nova versão, corremos o risco de introduzir alguns bugs em uma classe que já estava funcionando.

Além de ter que testar todos os tipos de débito em conta, um bug introduzido nesta modificação não pararia apenas o débito em conta investimento mas poderia causar que todos os tipos de débitos parassem de funcionar.

Não queremos isso certo? Na verdade queremos ter o mínimo de trabalho possível e maior garantia de qualidade.

Como deveria ser?

Vamos para um exemplo de um código usando abstração para gerar extensibilidade:

public abstract class Debito
{
    public abstract void Debitar(int valor);
}

public class DebitoContaCorrente : Debito
{
    public override void Debitar(int valor)
    {
        // Debita Conta Corrente
    }
}

public class DebitoContaPoupanca : Debito
{
    public override void Debitar(int valor)
    {
        // Debita Conta Poupança
    }
}

public class DebitoContaInvestimento : Debito
{
    public override void Debitar(int valor)
    {
        // Debita Conta Investimento
    }
}

Veja que possuímos agora uma abstração bem definida, onde todas as extensões implementam suas próprias regras de negócio sem necessidade de modificar uma funcionalidade devido mudança ou inclusão de outra.

O tipo de débito em conta de investimento foi implementado sem modificar nada, usando apenas a extensão. Além de tudo o código está muito mais bonito, entendível e fácil para aplicar cobertura de testes de unidade. Vale mencionar que também está de acordo com o primeiro princípio do SOLID o SRP

Conclusão

Este princípio nos atenta para um melhor design, tornando o software mais extensível e facilitando sua evolução sem afetar a qualidade do que já está desenvolvido.

Para o uso do Open Closed Principle é muito comum utilizarmos o Strategy Pattern do GoF, prometo explicá-lo em outro momento, apenas para não tornar este exemplo muito complexo.

Referências

TFS – Adicionando nova coluna de estado na board.

Adicionando nova coluna de estado na board.

Adicionar nova coluna de estado

No TFS existe como customizar o Workflow de um Work Item como podemos conferir neste artigo que escrevi.

Esse novo estado (foi criado um estado chamado “Testing” no artigo) pode ser atribuído aos Work Items que tiveram seu Workflow modificado, basta abrir o Work Item e selecionar no combo o novo estado.

Após essa implementação com certeza vai surgir outra necessidade, alterar o estado movendo o Work Item na board do TFS. E é isso que vamos aprender neste artigo.

Para isso é necessário editar o arquivo CommonConfiguration.xml do seu template e para acessá-lo basta exportar o arquivo através do comando witadmin

Para encontrar o diretório digite este caminho no Command Prompt:

cd %programfiles%Microsoft Visual Studio 11.0Common7IDE

Em uma edição de 64 bits do windows, substitua %programfiles% com %programfiles(x86)%.

Execute o comando:

witadmin exportcommonprocessconfig /collection:CollectionURL /p:ProjectName /f:"DirectoryPathCommonConfiguration.xml"

CollectionURL especifica a URL de seu Team Project Collection, ProjectName especifica o nome do Team Project, e DirectoryPath especifica o nome e local do arquivo a ser exportado.

Abra o arquivo no notepad e localize o seguinte trecho

  <RequirementWorkItems category="Microsoft.RequirementCategory" plural="Backlog items">
    <States>
      <State value="New" type="Proposed" />
      <State value="Approved" type="Proposed" />
      <State value="Committed" type="InProgress" />
      <State value="Done" type="Complete" />
    </States>
  </RequirementWorkItems>
  <TaskWorkItems category="Microsoft.TaskCategory">
    <States>
      <State value="To Do" type="Proposed" />
      <State value="In Progress" type="InProgress" />
      <State value="Done" type="Complete" />
    </States>
  </TaskWorkItems>

Repare que existem dois blocos, um para itens de Backlog e outro para Tasks, pois existem duas boards, uma de Backlog e outra de Tasks.

Escolha o bloco referente ao tipo de Work Item que foi editado e adicione uma nova linha, esta linha vai receber o valor do novo estado, porém o tipo nesse caso permanece “In Progress”, pois não trata-se do final de um ciclo.

No exemplo abaixo adicionei uma nova coluna para as duas boards.

  <RequirementWorkItems category="Microsoft.RequirementCategory" plural="Backlog items">
    <States>
      <State value="New" type="Proposed" />
      <State value="Approved" type="Proposed" />
      <State value="Committed" type="InProgress" />
      <State value="Testing" type="InProgress" />
      <State value="Done" type="Complete" />
    </States>
  </RequirementWorkItems>
  <TaskWorkItems category="Microsoft.TaskCategory">
    <States>
      <State value="To Do" type="Proposed" />
      <State value="In Progress" type="InProgress" />
      <State value="Testing" type="InProgress" />
      <State value="Done" type="Complete" />
    </States>
  </TaskWorkItems>

O arquivo já está modificado e pronto para ser importado. Utilize o comando de importação com os mesmos parâmetros utilizados para sua exportação:

witadmin importcommonprocessconfig /collection:CollectionURL /p:ProjectName /f:"DirectoryPathCommonConfiguration.xml"

Pressione F5 na board modificada para conferir a inclusão da nova coluna.

Atenção: O valor “nome” da coluna adicionada deve ser exatamente o mesmo do estado criado no Workflow. Para arrastar um Work Item para a nova coluna lembre-se que é necessário existir no Workflow uma transição de estados entre o estado atual e o novo.

Feedback, sugestões, dúvidas utilize o campo de comentário logo abaixo 🙂

Referências

SOLID – Single Responsibility Principle – SRP

Single Responsibility Principle, também conhecido como Princípio da Responsabilidade Única.

SOLID - Single Responsibility Principle - SRP

Este é o primeiro princípio do SOLID, um dos mais fáceis de entender e de aplicar.

"A class should have one, and only one, reason to change"

“Uma classe deve ter um, e apenas um, motivo para ser modificada”

Se uma classe só deve ter um motivo para ser modificada, certamente ela só deve ter uma única responsabilidade, logo:

Cada responsabilidade deve ser uma classe, porque uma responsabilidade é um eixo de mudança.

Veja esta classe:

public class DebitoContaCorrente
{
    public void ValidarSaldo(int valor) { }

    public void DebitarConta(int valor) { }

    public void EmitirComprovante() { }
}

O que esta classe faz?

Esta classe valida saldo em conta e debita valor da conta e emite comprovante.

Esta classe possui três responsabilidades, ou seja, ela tem três razões para ser modificada, problemas a vista, vamos imaginar que por algum motivo a regra de negócio da emissão de comprovante mudou, logo para aplicar a nova regra seria necessário modificar a classe DebitoContaCorrente.

Se por um acaso na modificação da classe algum bug não identificado foi para a produção não apenas a emissão de comprovante, mas sim todas as funcionalidades da classe poderiam estar comprometidas. O sistema deixaria de fazer o débito devido um problema com o comprovante.

Esse é apenas um exemplo de como o acoplamento pode trazer problemas, testes de unidade seriam muito mais complexos de serem desenvolvidos (e menos eficazes).
Ao modificar esta classe vários testes de integração necessitariam ser executados para garantir que uma funcionalidade não comprometeu as demais.

Alguns benefícios do Single Responsibility Principle:

  • Complexidade do código reduzida, mais explícita e direta;
  • Facilitação da legibilidade;
  • Redução de acoplamento;
  • Código limpo e testável;
  • Facilidade de evolução.

Como deveria ser?

Veja como a classe poderia ficar após um refactoring de aplicação do Single Responsibility Principle:

public class DebitoContaCorrente
{
    public void DebitarConta(int valor) { }
}

public class SaldoContaCorrente
{
    public void ValidarSaldo(int valor) { }
}

public class ComprovanteContaCorrente
{
    public void EmitirComprovante() { }
}

Cada classe com sua responsabilidade.
No início isso pode parecer exagero, mas não é, isto é uma promoção da qualidade do código e uma ótima maneira de obter os benefícios citados acima.

Conclusão

O Single Responsibility Principle é um dos mais importantes princípios do SOLID, deve ser aplicado para obtermos classes mais coesas e de baixo acoplamento.

Este é o tipo de princípio que todo código orientado a objetos deveria possuir.
Portanto antes de construir aquela classe que cadastra o usuário e envia o e-mail, lembre-se deste princípio.

Referências