Nesta apresentação é abordado o Princípio SRP (Single Responsibility Principle - Princípio de Única Responsabilidade) do Grupo de Princípios SOLID de boas práticas de Design de Software Orientado à Objetos.
Slides da palestra sobre Orientação a Objetos e Princípios SOLID: "Não sabemos nada sobre isso", por Vinicius Quaiato na IV Semana de Tecnologia do IFSP.
Aqui são apresentados conceitos básicos sobre o paradigma web. Simples e rápido.
/**Depois que entrei no mundo Java, começei a procurar por conteúdo na internet para estudar, então me deparei com um ótimo site, http://www.argonavis.com.br, de um grande cara chamado Helder Rocha, que disponibiliza este mesmo conteúdo em seu site também. Obrigado pela ajuda a comunidade.*/
Slides da palestra sobre Orientação a Objetos e Princípios SOLID: "Não sabemos nada sobre isso", por Vinicius Quaiato na IV Semana de Tecnologia do IFSP.
Aqui são apresentados conceitos básicos sobre o paradigma web. Simples e rápido.
/**Depois que entrei no mundo Java, começei a procurar por conteúdo na internet para estudar, então me deparei com um ótimo site, http://www.argonavis.com.br, de um grande cara chamado Helder Rocha, que disponibiliza este mesmo conteúdo em seu site também. Obrigado pela ajuda a comunidade.*/
Um dos pilares da orientação a objetos, o Encapsulamento é o conceito responsável pela definição de acessos as classes e seus métodos e atributos. Juntamente com a Herança e o Polimorfismo, itens essenciais a compreensão deste paradigma de programação.
Este trabalho apresenta um exemplo de uso dos Padrões J2EE em
um projeto de software, identificando as melhorias no desenvolvimento e na
implementação de um software com a utilização das boas práticas J2EE
Blueprints, destacando a modelagem de um sistema que utiliza essa
plataforma.
Design de aplicações orientadas a objetoElaine Naomi
Modelamos aplicações Ruby como um conjunto de objetos interagindo entre si para resolver um problema.
Quando propomos uma solução, ela geralmente é validada dentro de um escopo específico.
Mas mudanças sempre acontecem: no código, nas regras de negócio, na vida, no universo e em tudo mais.
Com essas mudanças, será que uma solução inicialmente proposta continua sendo válida? Se não for, o código implementado está preparado para evoluir e agregar novos comportamentos de maneira saudável?
Nesta talk, vamos analisar princípios e padrões de design de aplicações orientadas a objeto e como podemos aplicá-los no dia a dia a fim de tornar nosso código mais flexível e com maior qualidade.
21/07/2018
Implementing Product Line VariabilitiesMichel Alves
A abordagem de linha de produto de software tem como objetivo principal promover a geração de produtos específicos com base na reutilização de uma infra-estrutura central. Uma linha de produto representa um conjunto de sistemas que compartilham características comuns e gerenciáveis que satisfazem as necessidades de um segmento particular do mercado ou de uma missão. Esse conjunto de sistemas é também chamado de família de produtos. Os membros da família são produtos específicos desenvolvidos de maneira sistemática a partir de um conjunto comum de artefatos da linha de produto.
Um dos pilares da orientação a objetos, o Encapsulamento é o conceito responsável pela definição de acessos as classes e seus métodos e atributos. Juntamente com a Herança e o Polimorfismo, itens essenciais a compreensão deste paradigma de programação.
Este trabalho apresenta um exemplo de uso dos Padrões J2EE em
um projeto de software, identificando as melhorias no desenvolvimento e na
implementação de um software com a utilização das boas práticas J2EE
Blueprints, destacando a modelagem de um sistema que utiliza essa
plataforma.
Design de aplicações orientadas a objetoElaine Naomi
Modelamos aplicações Ruby como um conjunto de objetos interagindo entre si para resolver um problema.
Quando propomos uma solução, ela geralmente é validada dentro de um escopo específico.
Mas mudanças sempre acontecem: no código, nas regras de negócio, na vida, no universo e em tudo mais.
Com essas mudanças, será que uma solução inicialmente proposta continua sendo válida? Se não for, o código implementado está preparado para evoluir e agregar novos comportamentos de maneira saudável?
Nesta talk, vamos analisar princípios e padrões de design de aplicações orientadas a objeto e como podemos aplicá-los no dia a dia a fim de tornar nosso código mais flexível e com maior qualidade.
21/07/2018
Implementing Product Line VariabilitiesMichel Alves
A abordagem de linha de produto de software tem como objetivo principal promover a geração de produtos específicos com base na reutilização de uma infra-estrutura central. Uma linha de produto representa um conjunto de sistemas que compartilham características comuns e gerenciáveis que satisfazem as necessidades de um segmento particular do mercado ou de uma missão. Esse conjunto de sistemas é também chamado de família de produtos. Os membros da família são produtos específicos desenvolvidos de maneira sistemática a partir de um conjunto comum de artefatos da linha de produto.
In this presentation André Faria, CEO at Bluesoft, presented to his team a introduction to the AWS ecosystem and talked about all the new announcements AWS have made in the event AWS re:Invent 2017 that took place in Las Vegas.
Boas Práticas para Supermercadistas inspiradas no Whole Foods, Sprouts Marke...André Faria Gomes
Nessa apresentação André Faria, CEO da Bluesoft, apresenta alguns diferenciais de Redes Americanas de Supermercados como Whole Foods, Sprouts Market e Trader Joe's que podem servir de inspiração para Supermercadistas Brasileiros.
Depois de mais de 10 anos aplicando métodos ágeis no seu dia-a-dia em diversas equipes e organizações. André Faria, compartilha seus principais aprendizados.
6. Um exemplo popular que “viola” o
princípio é o ActiveRecord*, que
mistura persistência com regras de
negócio.
*Active Record é utilizado com muito
sucesso em muitos aplicativos.
Lembre-se é só um guideline.
7. Se uma regra de negócio muda e faz com uma
determinada classe mude, então uma mudança no
esquema do banco de dados, na GUI, no formato do
relatório, ou em qualquer outra área do sistema não
deve fazer com essa mesma classe mude.
8. class Funcionario
{
public Dinheiro calcularPagamento() {...}
public void salvar() {...}
public String reportarHoras() {...}
}
13. Não é bom ter que modificar a classe
Funcionario toda vez que alguém decidir
mudar o formato do relatório de
horas, ou toda vez que o DBA fizer uma
mudança no schema do banco de
dados, ou toda vez que as regras de
cálculo de pagamento forem
alteradas.
14. É melhor, separarmos essas diferentes funcionalidades em
classes distintas, de forma que cada classes possa ser alterar
de forma independente umas da outras.
15. class CalculadoraDePagamento {
public Dinheiro calcularPagamento() {...}
}
class RelatorioDeHoras {
public String reportarHoras() {...}
}
class FuncionarioDao {
public void salvar() {...}
}
16. 1 SRP in Ruby
2
http://butunclebob.com/ArticleS.UncleBob.SrpInRuby