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 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.
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.
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 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.
1) O documento discute Domain Driven Design (DDD), uma abordagem para projeto de software focada no domínio e suas regras de negócio.
2) DDD utiliza conceitos como linguagem ubíqua, modelagem dirigida por domínio e blocos de construção como entidades, agregados e serviços.
3) O documento também apresenta técnicas como refatoração e mapas de contexto para lidar com sistemas complexos.
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.
Bolovo - problema antigo de arquitetura de software - não use por aíPriscila Mayumi
O documento discute os problemas da arquitetura BOLOVO, que separa projetos em Entidades, BLL e DAL. Apresenta que essa arquitetura foi criada para resolver problemas do Java antigo, mas não faz mais sentido para .NET hoje em dia, levando a códigos procedurais, classes anêmicas e baixa testabilidade, indo contra princípios como SOLID e DDD. Recomenda que desenvolvedores .NET evoluam e não usem mais BOLOVO, aprendendo DDD e TDD.
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 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.
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.
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 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.
1) O documento discute Domain Driven Design (DDD), uma abordagem para projeto de software focada no domínio e suas regras de negócio.
2) DDD utiliza conceitos como linguagem ubíqua, modelagem dirigida por domínio e blocos de construção como entidades, agregados e serviços.
3) O documento também apresenta técnicas como refatoração e mapas de contexto para lidar com sistemas complexos.
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.
Bolovo - problema antigo de arquitetura de software - não use por aíPriscila Mayumi
O documento discute os problemas da arquitetura BOLOVO, que separa projetos em Entidades, BLL e DAL. Apresenta que essa arquitetura foi criada para resolver problemas do Java antigo, mas não faz mais sentido para .NET hoje em dia, levando a códigos procedurais, classes anêmicas e baixa testabilidade, indo contra princípios como SOLID e DDD. Recomenda que desenvolvedores .NET evoluam e não usem mais BOLOVO, aprendendo DDD e TDD.
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.
Domain Driven Design – DDD além da teoria!, por Paulo Victor GomesiMasters
Paulo Victor Gomes, Software Developer da Tricae, falou sobre 'Domain Driven Design – DDD além da teoria!' no iMasters PHP Experience 2015.
O iMasters PHP Experience 2015 aconteceu dia 25 de Abril de 2015, no Hotel Renaissance em São Paulo-SP - http://phpexperience.imasters.com.br/
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 os paradigmas de programação, definindo-os como estilos de programação. Apresenta os paradigmas funcional, lógico, procedural e orientado a objetos, destacando as semelhanças e diferenças entre o paradigma procedural e orientado a objetos.
1) A programação orientada a objetos surgiu na década de 1960 e visa aproximar o mundo real do virtual através da simulação de objetos e suas interações.
2) O padrão MVC foi criado em 1979 para separar dados, layouts e interfaces gráficas, de modo que alterações em um componente não afetem os outros.
3) A programação orientada a objetos e o padrão MVC trazem benefícios como reutilização de código, escalabilidade, manutenabilidade e desenvolvimento acelerado de sistemas complexos.
O documento defende que o padrão DCI (Data Context Interaction) é melhor do que MVC para arquitetura de software orientada a objetos. Apresenta os princípios do DCI, como a separação de dados, contexto e interação, e argumenta que ele resolve problemas de composição encontrados em MVC.
O documento descreve os principais paradigmas de programação como imperativo, funcional e orientado a objetos. Ele também discute linguagens de baixo, médio e alto nível e as diferenças entre interpretação e compilação.
O documento descreve o padrão de projeto Adapter, que permite a conexão entre objetos com interfaces incompatíveis, como um plugue de 3 pinos e uma tomada de 2 pinos usando um adaptador. Ele também é aplicado em programação para permitir que classes existentes sejam usadas mesmo quando suas interfaces não combinam com o cliente, através de uma classe adaptadora.
Juliana Fideles apresenta sobre código limpo em uma palestra na 25a Semana da Tecnologia da Fatec Sorocaba. Ela discute princípios como usar nomes significativos, estruturar o código em funções menores, e tratar erros com exceções. O objetivo é escrever código que seja fácil de ler, modificar e expandir no futuro.
Este documento fornece informações biográficas sobre Flávio Gomes da Silva Lisboa. Ele é um arquiteto, desenvolvedor, instrutor e especialista em história em quadrinhos que oferece serviços de consultoria. Suas principais áreas de atuação incluem arquitetura de software, orientação a objetos e padrões como MVC, DCI e injeção de dependências.
O padrão Adapter permite que classes com interfaces incompatíveis trabalhem juntas convertendo a interface de uma classe em outra interface esperada pelos clientes. O Adapter implementa a interface alvo e delega requisições para a classe existente, adaptando sua interface para a interface alvo. O Adapter pode ser implementado usando herança ou composição.
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 a linguagem de modelagem unificada (UML), incluindo sua evolução, ferramentas de modelagem e exemplos de diagramas UML como classe, sequência e atividades.
O documento apresenta um minicurso sobre a linguagem de programação Java. Aborda conceitos como programação orientada a objetos, o que é Java, variáveis, classes, métodos, objetos, atributos e métodos em Java, e ambientes de desenvolvimento como NetBeans e Eclipse.
Padrões de projeto
• ajudando a construir um software confiável com arquiteturas testada e perícia acumulada pela indústria.
• promovendo a reutilização de projetos em futuros sistemas.
• ajudando a identificar equívocos comuns e armadilhas que ocorrem ao construirem sistemas.
• ajudando a projetar sistemas independentemente da linguagem em que eles, em última instância, serão implementados.
• estabelecendo um vocabulário comum de projeto entre os desenvolvedores.
• encurtando a fase de projeto no processo de desenvolvimento de um software.
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.
Aplicação de Padrões de Projeto para a melhoria da manutenabilidade de softwareCesar Rocha
A comunidade de desenvolvimento de software vem adotando cada vez mais os conceitos propostos pelos padrões de projeto no processo de desenvolvimento de software. Estudos reportam evidências de que esses padrões causam um impacto positivo na qualidade do software, mas em alguns casos a adoção de padrões de projeto pode ser inapropriada. Esse trabalho monográfico relata a origem e os fundamentos dos padrões de projeto, e busca evidenciar a importância da aplicação de padrões para obter a excelência e a qualidade desejadas para os sistemas de software. Através de uma pesquisa bibliográfica esse trabalho evidenciou que a aplicação de padrões de projeto na fase de desenvolvimento do software é um recurso positivo nos processos futuros de manutenção. Fatores como reusabilidade, modularidade, uso de interfaces, composição de objetos, baixo acoplamento e alta coesão são diretamente manipulados através dos padrões de projeto e consequentemente promovem melhorias na manutenabilidade. Apesar dos benefícios proporcionados, os padrões de projeto também podem ter efeitos negativos sobre os sistemas de software.
O documento descreve o DB4O, um banco de dados orientado a objetos que permite a persistência transparente de objetos em Java e .NET. Ele não segue as especificações ODMG ou JDO e permite acesso por uma única aplicação ou por várias aplicações simultaneamente. O banco é acessado via ObjectServer e os objetos são armazenados em ObjectContainers dentro do banco de dados. Consultas podem ser feitas usando predicados ou exemplos de objetos.
O documento descreve o Db4objects, um banco de dados orientado a objetos de código aberto que permite armazenar objetos diretamente no banco de dados sem usar consultas SQL. Ele é mais rápido que bancos relacionais e é usado por empresas como Bosch, BMW e Intel. O Db4objects tem vantagens como rapidez e facilidade de uso, mas carece de recursos como controle de versão e recuperação de dados.
Domain Driven Design – DDD além da teoria!, por Paulo Victor GomesiMasters
Paulo Victor Gomes, Software Developer da Tricae, falou sobre 'Domain Driven Design – DDD além da teoria!' no iMasters PHP Experience 2015.
O iMasters PHP Experience 2015 aconteceu dia 25 de Abril de 2015, no Hotel Renaissance em São Paulo-SP - http://phpexperience.imasters.com.br/
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 os paradigmas de programação, definindo-os como estilos de programação. Apresenta os paradigmas funcional, lógico, procedural e orientado a objetos, destacando as semelhanças e diferenças entre o paradigma procedural e orientado a objetos.
1) A programação orientada a objetos surgiu na década de 1960 e visa aproximar o mundo real do virtual através da simulação de objetos e suas interações.
2) O padrão MVC foi criado em 1979 para separar dados, layouts e interfaces gráficas, de modo que alterações em um componente não afetem os outros.
3) A programação orientada a objetos e o padrão MVC trazem benefícios como reutilização de código, escalabilidade, manutenabilidade e desenvolvimento acelerado de sistemas complexos.
O documento defende que o padrão DCI (Data Context Interaction) é melhor do que MVC para arquitetura de software orientada a objetos. Apresenta os princípios do DCI, como a separação de dados, contexto e interação, e argumenta que ele resolve problemas de composição encontrados em MVC.
O documento descreve os principais paradigmas de programação como imperativo, funcional e orientado a objetos. Ele também discute linguagens de baixo, médio e alto nível e as diferenças entre interpretação e compilação.
O documento descreve o padrão de projeto Adapter, que permite a conexão entre objetos com interfaces incompatíveis, como um plugue de 3 pinos e uma tomada de 2 pinos usando um adaptador. Ele também é aplicado em programação para permitir que classes existentes sejam usadas mesmo quando suas interfaces não combinam com o cliente, através de uma classe adaptadora.
Juliana Fideles apresenta sobre código limpo em uma palestra na 25a Semana da Tecnologia da Fatec Sorocaba. Ela discute princípios como usar nomes significativos, estruturar o código em funções menores, e tratar erros com exceções. O objetivo é escrever código que seja fácil de ler, modificar e expandir no futuro.
Este documento fornece informações biográficas sobre Flávio Gomes da Silva Lisboa. Ele é um arquiteto, desenvolvedor, instrutor e especialista em história em quadrinhos que oferece serviços de consultoria. Suas principais áreas de atuação incluem arquitetura de software, orientação a objetos e padrões como MVC, DCI e injeção de dependências.
O padrão Adapter permite que classes com interfaces incompatíveis trabalhem juntas convertendo a interface de uma classe em outra interface esperada pelos clientes. O Adapter implementa a interface alvo e delega requisições para a classe existente, adaptando sua interface para a interface alvo. O Adapter pode ser implementado usando herança ou composição.
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 a linguagem de modelagem unificada (UML), incluindo sua evolução, ferramentas de modelagem e exemplos de diagramas UML como classe, sequência e atividades.
O documento apresenta um minicurso sobre a linguagem de programação Java. Aborda conceitos como programação orientada a objetos, o que é Java, variáveis, classes, métodos, objetos, atributos e métodos em Java, e ambientes de desenvolvimento como NetBeans e Eclipse.
Padrões de projeto
• ajudando a construir um software confiável com arquiteturas testada e perícia acumulada pela indústria.
• promovendo a reutilização de projetos em futuros sistemas.
• ajudando a identificar equívocos comuns e armadilhas que ocorrem ao construirem sistemas.
• ajudando a projetar sistemas independentemente da linguagem em que eles, em última instância, serão implementados.
• estabelecendo um vocabulário comum de projeto entre os desenvolvedores.
• encurtando a fase de projeto no processo de desenvolvimento de um software.
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.
Aplicação de Padrões de Projeto para a melhoria da manutenabilidade de softwareCesar Rocha
A comunidade de desenvolvimento de software vem adotando cada vez mais os conceitos propostos pelos padrões de projeto no processo de desenvolvimento de software. Estudos reportam evidências de que esses padrões causam um impacto positivo na qualidade do software, mas em alguns casos a adoção de padrões de projeto pode ser inapropriada. Esse trabalho monográfico relata a origem e os fundamentos dos padrões de projeto, e busca evidenciar a importância da aplicação de padrões para obter a excelência e a qualidade desejadas para os sistemas de software. Através de uma pesquisa bibliográfica esse trabalho evidenciou que a aplicação de padrões de projeto na fase de desenvolvimento do software é um recurso positivo nos processos futuros de manutenção. Fatores como reusabilidade, modularidade, uso de interfaces, composição de objetos, baixo acoplamento e alta coesão são diretamente manipulados através dos padrões de projeto e consequentemente promovem melhorias na manutenabilidade. Apesar dos benefícios proporcionados, os padrões de projeto também podem ter efeitos negativos sobre os sistemas de software.
O documento descreve o DB4O, um banco de dados orientado a objetos que permite a persistência transparente de objetos em Java e .NET. Ele não segue as especificações ODMG ou JDO e permite acesso por uma única aplicação ou por várias aplicações simultaneamente. O banco é acessado via ObjectServer e os objetos são armazenados em ObjectContainers dentro do banco de dados. Consultas podem ser feitas usando predicados ou exemplos de objetos.
O documento descreve o Db4objects, um banco de dados orientado a objetos de código aberto que permite armazenar objetos diretamente no banco de dados sem usar consultas SQL. Ele é mais rápido que bancos relacionais e é usado por empresas como Bosch, BMW e Intel. O Db4objects tem vantagens como rapidez e facilidade de uso, mas carece de recursos como controle de versão e recuperação de dados.
Partindo além do Java e conhecendo novas linguagens e tecnologias que podem aumentar o seu conjunto de ferramentas.
Palestra apresentada originalmente em 11 de julho de 2011 no N-ésimo encontro do PBJUG.
The document discusses various techniques for optimizing website performance, including respecting HTTP protocols like using GET requests for non-destructive actions; using a proxy server like Nginx to deliver static content; leveraging caching, compression, and content delivery networks; JavaScript and image optimizations; and asynchronous loading of scripts. The goal is to make websites faster by improving how static assets are served and how client-server interactions work.
O documento discute as vantagens da linguagem Scala em relação a Java ao migrar uma plataforma de Ruby para Java. Apresenta exemplos de código em Scala e Java demonstrando o uso de closures, coleções e iteradores. Defende que Scala oferece uma melhor experiência de programação funcional preservando a compatibilidade com código Java existente.
O documento discute como adicionar criptografia de texto em Java de forma flexível usando o padrão decorator. Ele propõe uma classe CryptoWriter que envolve qualquer Writer, processando dados criptografados antes de repassá-los, agindo como um "filtro". Isso permite criptografar qualquer fluxo ou arquivo independente da hierarquia de classes, aumentando a funcionalidade de forma não intrusiva.
O documento resume tópicos sobre desenvolvimento web, incluindo:
1) Uma dinâmica para apresentar colegas em potenciais entrevistas de emprego;
2) Uma explicação sobre os principais protocolos da Internet como IP, TCP, UDP, DNS, POP, SMTP, IMAP e HTTP;
3) Uma discussão sobre tendências em tecnologias como dispositivos móveis, RIA, HTML5 e linguagens de programação;
4) Uma revisão de tópicos de infraestrutura como bancos de dados, servidores web
O documento apresenta conceitos básicos da linguagem Java, incluindo estrutura de código, classes, objetos, arrays, estruturas de controle e exercícios para praticar os tópicos abordados.
O documento discute como os processos da Toyota e os princípios do Lean podem ser aplicados ao desenvolvimento de software. Apresenta os princípios do Toyota Production System e como eles inspiraram o Extreme Programming (XP) e outras metodologias ágeis, focando na eliminação de desperdícios e no valor para o cliente.
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 discute dois tópicos: (1) Paradigma de Orientação a Objetos, introduzindo seus conceitos-chave como objeto, classe e encapsulamento; (2) Persistência de dados via JDBC, explicando os tipos de drivers JDBC e fornecendo um exemplo básico de uso do JDBC.
O documento apresenta um workshop sobre Design Patterns, abordando sua introdução e alguns padrões como Factory, Abstract Factory, Singleton, Adapter, Facade e MVC. A agenda inclui antes de começar, introdução, cuidados e tipos de padrões como creacionais, estruturais e comportamentais.
O documento fornece uma introdução aos conceitos básicos de orientação a objetos, incluindo: (1) O que é orientação a objetos e seus principais conceitos como classes, objetos, herança e polimorfismo; (2) Como a orientação a objetos evoluiu através de linguagens de programação e metodologias; (3) Como a orientação a objetos facilita a reutilização de código e modelagem do mundo real.
O documento discute conceitos de análise e projeto orientados a objetos, incluindo identificação de classes, herança, encapsulamento, polimorfismo, UML e projeto orientado a objetos visando baixo acoplamento e alta coesão.
Net uma revisão sobre a programação orientada a objetosLP Maquinas
Neste artigo vou revisar os conceitos chaves sobre o paradigma da programação orientada a objetos sem rodeios.
A Programação Orientada a Objetos (POO) é uma abordagem para desenvolvimento de software no qual a estrutura do software é baseada em objetos que interagem uns com os outros para realizar uma tarefa.
Obs: Você vai encontrar com freqüência a acróstico OOP - Oriented Object Programming.
Essa interação toma a forma de mensagens que são trocadas entre os objetos sendo que em res
O documento apresenta uma introdução aos conceitos e histórico da orientação a objetos, incluindo definições de classes, objetos e outros princípios. Também discute vantagens da abordagem orientada a objetos, preconceitos comuns, desenvolvimento orientado a objetos e linguagens de programação orientadas a objetos como C++ e Java.
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 apresenta o professor Lucas Simões Maistro e discute as tendências do mercado de sistemas web, o que é a linguagem PHP e suas vantagens, como simplicidade, adaptabilidade e interoperabilidade. Apresenta exemplos básicos de scripts em PHP, incluindo o uso de formulários, variáveis, condicionais e laços.
Este documento é uma apostila para um curso de extensão sobre MFC (Microsoft Foundation Classes) e apresenta conceitos básicos de programação orientada a objetos. O documento discute a história da programação orientada a objetos, princípios como encapsulamento e herança, e conceitos como classe, objeto, método e mensagem.
Este documento discute os conceitos fundamentais da modelagem de sistemas de informação orientada a objetos em 3 frases:
1) Apresenta os principais conceitos da análise orientada a objetos como classes, objetos, herança, associações e encapsulamento.
2) Discutem os benefícios e desafios da análise orientada a objetos incluindo uma melhor compreensão dos problemas e maior flexibilidade no desenvolvimento.
3) Explica que a modelagem é fundamental para construir modelos que comuniquem a estrutura e comportamento do
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 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.
A apresentação discute a importância dos testes de unidade e TDD, incluindo como eles melhoram o design de classes, qualidade do código e acoplamento. Também aborda níveis de teste, mock objects e quando não usar TDD.
O documento discute os principais conceitos e práticas do Feature Driven Development (FDD). Ele explica que FDD envolve dividir o projeto em funcionalidades pequenas e focadas em valor para o cliente, definir papéis como gerente de projeto e arquiteto chefe, e organizar equipes ao redor das funcionalidades. O documento também discute tópicos como modelagem de objetos de domínio, propriedade de código e classes, e inspeções de código como parte do processo.
O documento discute técnicas de teste exploratório, incluindo: 1) O que é teste exploratório e quando deve ser usado; 2) Elementos do teste exploratório como exploração do produto e projeto de teste; 3) Requisitos do testador e do software para teste exploratório.
O documento discute o framework Naked Objects, que facilita a construção de aplicações orientadas a objetos a partir de objetos comportamentalmente completos. O framework fornece mecanismos de visualização e persistência que refletem automaticamente o modelo de objetos, poupando esforços do desenvolvedor. A abordagem promove sistemas verdadeiramente orientados a objetos e mais flexíveis às mudanças de requisitos.
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.
1) O documento apresenta Rodrigo Branas, palestrante e instrutor de modelagem ágil, Clean Code, Selenium e Maven.
2) A modelagem ágil é baseada em valores e princípios como simplicidade, feedback e YAGNI, e deve ser usada em conjunto com métodos como XP e Scrum.
3) Ferramentas simples como protótipos em papel e diagramas UML coloridos são recomendadas para modelagem ágil, que deve ter como foco produzir software funcionando de forma incremental.
Este documento fornece uma introdução aos conceitos de Análise e Projeto Orientados a Objetos (APOO). Discute a diferença entre análise e projeto, conceitos fundamentais de OO como classe, objeto, atributo e método, e técnicas de modelagem como associação, agregação e herança.
Unindo Ruby e Java através de uma arquitetura orientada a serviços na OfficeDropMaurício Linhares
O documento discute a arquitetura orientada a serviços em Ruby e Java, descrevendo como o autor dividiu uma grande aplicação Rails monolítica em duas aplicações separadas para gestão de documentos e processamento de documentos, comunicando-se via fila de mensagens e API REST. Isso trouxe benefícios como ciclos de deploy mais curtos e menos testes, porém também desafios de comunicação entre equipes. O autor conclui recomendando aplicações pequenas e focadas, compartilhando dados apenas via API.
Mixing Ruby and Java in a Service Oriented Architecture at OfficeDropMaurício Linhares
Service oriented architecture mixing Ruby and Java can provide benefits by separating applications into independent components that communicate over APIs. The document discusses a case where splitting a monolithic Rails application into separate document management and processing apps improved development by allowing independent deployment and reduced test time. Key aspects that enabled this included using Resque for job queuing between apps, RESTful JSON APIs, and storing processed files in S3. However, clear documentation and coordination were needed to integrate the separate teams working on each app.
O documento descreve conceitos básicos da linguagem de programação Ruby, incluindo:
1) Sua origem no Japão e influências de outras linguagens como Smalltalk e Perl.
2) Conceitos como orientação a objetos, dinamismo, blocos de código e falta de tipagem.
3) Ferramentas como RVM para gerenciar versões do Ruby e Rubygems para gerenciar pacotes.
O documento discute exceções e erros em Java, explicando que exceções representam erros que podem ser tratados enquanto erros são problemas irrecuperáveis. Ele também diferencia exceções controladas e não controladas, dando exemplos de cada tipo.
O documento descreve diferentes tipos de coleções em Java, incluindo vetores, conjuntos, pilhas, árvores binárias e tabelas de hash. Ele também discute a interface Collection e as interfaces Map, Set e List, além de exemplos de uso.
Curso java 06 - mais construtores, interfaces e polimorfismoMaurício Linhares
O documento discute herança e interfaces em Java. Ele explica que construtores não são herdados, mas precisam chamar o construtor da superclasse. Também apresenta como implementar interfaces para permitir que classes herdem comportamentos sem herança múltipla, resolvendo problemas como o "diamante da morte".
Curso java 05 - herança, classes e métodos abstratosMaurício Linhares
O documento discute os conceitos de herança, polimorfismo e classes abstratas em orientação a objetos. A herança permite que classes herdem atributos e comportamentos de outras classes, evitando repetição de código. O polimorfismo acontece quando métodos são sobrescritos em subclasses, permitindo tratá-las de forma genérica. Classes abstratas definem interfaces comuns para subclasses concretas, podendo conter métodos abstratos para implementação nas mesmas.
O documento discute variáveis e métodos estáticos em Java, explicando que variáveis estáticas pertencem à classe ao invés de objetos e podem ser acessadas sem a necessidade de um objeto. Também aborda métodos estáticos, que são chamados através do nome da classe, e padrões de nomenclatura para variáveis, métodos e classes em Java.
O documento discute variáveis em Java, incluindo: 1) a declaração de variáveis com tipos primitivos como inteiros, caracteres e números de ponto flutuante; 2) a diferença entre variáveis de tipos primitivos e objetos; 3) referências e como variáveis de objetos apontam para objetos.
O documento discute conceitos fundamentais de orientação a objetos em Java, como:
1) Pacotes agrupam classes relacionadas e definem sua localização no sistema de arquivos;
2) Métodos acessam variáveis de instância de um objeto;
3) Getters e setters encapsulam variáveis de instância e permitem acesso seguro a propriedades de objetos.
O documento discute as oportunidades de trabalho remoto e outsourcing para profissionais de tecnologia. Ele enfatiza a importância de estudar continuamente, construir uma marca profissional através de redes e projetos de código aberto, e dominar o inglês para competir globalmente. O autor também oferece uma vaga de estágio em sua empresa para aplicantes qualificados.
Maurício Linhares apresenta as principais tendências no mercado de tecnologia, incluindo plataformas móveis, Software como Serviço (SaaS), Plataforma como Serviço (PaaS) e Ruby on Rails. Ele discute as habilidades desejadas por empresas, como inglês, programação e aprendizado contínuo, e enfatiza a importância de compartilhar conhecimento através de blogs e comunidades.
O documento resume conceitos básicos de HTML e JavaScript. Explica que HTML é uma linguagem de marcação para estruturar páginas web, enquanto JavaScript permite adicionar interatividade dinâmica. Também define elementos HTML comuns como tags, atributos, formulários e lista. Por fim, apresenta conceitos básicos de programação em JavaScript como variáveis, condicionais, loops, funções e eventos.
O documento discute threads e sockets em Java, descrevendo como sockets permitem que aplicativos Java acessem serviços pela rede usando TCP ou UDP e como é possível criar clientes e servidores. Também aborda como criar threads para melhorar o desempenho de aplicações concorrentes, dividindo tarefas em unidades independentes de computação.
O documento discute vários tópicos avançados de desenvolvimento Java, incluindo composição e agregação de objetos, testes unitários com JUnit, classes File e Streams de entrada/saída, parsing de XML, acesso a bancos de dados com JDBC e geração de templates XML com FreeMarker.
Projeto e desenvolvimento de sistemas de informação 4 - computação em redeMaurício Linhares
O documento descreve a evolução das aplicações na Internet, desde sua presença inicial até a integração de serviços atuais. Apresenta também como a General Motors usou ferramentas de colaboração online para projetar carros de forma integrada entre seus 18 centros de tecnologia ao redor do mundo.
O documento apresenta os princípios e práticas do Extreme Programming (XP), abordando sua filosofia de abraçar a mudança e valorizar as pessoas. Descreve como o XP envolve ciclos curtos de desenvolvimento, planejamento incremental, testes automatizados e colaboração constante entre times e clientes.
O documento explica os principais conceitos e ferramentas para acesso a bancos de dados relacionais usando JDBC no Java, incluindo interfaces como Connection e Statement, PreparedStatement, CallableStatement, transações, isolamento de transações e tipos de ResultSets.
O Java WSDP é um conjunto de tecnologias para desenvolver web services em Java, incluindo JAX-WS, JAXB, StAX e SAAJ. Ele fornece uma API simples para comunicação remota via XML e permite implementar serviços com anotações. O wsgen gera classes necessárias e o wsimport cria objetos para invocar serviços remotamente com base em WSDL.
2. Material de referência
› Head
First Object Oriented Design and
Analysis – Brett D. McLaughlin e outros
› Domain
Driven Design – Tackling
Complexity in the Heart of Software – Eric
Evans
› Refactoring:
Improving the design of
existing code – Martin Fowler e outros
3. O que é análise
Orientada a Objetos?
Definição dos objetos, suas atividades,
propriedades e funções dentro do sistema onde
eles estão inseridos
5. Modelagem eficiente
› Manter
modelos e implementação
fortemente ligados;
› Cultivar
uma linguagem baseada no
modelo;
› Desenvolver
um modelo que represente
conhecimento sobre o assunto tratado;
6. Modelagem Eficiente
› Destilar
o modelo, removendo conceitos
desnecessários ou não essenciais;
› Brainstorms
e experimentação para
garantir que a solução que está sendo
desenvolvida é realmente a melhor
possível;
7. “É a criatividade dos brainstorms e
experimentações, junto com uma
linguagem baseada no modelo e
disciplinada pelo feedback da
implementação, que torna possível
encontrar um modelo rico e destilá-
lo para o software funcional.”
Eric Evans, Domain Driven
Design, página 13
8. Knowlege Crunching –
Triturando conhecimento
› A
equipe trabalha junto com os
especialistas do domínio para criar o
modelo;
› O
conhecimento deve ser refinado e
construído de acordo com as
funcionalidades desejadas;
9. Knowledge crunching
› Ilhas
de informação devem ser evitadas,
é importante que todos os membros
tenham conhecimento sobre o modelo
para que possam escrever o software;
› Abstrações
do modelo devem surgir
através das abstrações do próprio
domínio, o modelo sempre reflete o
mundo real;
10. Aprendizado contínuo
› Programar
é definir uma teoria, em
código, que representa elementos no
mundo real;
› Conhecimentose fragmenta, se torna
obsoleto ou representa entidades de
pouca importância, é necessário
continuar aprendendo;
12. Modelos profundos
› Não
perca tempo demais tentando ir o
mais fundo possível nos seus modelos;
› Conhecimento e refinamento vem com
tempo, prática e experimentação;
› O
modelo final dificilmente é o mesmo do
modelo inicial;
13. Momentos da análise OO –
Conceitualmente
› Deduzir os requisitos do cliente para o sistema;
› Identificar cenários de casos de uso;
› Selecionar classes e objetos usando os
requisitos;
› Identificar atributos e operações para cada
objeto do sistema;
› Definir estruturas e hierarquias que organizem as
classes;
› Construir um modelo objeto-relacionamento;
› Construir um modelo de comportamento de
objeto;
› Revisar o modelo de análise OO com base nos
casos de uso ou cenários.
14. Caminho do sucesso -
simplificado
› Descubra as funcionalidades que o cliente
necessita;
› Primeiro escreva código que atende a
necessidade do cliente (e com testes);
› Depois atente para os problemas de design OO
que o seu código possa ter e adicione
flexibilidade onde necessário;
› Mantenha o seu código bem organizado, legível
e passível de ser reutilizado;
› Lucro! $$$!
16. Tudo começa com os
requisitos
› Ouça o que o cliente deseja que o sistema
faça;
› Tenteusar mockups ou desenhos se ele tiver
dificuldade explicando o que ele deseja
(http://balsamiq.com/ );
› Não
se preocupe demais com a solução
tecnológica que você vai ter que
implementar;
17. Atenção aos verbos e
substantivos!
› O
seu cliente entende do negócio, ele
normalmente sabe do que ele está falando
então ENTENDA os conceitos básicos;
› Use
dentro do seu sistema os mesmos nomes
e atividades que o seu cliente está
explicando nas funcionalidades;
› Substantivos
normalmente simbolizam objetos
e verbos seus métodos;
18. A linguagem Ubíqua
› Desenvolvedorese usuários devem falar a
mesma língua quando estiverem falando
sobre o sistema;
› Traduções
entre conceitos são ruins e geram
perda de informação;
› Desenvolvedores devem procurar entender
ao menos os conceitos básicos do sistema
onde eles estão inseridos;
19. Um diálogo de exemplo
Como desenvolvedores e clientes se comunicam
20. Conhecimento sendo
passado pela fala
› Oseu cérebro é especializado em entender
a língua falada;
› A
forma mais eficiente de aprender uma
outra língua é através da imersão, não se fala
nada além da nova língua;
› Equipe
e especialistas do domínio devem
expandir e adicionar novos significados a
linguagem comum;
21. Ah, mas o cliente não
entende de objetos!
› Nemvocê entende de direito tributário,
contabilidade, engenharia civil ou gestão
de órgãos públicos. E aí?
› A
linguagem criada é uma interseção
entre o jargão técnico da informática e o
jargão técnico do domínio pro qual o seu
software vai ser produzido;
22. Documentos, diagramas,
modelos visuais
› Nãose prenda demais a papéis somente
pelo fato deles serem documentos;
› Documentação deve “pagar” pra existir;
› Não
tenha pena de jogar fora
documentação que sirva somente de
peso;
23. Documentos, diagramas,
modelos visuais
› Não
se prenda demais a detalhes
técnicos da UML ou da representação
que você está utilizando;
› Simplifique
qualquer coisa que não
atenda as suas necessidades;
› DiagramasNÃO SÃO O SEU PRODUTO (na
maior parte das vezes);
24. Passo a passo
› Reúnaos caminhos básicos do sistema,
crie uma lista, passo a passo, de o que
precisa ser implementado (o que é isso?);
› Bonus
se você estiver utilizando uma
ferramenta de testes que seja capaz de
receber texto puro;
25. Exemplo hardcore
Cenário: Remover itens do carrinho "
!
Dado que estou na listagem de produtos"
E adiciono "5" itens do produto "Lean Software
Development" ao carrinho"
E adiciono "5" itens do produto "Agile Estimating and
Planning" ao carrinho"
!
Quando vou pra página do carrinho "
E removo o produto "Agile Estimating and Planning" do
carrinho"
!
Entao devo ver "Lean Software Development“ "
!
Mas não devo ver "Agile Estimating and Planning"
27. O que é uma classe?
Reencontrando a orientação a objetos
28. O que é uma classe?
› Define
a estrutura de um objeto, com
seus atributos e operações;
› Atributos são os dados guardados no
objeto;
› Operaçõessão as atividades que um
objeto é capaz de executar ou as
mensagens que ele recebe;
29. O que é herança?
Reencontrando a orientação a objetos
30. O que é herança?
Reutilizar código de uma outra classe herdando
suas propriedades e seus comportamentos
31. O que é polimorfismo?
Reencontrando a orientação a objetos
32. O que é polimorfismo?
É a capacidade de se utilizar uma subclasse de um
objeto onde o objeto pai (ou interface) é utilizado
sem que o código perceba a diferença
34. O que é
encapsulamento?
É o ato de esconder as informações de
implementação de um objeto dos seus clientes
externos com o objetivo de facilitar as mudanças
no futuro.
35. O que são composição e
agregação?
Revisando orientação a objetos
36. O que são composição e
agregação?
Composição é o fato de que vários objetos
interligados compõem um objeto maior e não
fazem sentido em separado.
Agregação é quando vários objetos podem existir
dentro de um objeto maior ou isolados, não sendo
necessário que estejam reunidos.
37. Objetos devem fazer ou
representar uma coisa e
somente isso. Se o Bolo é
comida, vai ser sempre
comida.
Responsabilidade
38. Como identificar objetos que
fazem demais?
› É difícil definir um nome pra eles;
› Uma mudança nesse objeto afeta vários
outros objetos dentro do sistema;
› O objeto tem várias propriedades nulas e
isso é comum;
39. Modelo de classes?
› É
o diagrama de classes acompanhado
de uma descrição textual definindo o
que cada classe faz no sistema;
› Existe
em três diferentes tipos, domínio,
especificação e implementação;
41. Modelo de classes - Domínio
› Éo diagrama de classes puro, sem
dependência ou associação com a
tecnologia que vai ser utilizada;
› Normalmente só existe nos momentos
iniciais ou em rascunhos do sistema;
› Usa fortemente a linguagem ubíqua;
42. Modelo de classes -
Especificação
› Adicionadetalhes da implementação
que foi escolhida ao modelo (interfaces
de infraestrutura, classes base de
frameworks, funcionalidades da
linguagem);
› Normalmentedefinido antes de se entrar
em detalhes de implementação;
43. Modelo de classes -
Implementação
› Classes
implementadas na tecnologia
escolhida;
› Códigoreal e executável, normalmente
gerado inicialmente através dos modelos
definidos anteriormente;
44. Implementando um inventário
› Imagine uma livraria;
› Crie
modelos que representem o
inventário e que sejam capazes de fazer
uma busca dado o título, autor e/ou
categoria onde o livro se encontra;
› O
sistema deve ser capaz de encontrar
vários livros com uma única busca;
45. Associações no modelo
› Objetos estão sempre se relacionando
entre si, esses relacionamentos são
chamados de associações;
› Apesardo modelo ser um modelo de
classes, as associações são para os
objetos dessas classes;
47. Cardinalidade
› Definem
os limites inferiores e superiores
na associação entre dois objetos;
› Associações normalmente tem limites em
“0..1”, “0..N” ou “0..*”;
48. Exemplos de cardinalidade
Nome Simbologia
Apenas Um 1..1 (ou 1)
Zero ou Muitos 0..* (ou *)
Um ou Muitos 1..*
Zero ou Um 0..1
Intervalo Específico li..ls
50. Cardinalidade na fórmula 1
› Corridastem pelo menos 20 carros;
› Uma corrida só pode ter no máximo 24
carros;
› Um carro pode estar em várias corridas;
Carro Corrida
20..24 0..N
51. Participação
› Define
se uma associação é obrigatória
ou não entre os objetos relacionados;
› Se
a cardinalidade for 1, então ela é
obrigatória, se for 0 em algum momento
ela não é obrigatória;
52. Detalhes das associações em
UML
› Associações tem nomes, que definem o
seu significado dentro do sistema;
› Direção,definindo como você faz a
leitura da mesma;
› Papel,
para definir um papel específico
onde essa associação existe;
53. Exemplo de associação
Nome da Direção
Papel associação de leitura
Papel
contratante Contrata contratado
Organização Indivíduo
* *
54. Casos especiais: Agregação
› Losangos
definem a classe todo no
diagrama;
Afiliada membro
AssociaçãoEsportiva Equipe Jogador
* * * *
55. Classes associativas
› Classes
que existem para dar valores
especiais a uma associação entre
objetos;
› Utilizadas
quando não há sentido em
colocar os atributos em nenhuma das
classes relacionadas;
56. Exemplo de modelo com
classe associativa
Emprego
salário
dataContratação
Pessoa * * Empresa
nome
razãoSocial
telefone
empregado empregador endereço
endereço
58. Associações n-árias
› Utilizadas
para demonstrar associações
entre objetos de N classes;
› Associações ternárias são o caso mais
comum;
› Um
losango é a forma representada em
UML para essa associação;
59. Associação ternária
Projeto
Técnico 1 1
Uso nome
nome
verba
*
Computador
modelo
60. Associações reflexivas
› Associações
onde um objeto se associa a
outros objetos da mesma classe;
› Cadaobjeto tem um papel diferente na
associação, de forma que eles sejam
diferenciáveis;
62. Crie os diagramas de
associação entre os objetos
da loja
Lembre-se de adicionar as cardinalidades e os
nomes das associações.
63. Responsabilidades e
colaboradores
› Em sistemas OO, objetos encapsulam
tanto dados quanto comportamento.
› O comportamento de um objeto é
definido de tal forma que ele possa
cumprir com suas responsabilidades.
› Uma responsabilidade é uma obrigação
que um objeto tem para com o sistema
no qual ele está inserido.
› Através
delas, um objeto colabora (ajuda)
com outros para que os objetivos do
sistema sejam alcançados.
64. Responsabilidades e
colaboradores
› Naprática, uma responsabilidade é alguma
coisa que um objeto conhece ou faz.
(sozinho ou não).
› Um objeto Cliente conhece seu nome, seu
endereço, seu telefone, etc.
› Um objeto Pedido conhece sua data de
realização e sabe fazer o cálculo do seu total.
› Se
um objeto tem uma responsabilidade a
qual não pode cumprir sozinho, ele deve
requisitar colaborações de outros objetos.
65. Responsabilidades e
colaboradores
› Umexemplo: quando a impressão de uma
fatura é requisitada em um sistema de
vendas, vários objetos precisam colaborar:
› um objeto Pedido pode ter a responsabilidade
de fornecer o seu valor total
› um objeto Cliente fornece seu nome
› cada ItemPedido informa a quantidade
correspondente e o valor de seu subtotal
› os objetos Produto também colaboraram
fornecendo seu nome e preço unitário.
66. Responsabilidades e
colaboradoresObjetos
possuem
realizadas por
Responsabilidades Colaboradores
O que o objeto conhece O padrão de cooperação
+ (comunicação) entre objetos
O que o objeto faz
precisam de
67. Tipos comuns de objetos
encontrados nos sistemas
› Entidades;
› Value objects;
› Serviços;
› Repositórios;
› Controllers;
68. Camadas de um software
Presentation Layer
Application Layer
Domain Layer
Infrastructure Layer
69. Camadas de um software
› Cada camada só deve ter acesso direto
a objetos de si mesma ou de objetos em
uma camada inferior;
› Em alguns casos, a camada de
aplicação pode estar diretamente ligada
a camada de interface com o usuário;
› A camada do domínio deve ser sempre a
mais independente de todas dentro da
aplicação;
70. Entidades
› Objetos que não são definíveis apenas
através dos seus atributos;
› Eles representam uma linha de
identidade que existe de forma temporal,
mas que deve ser capaz de se comparar
com o mesmo objeto, ainda que hajam
atributos diferentes;
72. Entidades e identidade
› Em entidades, a identificação única não
deve depender somente de seus atributos,
deve haver um mecanismo de se identificar
se dois objetos são os mesmos independente
de o que eles aparentam ser;
› Um campo identificador (como o número do
cheque) pode ser adicionado ao objeto
para que ele possa ser comparado no futuro;
› Essa numeração deve ser garantidamente
única e imutável (como em colunas de auto-
incremento no banco de dados);
73. Value objetcs
› Nem tudo no domínio são entidades;
› Value objects são objetos que
representam valores e são comparados
apenas pelos seus atributos, eles não tem
identidade própria;
› Eles não são necessariamente simples,
mas o fato de não existir identidade faz
com que seja possível reutilizar, montar
caches ou pre-carregar value objects
sem maiores preocupações;
75. Ao implementar value objects
› Elesnormalmente são imutáveis, depois
de criados, não se alteram;
› É comum que sejam usados como no
padrão de projeto “Flyweight”;
› Podem ser criados de forma indireta
através de fábricas (que podem
implementar caching);
76. Services
› As vezes existem conceitos dentro do seu
modelo que não são coisas, mas atividades;
› Serviços servem para implementar “verbos”
que não estão cobertos por entidades ou
value objects dentro do seu modelo;
› Eles são stateless, executam a sua operação
mas não contém nenhum estado;
77. Services e layers
› Serviços não existem somente na camada do
domínio, eles podem estar também na
camada de aplicação e infra estrutura;
› Serviços de aplicação podem ser
responsáveis por organizar os dados antes
deles chegarem no domínio;
› Serviços de infra estrutura podem ser
responsáveis por falar com agentes externos
a aplicação, como companhias de cartão
de crédito;
79. Serviços como fronteiras
› Para
alguns autores, como Jacobson, existem
também os objetos de “fronteira”;
› Taisobjetos são definidos por serem serviços
que lidam com entidades externas ao
sistema e enviam os dados para clientes;
› Essesserviços são vistos como serviços de
infra estrutura;
80. Serviços como Fronteiras - 2
› Fronteiras
seriam qualquer entidade
externa, como:
› Usuáriosatravés de uma interface gráfica;
› Web services;
› Servidores de dados externos, como email
e bancos de dados;
› Arquivos;
81. Módulos e Pacotes
› Num mundo ideal, deve existir baixo
acoplamento entre pacotes diferentes e alta
coesão dentro deles;
› Pacotes devem criar interfaces ou meios de
acesso indiretos para as suas classes;
› Se você não faz parte de um pacote, não
deve ficar olhando para todas as classes
dele, deve haver uma fachada que faça
com que você faça a sua tarefa;
82. Integridade referencial no
domínio
› É difícil garantir a integridade referencial de
um modelo quando todo mundo pode
apontar pra todo mundo;
› Se uma Pessoa tem um Endereço e uma
Conta aponta diretamente para o Endereço
da pessoa, ao remover a Pessoa, o Endereço
é removido e Conta fica apontando para o
Nada;
› O uso de referências deve ser controlado de
forma que as dependências sejam
minimizadas;
83. Aggregates
› É normal existir interdependências entre os
objetos do modelo, mas também é normal
que alguns objetos tornem-se mais
importantes do que outros;
› Se uma Conta precisa saber o Endereço de
uma Pessoa, ela deve antes chegar a Pessoa
e depois acessar o Endereço;
› Aggregates definem os objetos que
funcionam como raízes dos relacionamentos,
protegendo os objetos que são internos a
eles;
84. Aggregates
› O objeto tido como raiz é o único objeto
que pode ser referenciado por objetos
que estejam “fora” do aggregate;
› Os objetos internos a raiz tem identidade
própria, mas essa identidade
normalmente também depende do
objeto raiz, eles não existem se o objeto
raiz não existir;
86. Repositories
› Fontes de objetos raiz carregados do
mecanismo de persistência para o modelo;
› Devem ser responsáveis por apenas um único
tipo de objeto, cada objeto deve ser o seu
(ou seus) repositórios;
› Idealmente devem se comportar como se o
cliente estivesse acessando dados em
memória (não deve deixar vazar detalhes de
sua implementação);
87. Controllers
› Servempara orquestrar as chamadas
que vem de serviços de infra-estrutura até
os objetos de domínio (value-objects e
entidades);
› Normalmente não contém lógica de
aplicação e funcionam muito mais
traduzindo dados externos para os
objetos do domínio;