O documento apresenta uma introdução aos padrões de projeto de software orientado a objetos. Discute a inspiração dos padrões de Christopher Alexander, o livro "Gang of Four" que catalogou 23 padrões comumente usados e o formato de descrição de cada padrão. Apresenta o padrão Abstract Factory como exemplo, descrevendo seu objetivo, estrutura, participantes e implementação.
Padrões de Projeto de Software Orientado a ObjetosCloves da Rocha
O documento apresenta o tema Padrões de Projeto de Software Orientados a Objetos. Discute a inspiração dos padrões de projeto, o catálogo de soluções conhecido como Gang of Four e o formato de descrição dos padrões. Apresenta o padrão Abstract Factory como exemplo, descrevendo seu objetivo, estrutura, participantes e implementação.
O documento discute Design Patterns, estruturas de projeto reutilizáveis em programação orientada a objetos. Apresenta o que são Design Patterns, incluindo sua popularização após o livro "Design Patterns" de 1994, e lista 23 padrões comuns. Exemplos de Factory Method, Adapter e Observer são explicados detalhadamente ilustrando suas características e aplicações.
Padrões de projeto (design patterns) foram criados originalmente para engenharia civil e foram aplicados à engenharia de software para melhorar a qualidade e reduzir custos de manutenção. O livro "Design Patterns" classificou padrões em criação, estruturais e comportamentais. A aplicação de padrões traz benefícios como confiabilidade, redução de custos e legibilidade, apesar de potencial complexidade inicial.
O documento discute padrões de projeto de software, incluindo o Gang of Four que descreveu 23 padrões. Ele explica brevemente cinco padrões: template method, strategy, observer, singleton e iterator.
Refatoração refere-se à reestruturação do código-fonte de um software sem alterar seu comportamento externo, visando melhorar aspectos como legibilidade, manutenibilidade e design. O documento descreve os princípios e origens da refatoração, exemplos de técnicas como renomear variáveis e extrair métodos, além de discutir vantagens como redução de duplicação e aumento da simplicidade do código.
O documento apresenta uma introdução sobre padrões de projeto, definindo-os como estruturas recorrentes no projeto de software orientado a objetos. Descreve brevemente os principais tipos de padrões (criação, estruturais e comportamentais) e alguns exemplos de cada um. Por fim, fornece referências adicionais sobre padrões de projeto.
O documento apresenta os conceitos e objetivos do desenvolvimento orientado a testes (TDD). O TDD é uma metodologia que propõe escrever testes unitários antes de implementar o código, seguindo os passos vermelho-verde-refatoração. O documento explica os benefícios do TDD, como código de melhor qualidade e facilidade de refatoração.
Padrões de projeto - Adapter, Proxy, Composite e BridgeLorran Pegoretti
O documento discute padrões de projeto de software, abordando especificamente os padrões Adapter, Proxy e Composite. O Adapter permite que classes com interfaces incompatíveis trabalhem juntas, o Proxy controla o acesso a um objeto e o Composite trata objetos compostos e individuais de forma uniforme.
Padrões de Projeto de Software Orientado a ObjetosCloves da Rocha
O documento apresenta o tema Padrões de Projeto de Software Orientados a Objetos. Discute a inspiração dos padrões de projeto, o catálogo de soluções conhecido como Gang of Four e o formato de descrição dos padrões. Apresenta o padrão Abstract Factory como exemplo, descrevendo seu objetivo, estrutura, participantes e implementação.
O documento discute Design Patterns, estruturas de projeto reutilizáveis em programação orientada a objetos. Apresenta o que são Design Patterns, incluindo sua popularização após o livro "Design Patterns" de 1994, e lista 23 padrões comuns. Exemplos de Factory Method, Adapter e Observer são explicados detalhadamente ilustrando suas características e aplicações.
Padrões de projeto (design patterns) foram criados originalmente para engenharia civil e foram aplicados à engenharia de software para melhorar a qualidade e reduzir custos de manutenção. O livro "Design Patterns" classificou padrões em criação, estruturais e comportamentais. A aplicação de padrões traz benefícios como confiabilidade, redução de custos e legibilidade, apesar de potencial complexidade inicial.
O documento discute padrões de projeto de software, incluindo o Gang of Four que descreveu 23 padrões. Ele explica brevemente cinco padrões: template method, strategy, observer, singleton e iterator.
Refatoração refere-se à reestruturação do código-fonte de um software sem alterar seu comportamento externo, visando melhorar aspectos como legibilidade, manutenibilidade e design. O documento descreve os princípios e origens da refatoração, exemplos de técnicas como renomear variáveis e extrair métodos, além de discutir vantagens como redução de duplicação e aumento da simplicidade do código.
O documento apresenta uma introdução sobre padrões de projeto, definindo-os como estruturas recorrentes no projeto de software orientado a objetos. Descreve brevemente os principais tipos de padrões (criação, estruturais e comportamentais) e alguns exemplos de cada um. Por fim, fornece referências adicionais sobre padrões de projeto.
O documento apresenta os conceitos e objetivos do desenvolvimento orientado a testes (TDD). O TDD é uma metodologia que propõe escrever testes unitários antes de implementar o código, seguindo os passos vermelho-verde-refatoração. O documento explica os benefícios do TDD, como código de melhor qualidade e facilidade de refatoração.
Padrões de projeto - Adapter, Proxy, Composite e BridgeLorran Pegoretti
O documento discute padrões de projeto de software, abordando especificamente os padrões Adapter, Proxy e Composite. O Adapter permite que classes com interfaces incompatíveis trabalhem juntas, o Proxy controla o acesso a um objeto e o Composite trata objetos compostos e individuais de forma uniforme.
O documento introduz os padrões de projetos GoF e Core J2EE, definindo o que são padrões de projeto e como surgem, e descrevendo alguns padrões específicos como Abstract Factory, Singleton, Template Method, Front Controller, Business Delegate e Domain Store. A conclusão questiona se alguns padrões ainda se aplicam com novas tecnologias.
Este documento descreve um curso de Android dividido em módulos. O primeiro módulo apresenta a plataforma Android, o IDE Eclipse, o SDK e o emulador Android. Ensina a criar e executar projetos no Eclipse com múltiplas activities. Instrui a editar layouts e recursos visuais usando arquivos XML e a executar aplicativos no emulador.
O padrão Facade simplifica a interface de um subsistema, provendo uma interface unificada para ele. O padrão define uma interface de mais alto nível que torna o subsistema mais fácil de ser usado, reduzindo a complexidade e dependências entre o subsistema e seus clientes. Uma classe Facade atua como intermediária entre o subsistema e os clientes, orquestrando o trabalho das classes do subsistema.
O documento discute padrões de projeto e anti-padrões. Apresenta padrões arquiteturais, de projeto e comportamentais com exemplos. Também descreve anti-padrões de arquitetura, desenvolvimento e gerência, indicando problemas comuns e soluções. O conhecimento de padrões e anti-padrões permite projetar sistemas de melhor qualidade e evitar surpresas.
O documento discute os fundamentos de projeto orientado a objetos, padrões de projeto e anti-padrões. Ele aborda tópicos como herança, polimorfismo, interfaces, classificações de padrões e como padrões podem ajudar a resolver problemas comuns de software.
Padrões de Projeto - Design Patterns e Anti-PatternsRodrigo Kono
Esta track irá abordar o que você precisa fazer para reduzir significativamente as falhas de desenvolvimento de software e como reparar as suas causas para que eles não reapareçam. O lema é aprender com os erros! AntiPatterns destacam os problemas mais comuns que a indústria de software enfrenta e ao mesmo tempo fornece as soluções para que você possa reconhecer esses problemas, mostrando que o Software Configuration Management (SCM) não é nem muito duro e nem muito complicado.
Test-Driven Development - Introdução ao método de construção de software guia...Thiago Faria de Andrade
O documento resume uma palestra sobre Test Driven Development (TDD). Aborda o que é TDD, seus benefícios e padrões, como escrever testes e refatorar código mantendo os testes verdes. O objetivo é ensinar como aplicar TDD de forma efetiva para construir software de qualidade.
Este documento fornece uma introdução à análise orientada a objetos, discutindo conceitos como modelagem de domínio, modelagem eficiente, conhecimento compartilhado e implementação iterativa. Inclui exemplos de modelagem de sistemas como um simulador de rotas de rede.
O documento descreve o padrão de projeto Abstract Factory. O padrão fornece uma interface para criação de famílias de objetos relacionados sem especificar suas classes concretas, permitindo que sistemas sejam independentes de como seus produtos são criados e representados. O padrão isola classes concretas dos clientes e facilita a troca de famílias de produtos.
O documento discute o desenvolvimento de sistemas utilizando a Linguagem de Modelagem Unificada (UML). A UML foi criada para padronizar a modelagem orientada a objetos, unificando as melhores partes de metodologias existentes como Booch, OMT e OOSE/Objectory. A UML pode ser usada em todas as fases do desenvolvimento de software, desde a análise de requisitos até os testes, e serve para modelar diferentes tipos de sistemas.
O documento fornece uma introdução sobre Test Driven Development (TDD) em 3 frases:
TDD é uma metodologia de desenvolvimento de software que utiliza testes para guiar o processo de desenvolvimento de forma incremental, maximizando a qualidade do código e simplificando o processo. O framework JUnit é utilizado para automatizar a execução dos testes unitários escritos, permitindo validar o código a cada nova funcionalidade implementada. A abordagem TDD promove o refinamento contínuo do código através de sucessivas etapas de escrita de testes,
O documento discute os princípios de código limpo, incluindo: (1) código limpo deve ser eficiente e ter lógica direta para minimizar bugs, (2) deve ter poucas dependências, e (3) deve ser legível para facilitar manutenção. Ele também fornece dicas como usar nomes significativos e formatar código claramente.
O documento discute padrões de projeto de software. Apresenta uma introdução sobre o que são padrões de projeto e sua motivação. Também descreve conceitos básicos como atributos, problemas resolvidos e tipos de padrões.
O documento apresenta uma introdução sobre Design Patterns, descrevendo os desafios da área de software e a necessidade de padrões para resolver problemas comuns. Apresenta os 23 padrões descritos no livro "Design Patterns" divididos em três categorias: Criação, Estrutura e Comportamento. Resume cada categoria listando os padrões e suas finalidades.
O documento discute padrões de projeto, ferramentas e métodos ágeis. Apresenta padrões de projeto inspirados por Christopher Alexander e o livro "Padrões de Projeto" de Gamma et al. Discutem categorias de padrões como criação, estrutural e comportamental e princípios como programar para interfaces. Exemplos incluem um jogo RPG e o padrão Singleton.
O documento descreve o padrão de projeto Abstract Factory, que fornece uma interface para criação de objetos delegando instanciações para subclasses. Ele é aplicado em um cenário de serviços bancários de um caixa eletrônico, onde a fábrica abstrata cria produtos como extratos e saldos de forma diferente para cada banco concreto, mantendo a aplicação cliente independente de implementações específicas.
Uma palestra "vintage" apresentada na Borland Conference 2004. Foi apresentada em uma trilha de desenvolvedores Java, onde depois desta apresentação, mostrei com live coding alguns patterns implementados com a linguagem Java, usando o JBuilder.
O foco da palestra foi nos GoF Patterns mas também comentei sobre outros repositórios de padrões que usava como referência na época. :)
O documento descreve a história e conceitos dos padrões de projeto orientados a objetos. Christopher Alexander cunhou o termo "padrões de projeto" para descrever soluções comuns a problemas recorrentes. Os padrões GoF tornaram-se populares em 1995 e descrevem padrões criacionais, estruturais e comportamentais.
O documento discute os vários níveis de reutilização na perspectiva de frameworks e padrões de projeto. Aborda a reutilização nos paradigmas funcional e orientado a objetos, conceitos como classe, herança, composição e componentes. Também discute frameworks, tipos, vantagens e desvantagens, além de padrões de projeto comuns em frameworks como Template Method e Abstract Factory.
O documento descreve a história e conceitos de padrões de projeto de software. Apresenta os 23 padrões de projeto documentados no livro "Design Patterns" de 1995, divididos nas categorias criacionais, comportamentais e estruturais. Explica brevemente alguns padrões como Singleton, Factory Method, Observer, Composite e MVC.
Módulo 9 - Introdução à Programação Orientada a Objectos Luis Ferreira
Características da Programação Orientada por Objetos (POO).
Conceito de Classe, Atributos, Métodos, e Eventos.
Conceito de Objeto.
Conceito de Encapsulamento.
Conceito de Visibilidade de Classes, Métodos e Atributos.
Diagramas de Classe.
O ambiente de trabalho do Visual C#.
Objetos básicos e outras características básicas da linguagem do Visual C# e respetivo ambiente de trabalho.
O documento introduz os padrões de projetos GoF e Core J2EE, definindo o que são padrões de projeto e como surgem, e descrevendo alguns padrões específicos como Abstract Factory, Singleton, Template Method, Front Controller, Business Delegate e Domain Store. A conclusão questiona se alguns padrões ainda se aplicam com novas tecnologias.
Este documento descreve um curso de Android dividido em módulos. O primeiro módulo apresenta a plataforma Android, o IDE Eclipse, o SDK e o emulador Android. Ensina a criar e executar projetos no Eclipse com múltiplas activities. Instrui a editar layouts e recursos visuais usando arquivos XML e a executar aplicativos no emulador.
O padrão Facade simplifica a interface de um subsistema, provendo uma interface unificada para ele. O padrão define uma interface de mais alto nível que torna o subsistema mais fácil de ser usado, reduzindo a complexidade e dependências entre o subsistema e seus clientes. Uma classe Facade atua como intermediária entre o subsistema e os clientes, orquestrando o trabalho das classes do subsistema.
O documento discute padrões de projeto e anti-padrões. Apresenta padrões arquiteturais, de projeto e comportamentais com exemplos. Também descreve anti-padrões de arquitetura, desenvolvimento e gerência, indicando problemas comuns e soluções. O conhecimento de padrões e anti-padrões permite projetar sistemas de melhor qualidade e evitar surpresas.
O documento discute os fundamentos de projeto orientado a objetos, padrões de projeto e anti-padrões. Ele aborda tópicos como herança, polimorfismo, interfaces, classificações de padrões e como padrões podem ajudar a resolver problemas comuns de software.
Padrões de Projeto - Design Patterns e Anti-PatternsRodrigo Kono
Esta track irá abordar o que você precisa fazer para reduzir significativamente as falhas de desenvolvimento de software e como reparar as suas causas para que eles não reapareçam. O lema é aprender com os erros! AntiPatterns destacam os problemas mais comuns que a indústria de software enfrenta e ao mesmo tempo fornece as soluções para que você possa reconhecer esses problemas, mostrando que o Software Configuration Management (SCM) não é nem muito duro e nem muito complicado.
Test-Driven Development - Introdução ao método de construção de software guia...Thiago Faria de Andrade
O documento resume uma palestra sobre Test Driven Development (TDD). Aborda o que é TDD, seus benefícios e padrões, como escrever testes e refatorar código mantendo os testes verdes. O objetivo é ensinar como aplicar TDD de forma efetiva para construir software de qualidade.
Este documento fornece uma introdução à análise orientada a objetos, discutindo conceitos como modelagem de domínio, modelagem eficiente, conhecimento compartilhado e implementação iterativa. Inclui exemplos de modelagem de sistemas como um simulador de rotas de rede.
O documento descreve o padrão de projeto Abstract Factory. O padrão fornece uma interface para criação de famílias de objetos relacionados sem especificar suas classes concretas, permitindo que sistemas sejam independentes de como seus produtos são criados e representados. O padrão isola classes concretas dos clientes e facilita a troca de famílias de produtos.
O documento discute o desenvolvimento de sistemas utilizando a Linguagem de Modelagem Unificada (UML). A UML foi criada para padronizar a modelagem orientada a objetos, unificando as melhores partes de metodologias existentes como Booch, OMT e OOSE/Objectory. A UML pode ser usada em todas as fases do desenvolvimento de software, desde a análise de requisitos até os testes, e serve para modelar diferentes tipos de sistemas.
O documento fornece uma introdução sobre Test Driven Development (TDD) em 3 frases:
TDD é uma metodologia de desenvolvimento de software que utiliza testes para guiar o processo de desenvolvimento de forma incremental, maximizando a qualidade do código e simplificando o processo. O framework JUnit é utilizado para automatizar a execução dos testes unitários escritos, permitindo validar o código a cada nova funcionalidade implementada. A abordagem TDD promove o refinamento contínuo do código através de sucessivas etapas de escrita de testes,
O documento discute os princípios de código limpo, incluindo: (1) código limpo deve ser eficiente e ter lógica direta para minimizar bugs, (2) deve ter poucas dependências, e (3) deve ser legível para facilitar manutenção. Ele também fornece dicas como usar nomes significativos e formatar código claramente.
O documento discute padrões de projeto de software. Apresenta uma introdução sobre o que são padrões de projeto e sua motivação. Também descreve conceitos básicos como atributos, problemas resolvidos e tipos de padrões.
O documento apresenta uma introdução sobre Design Patterns, descrevendo os desafios da área de software e a necessidade de padrões para resolver problemas comuns. Apresenta os 23 padrões descritos no livro "Design Patterns" divididos em três categorias: Criação, Estrutura e Comportamento. Resume cada categoria listando os padrões e suas finalidades.
O documento discute padrões de projeto, ferramentas e métodos ágeis. Apresenta padrões de projeto inspirados por Christopher Alexander e o livro "Padrões de Projeto" de Gamma et al. Discutem categorias de padrões como criação, estrutural e comportamental e princípios como programar para interfaces. Exemplos incluem um jogo RPG e o padrão Singleton.
O documento descreve o padrão de projeto Abstract Factory, que fornece uma interface para criação de objetos delegando instanciações para subclasses. Ele é aplicado em um cenário de serviços bancários de um caixa eletrônico, onde a fábrica abstrata cria produtos como extratos e saldos de forma diferente para cada banco concreto, mantendo a aplicação cliente independente de implementações específicas.
Uma palestra "vintage" apresentada na Borland Conference 2004. Foi apresentada em uma trilha de desenvolvedores Java, onde depois desta apresentação, mostrei com live coding alguns patterns implementados com a linguagem Java, usando o JBuilder.
O foco da palestra foi nos GoF Patterns mas também comentei sobre outros repositórios de padrões que usava como referência na época. :)
O documento descreve a história e conceitos dos padrões de projeto orientados a objetos. Christopher Alexander cunhou o termo "padrões de projeto" para descrever soluções comuns a problemas recorrentes. Os padrões GoF tornaram-se populares em 1995 e descrevem padrões criacionais, estruturais e comportamentais.
O documento discute os vários níveis de reutilização na perspectiva de frameworks e padrões de projeto. Aborda a reutilização nos paradigmas funcional e orientado a objetos, conceitos como classe, herança, composição e componentes. Também discute frameworks, tipos, vantagens e desvantagens, além de padrões de projeto comuns em frameworks como Template Method e Abstract Factory.
O documento descreve a história e conceitos de padrões de projeto de software. Apresenta os 23 padrões de projeto documentados no livro "Design Patterns" de 1995, divididos nas categorias criacionais, comportamentais e estruturais. Explica brevemente alguns padrões como Singleton, Factory Method, Observer, Composite e MVC.
Módulo 9 - Introdução à Programação Orientada a Objectos Luis Ferreira
Características da Programação Orientada por Objetos (POO).
Conceito de Classe, Atributos, Métodos, e Eventos.
Conceito de Objeto.
Conceito de Encapsulamento.
Conceito de Visibilidade de Classes, Métodos e Atributos.
Diagramas de Classe.
O ambiente de trabalho do Visual C#.
Objetos básicos e outras características básicas da linguagem do Visual C# e respetivo ambiente de trabalho.
1. O documento apresenta Rodrigo Branas, palestrante e instrutor de Domain-Driven Design.
2. Ele tem formação em Ciências da Computação e Gerenciamento de Projetos e trabalhou com grandes empresas.
3. Domain-Driven Design é abordado, focando na importância de entender profundamente o domínio do negócio através da linguagem ubíqua e do modelo de domínio.
O documento discute práticas para melhoria contínua de programadores, incluindo refatoração, testes automatizados, e comunicação com usuários. Ele enfatiza uma abordagem pragmática e iterativa ao desenvolvimento de software.
Estratégias de Estruturação de Código-fonte e Controlo de VersãoComunidade NetPonto
Muitas das dificuldades no desenvolvimento profissional de software são causadas por problemas (ou a falta de) um correcto sistema e uso de controlo de versões. Nesta apresentação o Tiago Pascoal, MVP em Visual Studio Team System, irá mostrar estratégias sobre como melhor estruturar todos os artefactos de um projecto, incluindo melhores práticas para uso de controlo de versões, tendo por base a plataforma de Application Lifecycle Management da Microsoft (Team Foundation Server / TFS).
A análise e modelagem de software não é uma atividade simples, quando o domínio do software não é algo trivial e mais complicado ainda. O Domain Driven Design sugere uma nova abordagem para resolver estas tarefas, criando uma linguagem única para todas as pessoas envolvidas no projeto.
Nesta palestra buscamos conhecer um pouco mais sobre essa abordagem e quais ferramentas temos para aplicá-la utilizando PHP.
O documento discute a avaliação de qualidade de linha de produto de software baseada em arquitetura e métricas. Apresenta definições de linha de produto de software e suas características, etapas de desenvolvimento e abordagens de gerenciamento de variabilidades. Também descreve diferentes momentos e técnicas para avaliação de qualidade de linha de produto de software, com foco na avaliação arquitetural por meio de métricas.
Nesta apresentação é exibido os principais padrões de projetos para criação de um software baseado em programação orientada a objetos escalável e de forma evolutiva.
Domain-Driven Design não é uma tecnologia ou metodologia. DDD é uma abordagem à modelação de software que providencia uma estrutura de práticas, padrões de programação e terminologias que ajudam à sua concepção.
Nesta sessão vamos conhecer o que é Domain-Driven Design, quando o usar e como implementar.
Um padrão é a solução para um determinado problema em um determinado contexto. Um padrão codifica conhecimento específico obtido em uma experiência em um determinado domínio. Um sistema bem estruturado estará cheio de padrões: de linguagem; de projeto; e de arquitetura. Segundo Fowler, podem ser utilizados para melhorar o entendimento ou comunicação dos problemas e decisões arquiteturais. Podem ser vistos como uma tentativa de criar um vocabulário comum para comunicação.
Um padrão que se deve ter conhecimento na orientação a objetos é o GRASP que significa General Responsability Assignment Software Patterns e que descreve os princípios fundamentais do design orientado a objetos e a atribuição de responsabilidades. Outro padrão é o de Gamma, et al que descreve vinte e três padrões clássicos na orientação a objetos. O padrão de Gamma é mais conhecido como padrão da gangue dos quatro (Gang of Four patterns, ou apenas GoF).
Construção de Frameworks com Annotation e Reflection API em JavaFernando Camargo
Para acessar um método protected de uma superclasse usando reflection, precisamos desabilitar o mecanismo de verificação de visibilidade (acess check) antes de invocar o método. Isso pode ser feito chamando o método setAccessible(true) no objeto Method antes da invocação.
[1] O documento discute conceitos importantes de projeto como modularidade, encapsulamento, independência funcional, coesão e acoplamento que levam a um software de alta qualidade.
[2] Também aborda padrões de projeto, refatoração e projeto orientado a objetos, incluindo classes de entidades, fronteiras e controle.
[3] O objetivo é fornecer diretrizes para o projeto de software que implemente requisitos, seja compreensível e apresente a arquitetura de forma modular e de baixa complexidade.
Semelhante a Padrões de Projeto de Software Orientado a Objetos (20)
Evidence-based Public Policymaking in Smart CitiesFabio Kon
O documento discute as definições de cidades inteligentes e como a tecnologia, como internet das coisas, computação em nuvem e big data, podem ser usadas para melhorar a qualidade de vida dos cidadãos de forma sustentável. Exemplos mostram como a integração de dados sobre mobilidade, saúde e esporte podem gerar novas políticas públicas baseadas em evidências.
Automatic Configuration of Component-Based Distributed SystemsFabio Kon
PhD thesis defense at the University of Illinois.
It covers software architecture, reflective middleware, dynamic configuration, object-orientation, and systems performance.
The technology is applied to use cases in video streaming, mobile and pervasive computing, and communication middleware.
O documento discute empreendedorismo em startups de software, comparando o ecossistema de startups de Israel com o Brasil. Apresenta as vantagens de startups, define o que é uma startup, e descreve a metodologia de pesquisa qualitativa realizada, que incluiu entrevistas e visitas a startups em Israel. Também lista 10 mandamentos de como falhar em uma startup e discute os desafios e oportunidades do empreendedorismo de alta tecnologia no Brasil.
Cidades Inteligentes: Interdisciplinaridade, Software Livre, Dados Abertos e ...Fabio Kon
O documento discute o conceito de cidades inteligentes, abordando tópicos como: (1) como tornar as cidades mais inteligentes por meio da otimização dos recursos e uso de tecnologias; (2) definições de cidades inteligentes e dimensões interdisciplinares como economia, mobilidade e meio ambiente; (3) tecnologias como Internet das Coisas, Big Data e computação em nuvem; (4) iniciativas de cidades inteligentes ao redor do mundo e a importância do software livre.
Smart Cities: Concepts, Platforms, and Challenges Fabio Kon
O documento apresenta conceitos e iniciativas relacionadas a cidades inteligentes, incluindo definições, dimensões, tecnologias envolvidas como Internet das Coisas, Big Data e computação em nuvem, e exemplos de projetos em cidades como Santander, Barcelona, Amsterdã, Chicago e Dublin.
Inovação Aberta, Ecossistemas de Startups e sua EvoluçãoFabio Kon
O documento discute a inovação aberta, ecossistemas de startups e sua evolução. Resume que startups oferecem vantagens como baixo custo e agilidade, e definem startups como organizações temporárias para buscar modelos de negócios escaláveis. Também apresenta uma pesquisa sobre ecossistemas de startups em três cidades e propõe um modelo de maturidade para avaliar ecossistemas.
Como Ensinar Engenharia de Software sem que seus alunos durmamFabio Kon
Minha palestra na RubyConf'2016 sobre um conjunto de boas práticas para ensinar Engenharia de Software atualmente. Baseado no material didático de http://br.sassbook.info
A linguagem C# aproveita conceitos de muitas outras linguagens,
mas especialmente de C++ e Java. Sua sintaxe é relativamente fácil, o que
diminui o tempo de aprendizado. Todos os programas desenvolvidos devem
ser compilados, gerando um arquivo com a extensão DLL ou EXE. Isso torna a
execução dos programas mais rápida se comparados com as linguagens de
script (VBScript , JavaScript) que atualmente utilizamos na internet
As classes de modelagem podem ser comparadas a moldes ou
formas que definem as características e os comportamentos dos
objetos criados a partir delas. Vale traçar um paralelo com o projeto de
um automóvel. Os engenheiros definem as medidas, a quantidade de
portas, a potência do motor, a localização do estepe, dentre outras
descrições necessárias para a fabricação de um veículo
Padrões de Projeto de Software Orientado a Objetos
1. 1
Padrões de Projeto de
Software Orientado a Objetos
Programação Orientada a Objetos
Prof. Fabio Kon - IME/USP
2. Padrões de Projeto de Software OO 2 / 33
Padrões de Projeto de Software
OO
Também conhecidos como
Padrões de Desenho de Software OO
ou simplesmente como Padrões.
3. Padrões de Projeto de Software OO 3 / 33
A Inspiração
A idéia de padrões foi apresentada por Christopher Alexander em
1977 no contexto de Arquitetura (de prédios e cidades):
Cada padrão descreve um problema que ocorre repetidamente de
novo e de novo em nosso ambiente, e então descreve a parte central
da solução para aquele problema de uma forma que você pode usar
esta solução um milhão de vezes, sem nunca implementa-la duas
vezes da mesma forma.
Livros
The Timeless Way of Building
A Pattern Language: Towns, Buildings, and Construction
serviram de inspiração para os desenvolvedores de software.
4. Padrões de Projeto de Software OO 4 / 33
Catálogo de soluções
Um padrão encerra o conhecimento de uma pessoa muito
experiente em um determinado assunto de uma forma que
este conhecimento pode ser transmitido para outras pessoas
menos experientes.
Outras ciências (p.ex. química) e engenharias possuem
catálogos de soluções.
Desde 1995, o desenvolvimento de software passou a ter o
seu primeiro catálogo de soluções para projeto de software: o
livro GoF.
5. Padrões de Projeto de Software OO 5 / 33
Gang of Four (GoF)
E. Gamma and R. Helm and R.
Johnson and J. Vlissides. Design
Patterns - Elements of Reusable
Object-Oriented Software.
Addison-Wesley, 1995.
6. Padrões de Projeto de Software OO 6 / 33
Gang of Four (GoF)
Passamos a ter um vocabulário comum para conversar sobre
projetos de software.
Soluções que não tinham nome passam a ter nome.
Ao invés de discutirmos um sistema em termos de pilhas,
filas, árvores e listas ligadas, passamos a falar de coisas de
muito mais alto nível como Fábricas, Fachadas, Observador,
Estratégia, etc.
A maioria dos autores eram entusiastas de Smalltalk,
principalmente o Ralph Johnson.
Mas acabaram baseando o livro em C++ para que o impacto
junto à comunidade de CC fosse maior. E o impacto foi
enorme, o livro vendeu centenas de milhares de cópias.
7. Padrões de Projeto de Software OO 7 / 33
O Formato de um padrão
Todo padrão inclui
Nome
Problema
Solução
Conseqüências / Forças
Existem outros tipos de padrões mas na aula de hoje
vamos nos concentrar no GoF.
8. Padrões de Projeto de Software OO 8 / 33
O Formato dos padrões no GoF
Nome (inclui número da página)
um bom nome é essencial para que o padrão caia na boca do povo
Objetivo / Intenção
Também Conhecido Como
Motivação
um cenário mostrando o problema e a necessidade da solução
Aplicabilidade
como reconhecer as situações nas quais o padrão é aplicável
Estrutura
uma representação gráfica da estrutura de classes do padrão
(usando OMT91) em, às vezes, diagramas de interação (Booch 94)
Participantes
as classes e objetos que participam e quais são suas responsabilidades
Colaborações
como os participantes colaboram para exercer as suas responsabilidades
9. Padrões de Projeto de Software OO 9 / 33
O Formato dos padrões no GoF
Conseqüências
vantagens e desvantagens, trade-offs
Implementação
com quais detalhes devemos nos preocupar quando implementamos o
padrão
aspectos específicos de cada linguagem
Exemplo de Código
no caso do GoF, em C++ (a maioria) ou Smalltalk
Usos Conhecidos
exemplos de sistemas reais de domínios diferentes onde o padrão é
utilizado
Padrões Relacionados
quais outros padrões devem ser usados em conjunto com esse
quais padrões são similares a este, quais são as dierenças
10. Padrões de Projeto de Software OO 10 / 33
Tipos de Padrões de Projeto
Categorias de Padrões do GoF
Padrões de Criação
Padrões Estruturais
Padrões Comportamentais
Vamos ver um exemplo de cada um deles.
Na aula de hoje:
Fábrica Abstrata (Abstract Factory (87))
- padrão de Criação de objetos
11. Padrões de Projeto de Software OO 11 / 33
Fábrica Abstrata
Abstract Factory (87)
Objetivo:
prover uma interface para criação de famílias de
objetos relacionados sem especificar sua classe
concreta.
12. Padrões de Projeto de Software OO 12 / 33
Abstract Factory - Motivação
Considere uma aplicação com interface gráfica que é implementada para
plataformas diferentes (Motif para UNIX e outros ambientes para
Windows e MacOS).
As classes implementando os elementos gráficos não podem ser
definidas estaticamente no código. Precisamos de uma implementação
diferente para cada ambiente. Até em um mesmo ambiente, gostaríamos
de dar a opção ao usuário de implementar diferentes aparências (look-
and-feels).
Podemos solucionar este problema definindo uma classe abstrata para
cada elemento gráfico e utilizando diferentes implementações para cada
aparência ou para cada ambiente.
Ao invés de criarmos as classes concretas com o operador new,
utilizamos uma Fábrica Abstrata para criar os objetos em tempo de
execução.
O código cliente não sabe qual classe concreta utilizamos.
13. Padrões de Projeto de Software OO 13 / 33
Abstract Factory - Aplicabilidade
Use uma fábrica abstrata quando:
um sistema deve ser independente da forma como
seus produtos são criados e representados;
um sistema deve poder lidar com uma família de
vários produtos diferentes;
você quer prover uma biblioteca de classes de
produtos mas não quer revelar as suas
implementações, quer revelar apenas suas interfaces.
14. Padrões de Projeto de Software OO 14 / 33
Abstract Factory - Estrutura
AbstractProductA
ProductA1
Client
ProductA2
AbstractFactory
CreatProductA()
CreatProductB()
ConcreteFactory2
CreatProductA()
CreatProductB()
ConcreteFactory1
CreatProductA()
CreatProductB()
AbstractProductB
ProductB1ProductB2
15. Padrões de Projeto de Software OO 15 / 33
Abstract Factory - Participantes
AbstractFactory (WidgetFactory)
ConcreteFactory (MotifWidgetFactory,
WindowsWidgetFactory)
AbstractProduct (Window, ScrollBar)
ConcreteProduct (MotifWindow,
MotifScrollBar, WindowsWindow,
WindowsScrollBar)
Client - usa apenas as interfaces declaradas pela
AbstractFactory e pelas classes AbstratProduct
16. Padrões de Projeto de Software OO 16 / 33
Abstract Factory - Colaborações
Normalmente, apenas uma instância de
ConcreteFactory é criada em tempo de execução.
Esta instância cria objetos através das classes
ConcreteProduct correspondentes a uma família de
produtos.
Uma AbstractFactory deixa a criação de objetos para
as suas subclasses ConcreteFactory.
17. Padrões de Projeto de Software OO 17 / 33
Abstract Factory - Conseqüências
O padrão
1. isola as classes concretas dos clientes;
2. facilita a troca de famílias de produtos (basta
trocar uma linha do código pois a criação da fábrica
concreta aparece em um único ponto do programa);
3. promove a consistência de produtos (não há o
perigo de misturar objetos de famílias diferentes);
4. dificulta a criação de novos produtos
ligeiramente diferentes (pois temos que modificar
a fábrica abstrata e todas as fábricas concretas).
18. Padrões de Projeto de Software OO 18 / 33
Abstract Factory - Implementação
1. Fábricas abstratas em geral são implementadas como
(127).
2. Na fábrica abstrata, cria-se um método fábrica para cada tipo de
produto. Cada fábrica concreta implementa o código que cria os
objetos de fato.
3. Se tivermos muitas famílias de produtos, teríamos um excesso
de classes “fábricas concretas”.
Para resolver este problema, podemos usar o Prototype
(117): criamos um dicionário mapeando tipos de produtos em
instâncias prototípicas destes produtos.
Então, sempre que precisarmos criar um novo produto pedimos
à sua instância prototípica que crie um clone (usando um método
como clone() ou copy()).
19. Padrões de Projeto de Software OO 19 / 33
Abstract Factory - Implementação
4. Em linguagens dinâmicas como Smalltalk onde classes são
objetos de primeira classe, não precisamos guardar uma
instância prototípica, guardamos uma referência para a própria
classe e daí utilizamos o método new para construir as novas
instâncias.
5. Definindo fábricas extensíveis.
• normalmente, cada tipo de produto tem o seu próprio método
fábrica; isso torna a inclusão de novos produtos difícil.
• solução: usar apenas um método fábrica
• Product make (string thingToBeMade)
• isso aumenta a flexibilidade mas torna o código
menos seguro (não teremos verificação de tipos pelo
compilador).
20. Padrões de Projeto de Software OO 20 / 33
Abstract Factory -
Exemplos de Código
O GoF contém exemplos em C++ e Smalltalk
Para casa, dar uma olhada em implementações em
C++
Smalltalk
Java
e pense nas diferenças entre as implementações nestas linguagens
21. Pausa para o Template Method
Template Method (325) - padrão Comportamental
definição de classes abstratas com métodos concretos
que apresentam uma receita de bolo chamando outros
métodos abstratos
são as subclasses concretas que definem que tipo de
bolo será criado.
no exemplo do Yoder note como o View "obriga" suas
subclasses a sempre chamar o setFocus antes e o
resetFocus depois.
Padrões de Projeto de Software OO 21 / 33
22. Cap. 13 do livro
Design Patterns in Ruby
A aventura do laguinho
Padrões de Projeto de Software OO 22 / 33
23. Exemplo em Ruby (1/2)
Padrões de Projeto de Software OO 23 / 33
24. Exemplo em Ruby (2/2)
Padrões de Projeto de Software OO 24 / 33
25. Padrões de Projeto de Software OO 25 / 33
Abstract Factory - Usos Conhecidos
InterViews usa fábricas abstratas para encapsular
diferentes tipos de aparências para sua interface gráfica
ET++ usa fábricas abstratas para permitir a fácil
portabilidade para diferentes ambientes de janelas
(XWindows e SunView, por exemplo)
Sistema de captura e reprodução de vídeo feito na UIUC
usa fábricas abstratas para permitir portabilidade entre
diferentes placas de captura de vídeo.
Em linguagens dinâmicas como Smalltalk (e talvez em
POO em geral) classes podem ser vistas como fábricas
de objetos.
26. Padrões de Projeto de Software OO 26 / 33
Abstract Factory -
Padrões Relacionados
Fábricas abstratas são normalmente implementadas com
métodos fábrica (FactoryMethod (107)) mas podem
também ser implementados usando Prototype (117).
O uso de protótipos é particularmente importante em
linguagens não dinâmicas como C++ e em linguagens
"semi-dinâmicas" como Java.
Em Smalltalk, não é tão relevante.
Curiosidade: a linguagem Self não possui classes, toda
criação de objetos é feita via clonagem.
Uma fábrica concreta é normalmente um
Singleton (127)
27. Padrões de Projeto de Software OO 27 / 33
Os 23 Padrões do GoF
Criação
Abstract Factory
Builder
Factory Method
Prototype
Singleton
28. Padrões de Projeto de Software OO 28 / 33
Os 23 Padrões do GoF
Estruturais
Adapter
Bridge
Composite
Decorator
Façade
Flyweight
Proxy
29. Padrões de Projeto de Software OO 29 / 33
Os 23 Padrões do GoF
Comportamentais
Chain of Responsibility
Command
Interpreter
Iterator
Mediator
Memento
Observer
State
Strategy
Template Method
Visitor
30. Padrões de Projeto de Software OO 30 / 33
Para próxima aula
Dar uma olhada no GoF
a biblioteca possui algumas cópias
Buscar por “GoF patterns” no google
31. Padrões de Projeto de Software OO 31 / 33
Recapitulando
Voltando ao Christopher Alexander:
Cada padrão descreve um problema que ocorre
repetidamente de novo e de novo em nosso ambiente, e então
descreve a parte central da solução para aquele problema de
uma forma que você pode usar esta solução um milhão de
vezes, sem nunca implementa-la duas vezes da mesma forma.
Talvez a última parte não seja sempre desejável.
32. Padrões de Projeto de Software OO 32 / 33
Próximas Aulas
Demais padrões do GoF
Outros tipos de padrões
arquiteturais
de análise
anti-padrões
etc.
InterViews é um toolkit para a construção de aplicações gráficas no X Windows no qual o John Vlissides trabalhou e fez parte de sua tese de doutorado.
ET++ é um arcabouço no qual o Gamma trabalhou e ajudava a construir aplicações com interfaces gráficas complexas (similares ao Java Swing de hoje).