programacao_orientada_objetos_II - Multivix

Prévia do material em texto

1
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
PROGRAMAÇÃO 
ORIENTADA A 
OBJETOS II 
2
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
A Faculdade Multivix está presente de norte a sul 
do Estado do Espírito Santo, com unidades em 
Cachoeiro de Itapemirim, Cariacica, Castelo, Nova 
Venécia, São Mateus, Serra, Vila Velha e Vitória. 
Desde 1999 atua no mercado capixaba, des-
tacando-se pela oferta de cursos de gradua-
ção, técnico, pós-graduação e extensão, com 
qualidade nas quatro áreas do conhecimen-
to: Agrárias, Exatas, Humanas e Saúde, sem-
pre primando pela qualidade de seu ensino 
e pela formação de profissionais com cons-
ciência cidadã para o mercado de trabalho.
Atualmente, a Multivix está entre o seleto 
grupo de Instituições de Ensino Superior que 
possuem conceito de excelência junto ao 
Ministério da Educação (MEC). Das 2109 institui-
ções avaliadas no Brasil, apenas 15% conquistaram 
notas 4 e 5, que são consideradas conceitos 
de excelência em ensino.
Estes resultados acadêmicos colocam 
todas as unidades da Multivix entre as 
melhores do Estado do Espírito Santo e 
entre as 50 melhores do país.
 
missão
Formar profissionais com consciência cida-
dã para o mercado de trabalho, com ele-
vado padrão de qualidade, sempre mantendo a 
credibilidade, segurança e modernidade, visando 
à satisfação dos clientes e colaboradores.
 
Visão
Ser uma Instituição de Ensino Superior reconheci-
da nacionalmente como referência em qualidade 
educacional.
GRUPO
MULTIVIX
3
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
bibLioteCa mULtiViX (dados de publicação na fonte)
As imagens e ilustrações utilizadas nesta apostila foram obtidas no site: http://br.freepik.com
de Campos Souza Paulo Vitor
Programação Orientada a Objetos II / de Campos Souza Paulo Vitor. – Serra: Multivix, 2019.
editoriaL
Catalogação: Biblioteca Central Anisio Teixeira – Multivix Serra
2019 • Proibida a reprodução total ou parcial. Os infratores serão processados na forma da lei.
FaCULdade CaPiXaba da serra • mULtiViX
Diretor Executivo
Tadeu Antônio de Oliveira Penina
Diretora Acadêmica
Eliene Maria Gava Ferrão Penina
Diretor Administrativo Financeiro
Fernando Bom Costalonga
Diretor Geral
Helber Barcellos da Costa
Diretor da Educação a Distância
Pedro Cunha
Conselho Editorial
Eliene Maria Gava Ferrão Penina (presidente 
do Conselho Editorial)
Kessya Penitente Fabiano Costalonga
Carina Sabadim Veloso
Patrícia de Oliveira Penina
Roberta Caldas Simões
Revisão de Língua Portuguesa
Leandro Siqueira Lima
Revisão Técnica
Alexandra Oliveira
Alessandro Ventorin
Graziela Vieira Carneiro
Design Editorial e Controle de Produção de Conteúdo
Carina Sabadim Veloso
Maico Pagani Roncatto
Ednilson José Roncatto
Aline Ximenes Fragoso
Genivaldo Félix Soares
Multivix Educação a Distância
Gestão Acadêmica - Coord. Didático Pedagógico
Gestão Acadêmica - Coord. Didático Semipresencial
Gestão de Materiais Pedagógicos e Metodologia
Direção EaD
Coordenação Acadêmica EaD
4
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
Aluno (a) Multivix,
Estamos muito felizes por você agora fazer parte 
do maior grupo educacional de Ensino Superior do 
Espírito Santo e principalmente por ter escolhido a 
Multivix para fazer parte da sua trajetória profissional.
A Faculdade Multivix possui unidades em Cachoei-
ro de Itapemirim, Cariacica, Castelo, Nova Venécia, 
São Mateus, Serra, Vila Velha e Vitória. Desde 1999, 
no mercado capixaba, destaca-se pela oferta de 
cursos de graduação, pós-graduação e extensão 
de qualidade nas quatro áreas do conhecimento: 
Agrárias, Exatas, Humanas e Saúde, tanto na mo-
dalidade presencial quanto a distância.
Além da qualidade de ensino já comprova-
da pelo MEC, que coloca todas as unidades do 
Grupo Multivix como parte do seleto grupo das 
Instituições de Ensino Superior de excelência no 
Brasil, contando com sete unidades do Grupo en-
tre as 100 melhores do País, a Multivix preocupa-
-se bastante com o contexto da realidade local e 
com o desenvolvimento do país. E para isso, pro-
cura fazer a sua parte, investindo em projetos so-
ciais, ambientais e na promoção de oportunida-
des para os que sonham em fazer uma faculdade 
de qualidade mas que precisam superar alguns 
obstáculos. 
Buscamos a cada dia cumprir nossa missão que é: 
“Formar profissionais com consciência cidadã para o 
mercado de trabalho, com elevado padrão de quali-
dade, sempre mantendo a credibilidade, segurança 
e modernidade, visando à satisfação dos clientes e 
colaboradores.”
Entendemos que a educação de qualidade sempre 
foi a melhor resposta para um país crescer. Para a 
Multivix, educar é mais que ensinar. É transformar o 
mundo à sua volta.
Seja bem-vindo!
APRESENTAÇÃO 
DA DIREÇÃO 
EXECUTIVA
Prof. Tadeu Antônio de Oliveira Penina 
diretor executivo do grupo multivix
5
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
Lista de FigUras
 > FIGURA 1 - Diagrama de Classes 15
 > FIGURA 2 - Diagrama de Casos de Uso 16
 > FIGURA 3 - Diagrama de Sequência 17
 > FIGURA 4 - Criação de três objetos Casa com suas 
respectivas características 20
 > FIGURA 5 - Exemplo de diagrama de componentes 24
 > FIGURA 6 - Interface programada na linguagem C# 33
 > FIGURA 7 - Contêiner de conteúdo representando um calendário 40
 > FIGURA 8 - Interface do Visual Studio 42
 > FIGURA 9 - Exemplo de interação com o usuário 
durante transferência e cópia de arquivos 43
 > FIGURA 10 - Mensagem de aviso de um sistema computacional 44
 > FIGURA 11 - Diagrama de casos de uso 46
 > FIGURA 12 - Exemplo de diagrama de sequência da UML 47
 > FIGURA 13 - Exemplo de diagrama de componentes 47
 > FIGURA 14 - Planejamento de etapas do escopo de projeto 
de componentes 52
 > FIGURA 15 - Reunião para definição da documentação do projeto 53
 > FIGURA 16 - Pesquisas em interfaces de hardware e software 
para a inclusão de novos componentes 56
 > FIGURA 17 - Windows 57
 > FIGURA 18 - Interface do Linux 58
 > FIGURA 19 - Máquina atuando na vida das pessoas 62
 > FIGURA 20 - Divisão de serviços de software 68
 > FIGURA 21 - Serviços de software 69
 > FIGURA 22 - Sistemas ERP e sua relevância para a empresa 70
 > FIGURA 23 - Exemplo de soluções completas para compras on-line 72
 > FIGURA 24 - Repositório de componentes compartilhando 
serviços de software 75
6
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
 > FIGURA 25 - Comunicação de dispositivos localmente 
separados por meio de requisições e mensagens 76
 > FIGURA 26 - Serviços de software 79
 > FIGURA 27 - Matriz de avaliação entre reúso e produtividade 85
 > FIGURA 28 - Classe Usuario 87
 > FIGURA 29 - Principais etapas que devem existir em reúso 
de componentes 88
 > FIGURA 30 - Elementos presentes nas interfaces web 94
 > FIGURA 31 - Destaque das responsabilidades em grandes 
empresas e sistemas 99
7
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
sUmÁrio
1UNIDADE
2UNIDADE
3UNIDADE
1 reVisão de ConCeitos de orientação a objetos e 
ConCeitos de ComPonentes 13
1.1 1. REVISÃO DE CONCEITOS DE ORIENTAÇÃO A OBJETOS E 
CONCEITOS DE COMPONENTES 14
1.1.1 INTRODUÇÃO AO DESENVOLVIMENTO DE SOFTWARES 
ORIENTADOA OBJETOS 14
1.1.2 CLASSES E OBJETOS 18
1.1.3 ATRIBUTOS E MÉTODOS 20
1.1.4 INTRODUÇÃO AOS COMPONENTES DE SOFTWARE 23
1.1.4.1 EXEMPLOS DE UTILIZAÇÃO DE COMPONENTES 28
ConCLUsão 29
2 interFaCes, ContÊineres, interação e Projetos 
de ComPonentes 31
2.1 INTERFACES, CONTÊINERES, INTERAÇÃO E PROJETOS 
DE COMPONENTES 32
2.1.1 INTERFACES 32
2.1.1.1 EXEMPLOS DE INTERFACES 35
2.1.2 CONTÊINERES 38
2.1.3 INTERAÇÃO 42
2.1.4 PROJETOS 45
ConCLUsão 48
3 esCoPo, objetiVo e abstração de ComPonentes 50
3.1 CONCEITO DE ESCOPO DE COMPONENTES 50
3.1.1 RECURSOS UTILIZADOS NO ESCOPO DE COMPONENTES 50
3.1.1.1 EXEMPLOS DE PROBLEMAS EM ESCOPO DE COMPONENTES 59
3.2 PRINCIPAIS OBJETIVOS DOS COMPONENTES 59
3.3 ABSTRAÇÃO DE COMPONENTES 61
ConCLUsão 65
8
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
sUmÁrio
4UNIDADE
5UNIDADE
6UNIDADE
4 granULaridade, LoCaLiZação e serViço de ComPonentes 67
4.1 4 GRANULARIDADE, LOCALIZAÇÃO E SERVIÇOS DE COMPONENTES 67
4.1.1 GRANULARIDADE DE COMPONENTES 67
4.1.2 LOCALIZAÇÃO DE COMPONENTES 74
4.1.3 SERVIÇOS DE COMPONENTES 78
ConCLUsão 80
5 reÚso e reFatoração de ComPonentes de soFtWare 82
5.1 REÚSO E REFATORAÇÃO NOS COMPONENTES DE SOFTWARE 83
5.1.1 REÚSO DE COMPONENTES DE SOFTWARE 83
5.1.1.1 PROJETOS DE COMPONENTES COM REÚSO 87
5.2 REFATORAÇÃO DE COMPONENTES DE SOFTWARE 89
ConCLUsão 94
6 PadrÕes de Projeto Para ConstrUção de 
ComPonentes Com reÚso 96
6.1 PADRÕES DE PROJETO PARA A CONSTRUÇÃO DE 
COMPONENTES COM REUSO 97
6.1.1 INTRODUÇÃO AOS PADRÕES DE SOFTWARE 97
6.1.2 PRINCÍPIO DE RESPONSABILIDADE ÚNICA 98
6.1.3 PRINCÍPIO DE SEGREGAÇÃO DE INTERFACES 100
6.1.4 PRINCÍPIO DO ABERTO FECHADO 101
6.1.5 PRINCÍPIO DE SUBSTITUIÇÃO DE LISKOV 103
6.1.6 PRINCÍPIO DE INVERSÃO DE DEPENDÊNCIAS 105
ConCLUsão 107
reFerÊnCias 108
9
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
iConograFia
ATENÇÃO 
PARA SABER
SAIBA MAIS
ONDE PESQUISAR
DICAS
LEITURA COMPLEMENTAR
GLOSSÁRIO
ATIVIDADES DE
APRENDIZAGEM
CURIOSIDADES
QUESTÕES
ÁUDIOSMÍDIAS
INTEGRADAS
ANOTAÇÕES
EXEMPLOS
CITAÇÕES
DOWNLOADS
10
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
APRESENTAÇÃO DA DISCIPLINA
Olá, alunos! Bem-vindos à disciplina Programação Orientada a Objetos II. 
O desenvolvimento de software evolui assim como os desejos da sociedade. Por-
tanto, os novos profissionais devem estar aptos a atender às principais vontades de 
seus clientes, fazendo suas atividades com eficiência e economicidade de recursos. 
Para tal, os desenvolvedores precisam conhecer as principais técnicas de construção 
de softwares, para que o trabalho seja reconhecido e valorizado. Em um mercado 
competitivo, uma formação sólida e o conhecimento dos principais fundamentos da 
orientação a objetos e qualidade de software tornam-se necessários para uma evolu-
ção gradual da carreira profissional dos desenvolvedores e da qualidade do desenvol-
vimento de softwares no país. 
Nesse curso, você irá aprimorar seus conhecimentos sobre orientação a objetos, pen-
sando de uma forma mais crítica e prática sobre os principais conceitos de qualidade 
que envolvem esse tipo de disciplina. Aprenderá, também, a importância da orienta-
ção a objetos para construir elementos da tecnologia da informação, que atendam 
a requisitos de qualidade e que possibilitem a satisfação do cliente, bem como criar 
objetos menos acoplados e mais reutilizáveis. Se você ainda não sabe do que isso se 
trata, pode ter certeza que, durante o curso, aprenderá esses e inúmeros outros con-
ceitos. A abordagem prática e conceitual o auxiliará a entender sobre as principais 
necessidades do mercado de desenvolvimento de softwares e sobre quais conheci-
mentos o desenvolvedor de aplicativos computacionais necessita para se destacar. 
Os estudos sobre os componentes de software nortearão a sua forma de desenvolvi-
mento e o ajudarão a construir softwares mais representativos e com independência. 
Aproveite o material e faça bons estudos!
Objetivos da disciplina
Ao final desta disciplina, esperamos que você seja capaz de:
• Explicar como funcionam os principais conceitos da orientação a objetos por 
meio da construção de softwares com qualidade. 
• Registrar conhecimentos sobre os principais tipos de componentes de soft-
wares. 
11
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
• Analisar, aplicar e explicar os principais fatores que permitem que os com-
ponentes de softwares estejam presentes na rotina de desenvolvedores e de 
fábricas de software.
• Criar elementos de softwares reutilizáveis. 
• Identificar as principais características e os impactos para a produtividade de 
um desenvolvimento eficiente de softwares.
• Reafirmar a relevância do desenvolvimento de softwares, seguindo padrões de 
projeto com foco no desenvolvimento eficiente de aplicativos.
12
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
OBJETIVO 
Ao final desta 
unidade, 
esperamos 
que você:
> Recordar os 
principais elementos 
presentes na 
orientação a objetos.
> Avaliar a produção 
de softwares 
reutilizáveis por meio 
de componentes 
independentes.
> Identificar 
características 
fundamentais de 
programação de alto 
nível.
UNIDADE 1
13
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
1 REVISÃO DE CONCEITOS 
DE ORIENTAÇÃO A 
OBJETOS E CONCEITOS DE 
COMPONENTES
A orientação a objetos (OO) gerou uma evolução nas linguagens estruturadas para 
que o desenvolvimento de softwares fosse mais eficiente, permitindo que soluções 
que funcionassem bem para um problema pudessem ser aproveitadas por outros 
softwares. A OO facilita a tradução das necessidades dos clientes (requisitos) em co-
dificação, permitindo que o gap semântico seja menor entre o que o cliente deseja e 
a solução construída. 
Quando um sistema é desenvolvido orientado a objetos, qualquer alteração nos re-
quisitos não gera impactos tão profundos quanto se ele fosse desenvolvido de forma 
estruturada. A OO fundamenta-se na utilização de componentes individuais que pos-
suem representatividade para o contexto. Eles são chamados de objetos e possibili-
tam a construção de sistemas complexos, fazendo a análise por meio de situações e 
contextos vividos no mundo real. 
Os principais componentes a serem desenvolvidos em um sistema devem permitir 
que cada uma das partes seja individualizada, eficiente e com entendimento com-
pleto. Assim, muitos sistemas originaram-se de partes de outros sistemas mais com-
plexos. Os objetos podem se comunicar por troca de mensagens, possibilitando ações 
que seriam extremamente morosas de acontecer se estivessem implementadas de 
forma estruturada. Portanto, nesta unidade, serão estudados os principais conceitos 
que definem a construção de softwares orientada a objetos e como essas técnicas 
permitem a compreensão e construção de componentes de softwares.
14
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
1.1 1. REVISÃO DE CONCEITOS DE ORIENTAÇÃO A 
OBJETOS E CONCEITOS DE COMPONENTES
1.1.1 INTRODUÇÃO AO DESENVOLVIMENTO DE 
SOFTWARES ORIENTADO A OBJETOS
Os desenvolvedores passam por diversos processos para coletar todas as informações 
referentes ao desejo do usuário em uma solução informatizada. O processo de cole-
ta,elucidação, desenho dos requisitos e uma representação gráfica ou visual desse 
processo é chamado design de projetos de software. É preciso conhecer ferramentas 
que traduzam os desejos do cliente em processos que possibilitem a elaboração de 
documentos com símbolos padrões, que realizem a conclusão da solução informa-
tizada. Esses documentos são chamados de especificação de software e contêm os 
principais digramas, capazes de apresentar as características a serem desenvolvidas 
para atender às expectativas dos stakeholders. Esses modelos são elaborados a partir 
de uma linguagem padrão no mundo da computação, a UML. Ela permite criar os 
principais diagramas que possibilitam a tradução dos requisitos pelo especialista e a 
sua compreensão por parte dos desenvolvedores. Esse fator permite a execução das 
tarefas de acordo com o combinado junto ao cliente. 
A especificação de software deve ser:
1. Clara;
2. Sem ambiguidades;
3. Composta pelos diagramas que resolvam a solução;
4. Coerente com as necessidades do cliente;
5. Completa, agregando valor.
Em geral, a especificação de requisitos de software apresenta os seguintes diagra-
mas, que podem auxiliar no desenvolvimento de softwares com qualidade:
1. Diagrama de Caso de uso.
2. Diagrama de Contexto.
3. Diagrama de Classes.
15
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
4. Diagrama de Atividades.
5. Diagrama de Sequências.
6. Diagrama de Objetos.
7. Diagrama de Componentes.
Esses diagramas podem ser construídos com ferramentas que dão suporte à UML, 
por exemplo, o Astah, StarUML, dentre outros.
Então, para que um programa seja bem construído, o design deve ser elaborado com 
qualidade e seguindo os padrões de construção de artefatos. Na figura a seguir, está 
representado um diagrama de classes, no qual são apresentadas as principais enti-
dades presentes no software. Nele, estão listadas as classes importantes, sendo que 
cada classe tem seus atributos e cada um deles possui um tipo. Essa linguagem facili-
ta o desenvolvimento de softwares e a tradução das imagens em codificações. A esse 
processo de receber um diagrama e transformá-lo em código no C# (ou qualquer 
outra linguagem), dá-se o nome de engenharia direta. Quando se tem o código e se 
resolve criar os diagramas baseados na codificação disponível, o processo é chamado 
de engenharia reversa (DEITEL, 2007). 
FIGURA 1 - DIAGRAMA DE CLASSES
Fonte: SHUTTERSTOCK, 2018.
16
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
Na figura a seguir, está presente um diagrama de casos de uso que contém as princi-
pais funcionalidades do sistema. Em geral, esse diagrama apresenta também os ato-
res que podem interagir com cada caso de uso. Essa fase do design auxilia os desen-
volvedores na criação dos principais menus de funcionalidade de uma solução, além 
de determinar perfis de acesso de usuário de acordo com o papel que ele exerce no 
sistema. Acompanhado dos casos de uso e dos atores, têm-se os relacionamentos 
entre os atores e os casos de uso, que permitem melhor detalhamento e construção 
do sistema.
FIGURA 2 - DIAGRAMA DE CASOS DE USO
Fonte: SHUTTERSTOCK, 2018.
Já na figura seguinte, apresenta-se um diagrama que dá noções de como as princi-
pais funções do sistema vão funcionar, baseando-se principalmente em identificar 
as etapas, possíveis respostas e impactos nos sistemas e os atores responsáveis pela 
interação de uma atividade. Nessa figura, estão listados os principais envolvidos e as 
principais atividades para a locação de um filme. A diferença desse diagrama para 
um diagrama de atividades é que este contém a sequência correta de como as ativi-
dades devem acontecer.
 
17
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
FIGURA 3 - DIAGRAMA DE SEQUÊNCIA
Fonte: SHUTTERSTOCK, 2018.
Para saber mais sobre os principais diagramas que com-
põem a UML e como eles podem auxiliar no design de 
projetos de software, procure na internet por “Resumo de 
alguns diagramas UML”, do professor Eduardo Figueiredo.
Esses diagramas auxiliam na compreensão do mundo real e das necessidades do 
usuário para a programação em linhas de código, permitindo que seja realizada a 
construção de um software que atenda às principais necessidades levantadas pelo 
cliente. 
Gap Semântico - Diferença entre o problema levantado no 
mundo real e a abstração do modelo construído. Sua rela-
ção se dá de modo inversamente proporcional quando se 
avalia o gap semântico e o tempo da construção da solução.
18
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
1.1.2 CLASSES E OBJETOS
Conforme definido por Sharp (2008) , classes representam um tipo de dado comple-
xo. Elas são uma especificação para os objetos, descrevendo os dados que os com-
põem (o que podem armazenar) e o que eles podem executar (o que podem fazer). 
Diante desse contexto, é relevante entender que as classes surgem baseadas nos 
principais elementos que fazem parte do sistema. 
Por exemplo, se você está desenvolvendo um sistema de livrarias, existem classes que 
são fundamentais para um sistema que atenderá a essa demanda, como Livro, Clien-
te, Funcionário, Autor e qualquer outra representação que permita a todos os envolvi-
dos na construção desse sistema a criação de elementos que tenham razão de existir 
para essa livraria. A vantagem da orientação a objetos é que a criação dessas classes é 
genérica, atendendo à maioria dos contextos que envolvem, nesse caso, a livraria. Isso 
facilita a disseminação e a construção de elementos que possam ser reutilizados ou 
adaptados a outras linguagens ou sistemas. 
As classes são representadas na UML (Unified Modeling Language) pelo diagrama 
de classes e no desenvolvimento de softwares. Esse modelo gráfico apresenta todos 
os elementos que permitem a definição da livraria dentro do sistema informatizado. 
O trabalho de coleta de requisitos e a transformação em classes são realizados por 
profissionais de engenharia de software, que criam a especificação de requisitos de 
software com todas as classes e seus devidos elementos. 
Em um diagrama de classes, é possível identificar elementos que se fazem presentes 
na modelagem. Entre as classes, existem as ligações, a cardinalidade e a forma como 
os desenvolvedores devem construir essas classes, conforme a linguagem escolhida 
para o projeto. Dentro das caixas de classes, existem padronizações que devem ser 
seguidas, por exemplo, o nome da classe com a primeira letra maiúscula, os atributos 
(elementos que representam a classe), os métodos (operações realizadas pelas clas-
ses) e a forma como eles existem dentro desse contexto (se são numéricos, flutuantes, 
lógicos ou textuais). Para o desenvolvedor, um diagrama de classes bem elaborado 
permite a criação de classes de forma a atender aos requisitos.
19
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
Quando o desenvolvedor recebe um diagrama de classes 
da UML, ele faz a conversão dos elementos gráficos para 
os elementos de programação. Suponha que você rece-
beu um diagrama de classes que possui uma representa-
ção de uma classe Livro. Essa classe Livro tem 4 atributos 
privados, sendo o nome do tipo que permite textos, dois 
atributos inteiros que recebem o número de páginas e o 
código do livro, além de também referenciar uma chave 
estrangeira para um objeto Autor, permitindo que o livro 
seja ligado a um autor. A programaçãoda classe pode ser 
feita da seguinte maneira.
public class Livro {
 private String nome;
 private int numeroPaginas;
 private int codigo;
 private Autor autor;
//gets e sets
}
Ao se criarem as classes, pode-se construir suas instâncias por meio de atributos es-
pecíficos. Imagine que você deseja criar um livro de nome “Estudando Programa-
ção” com um número de páginas igual a 60, no qual seu código é o 001 e seu au-
tor chama-se “Paulo Souza”. Assim, atribuem-se características específicas às classes, 
transformando essas instâncias criadas nos chamados objetos. Na UML, podem ser 
criados diagramas de objetos para facilitar o entendimento sobre o contexto que se 
deseja transmitir para o sistema.
Representação do objeto da classe Livro:
Livro livro = new Livro();
Autor autor = new Autor();
autor.setNome(“Paulo Souza”);
livro.setNome(“Estudando Programação”);
livro.setNumeroPaginas(60); 
livro.setCodigo(001); 
livro.setAutor(Autor);
20
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
Objetos são as representações lógicas de elementos do mundo real. No contexto sis-
têmico, eles são instâncias das classes. As classes especificam dados e ações que os 
objetos devem seguir, mas são os objetos que armazenam informações e executam 
tais ações, diferenciando-se uns dos outros.
Por meio da figura a seguir, você entenderá melhor. Têm-se três objetos: c1, c2 e c3, 
estes são instâncias da classe Casa, ou seja, possuem número, cor, nome do arquite-
to e capacidade de executar a ação de abrir a porta, conforme definido pela classe. 
Entretanto, bem como no mundo real, cada casa possui características diferentes. 
A primeira casa (o objeto c1) possui o número 12 e a cor azul. Já a segunda casa (o 
objeto c2) possui o número 43 e a cor vermelha. A terceira casa (o objeto c3), por sua 
vez, possui o número 72, a cor branca e está com a porta aberta, indicando que o 
método abrePorta foi executado (GREENE et al., 2008 ).
FIGURA 4 - CRIAÇÃO DE TRÊS OBJETOS CASA COM SUAS 
RESPECTIVAS CARACTERÍSTICAS
Casa c1 = new Casa();
c1.numero = 12;
c1.cor = Color.blue;12
Casa c2 = new Casa();
c2.numero = 56;
c2.cor = Color.red;56
Casa c3 = new Casa();
c3.numero = 72;
c3.abreporta();72
Fonte: Adaptado de ROCHA, 2003 .
1.1.3 ATRIBUTOS E MÉTODOS
Os atributos e métodos de uma classe são os elementos que representam o contexto 
pretendido para ilustrar um contexto do mundo real dentro do sistema. No diagrama 
de classes, os atributos aparecem primeiro e os métodos são listados na parte inferior 
21
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
da classe, identificando quais funções e quais atributos aquela classe deve ter na sua 
representação. O diagrama de classes da livraria, por exemplo, pode apresentar de 
uma maneira genérica seus atributos e métodos. Na UML, existem símbolos que fa-
cilitam o desenvolvimento do software mediante a tradução dos sinais empregados 
para a codificação necessária.
O engenheiro de software ou o analista de sistemas deve planejar os diagramas de 
forma precisa e eficiente, principalmente se a empresa adotar as metodologias ati-
vas, pois quaisquer mudanças dentro desse contexto podem ser catastróficas para a 
operação dos desenvolvedores e testers. Portanto, deve-se trabalhar sempre com um 
escopo de projeto e de classes bem definido, buscando atuar de maneira mais dinâ-
mica e eficiente. O arquiteto deve pensar em lógicas e recursos que sejam capazes de 
atender às especificidades desse diagrama, e os desenvolvedores devem implemen-
tá-lo de forma integral.
Os quatro principais pilares da orientação a objetos são:
abstração: O desenvolvedor deve ser capaz de representar em classes e objetos os 
fatores de maior relevância a um contexto. A abstração deve partir desde a modela-
gem até o desenvolvimento orientado a objetos, permitindo que as classes possuam 
somente atributos presentes nos indivíduos modelados e que tenham relevância ao 
contexto apresentado (uma classe “aluno” pode ter como características relevantes, 
modeladas e programadas: o seu nome, a sua idade, a data de matrícula do curso, 
o curso que ele estuda. Veja que um apelido não seria viável para esse contexto de 
desenvolvimento, pois não acrescentaria nada nas funcionalidades do sistema saber 
o apelido do aluno).
encapsulamento: É o conceito que determina que o desenvolvedor deve programar 
as classes por meio de um isolamento aos elementos mais importantes de uma clas-
se. Essa proteção é dada aos atributos e/ou métodos de uma classe, que podem ser 
visíveis a todos os envolvidos no contexto proposto (public), privados a somente ele-
mentos internos da classe (private), ou então visíveis a todos dentro de um mesmo 
pacote (protected). Assim como na vida, a Orientação a Objetos (OO) permite que 
22
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
informações sejam compartilhadas a quem é de direito. Todos podem saber o seu 
nome (public), porém o seu local de trabalho é algo que você só compartilha com a 
família (protected) e ninguém, além de você ou de quem você desejar, precisa saber 
quanto você recebe de salário (private).
Herança: Para Barners (2009), dentro da Orientação a Objetos, o conceito de herança 
também remete a características dos seres humanos. Esse conceito permite ao de-
senvolvedor entender e diminuir a quantidade de linhas de código para resolver pro-
blemas que tenham o mesmo comportamento ou compartilham de mesmas fun-
cionalidades. A utilização de herança permite que o comportamento de uma classe 
seja herdado por outra classe, fazendo com que classes que tenham comportamen-
tos parecidos na maioria de suas funcionalidades possam compartilhar atributos, 
métodos ou contextos. Por exemplo: uma conta bancária possui diversos elementos 
em comum com uma conta corrente e uma conta poupança, porém essas contas 
se diferenciam entre suas principais funcionalidades. Ao invés de ter de desenvolver 
os mesmos métodos para cada uma das três classes, o ideal é desenvolver uma clas-
se com todos os atributos em comum para as demais envolvidas e fazer com que 
elas herdem esse comportamento (extends). Exemplo: public class ContaCorrente 
extends ContaBancaria. Nesse contexto, todos os atributos e métodos públicos pode-
rão ser utilizados também na classe ContaCorrente.
Polimorfismo: O polimorfismo remete a muitas formas. Isso significa que o desenvol-
vedor pode construir classes que remetam ao princípio de que duas ou mais classes 
derivadas de uma mesma superclasse podem utilizar funções ou métodos que pos-
suam a mesma assinatura, mas comportamentos diferentes em cada uma das clas-
ses, utilizando como referência um objeto de sua classe “Pai”. Essa técnica deve ser 
utilizada pelos desenvolvedores por meio da redefinição de métodos (sobrescrita ou 
overriding), quando um método já escrito ganha novas funcionalidades que sobres-
crevem o que havia sido previamente desenvolvido (SILVA FILHO, 2010). 
A utilização de recursos como herança, polimorfismo e encapsulamento permite que 
as tarefas para a construção do sistema sejam realizadas de forma mais rápida, pois 
você economiza funcionalidades que já foram desenvolvidas. Treinar esses conceitos 
é fundamental para se manter atualizado sobre as principais técnicas e metodolo-
gias de desenvolvimento de software.
23
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
Caso você não se lembre da contextualização de orientação 
a objetos, realize estudos auxiliares, pois esse é um tema 
necessáriopara que você entenda os próximos passos da 
disciplina. Existem artigos e livros que podem facilitar sua 
concepção sobre os principais conceitos da orientação a 
objetos, principalmente os indicados na ementa da disci-
plina. Não deixe de procurá-los, caso você tenha muitas dú-
vidas, e tente resolver os exercícios propostos. 
1.1.4 INTRODUÇÃO AOS COMPONENTES DE 
SOFTWARE
Os conceitos que envolvem os componentes de software estão intimamente ligados 
à orientação a objetos. Quando se programa orientado a objetos, busca-se uma re-
presentação do mundo real, permitindo que coisas sejam independentes e tenham 
funcionalidades representadas em sistemas computadorizados. Quando um recurso 
de software agrupa e encapsula diversas atividades e tarefas de um sistema comple-
xo, ele é considerado um componente. 
Para entender melhor: você utiliza um sistema operacional que é considerado um 
software robusto e completo, porém, ele não desempenha sozinho todas as ativida-
des. Por exemplo, você utiliza um editor de PDF ou editor de texto para estudar. Ele 
é um componente de software que permite a visualização de textos em um compu-
tador. Os editores são componentes que possuem características sólidas, atômicas 
e independentes para atuar na resolução de problemas complexos, principalmente 
ligados à edição e visualização de textos. Na UML, os componentes presentes em um 
software dão a dimensão de composição dos itens que fazem parte da estrutura de 
um software. Eles são representados em um diagrama de componentes.
24
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
FIGURA 5 - EXEMPLO DE DIAGRAMA DE COMPONENTES
Aplicación Alamacén Deportes
Identificacion.frm
Control y 
Análisis
Acceso a Base 
de Datos
Rutinas de Conexión
(Librerias.bas)
Identificacion.frm
BD
Aplicación Ventas Deportes
Fonte: WIKIMEDIA COMMONS, 2018.
No entanto, apesar de hoje se ter uma decisão mais aceita pela comunidade, a defi-
nição de componente se misturou com outros contextos e, durante muitos anos, foi 
alvo de diversas discussões acadêmicas, nas quais algumas frentes enxergavam os 
componentes como qualquer parte do software, e outros entendiam que os compo-
nentes deveriam ter vida própria se não estivessem trabalhando acoplados a outros 
sistemas. Apesar da confusão nas definições, é possível enxergar algo em comum. 
Sobre o componente, Greene (2008) aponta que:
• é visto como um pacote coerente de artefatos de software;
• pode ser desenvolvido independentemente;
• pode ser entregue como unidade;
• pode ser composto, sem mudança com outros componentes, para construir 
algo maior. 
Se você analisar esse contexto, ele representa tudo que pode ser estudado e apren-
dido com a orientação a objetos: entender o problema, separá-lo por meio de suas 
funcionalidades, programá-lo para que as execute com eficiência e permitir que ele 
tenha funcionalidades distintas daquelas ligadas a um software geral.
25
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
Baseando-se nessa definição, de acordo com Sharp (2008), tudo que se segue pode 
ser considerado componente:
• Utilizar uma plataforma de desenvolvimento web que utiliza frameworks com-
pletos para a construção de suas interfaces, como o jsp.
• Usar métodos de uma classe java ou em C# para realizar manipulações com 
textos.
• Utilizar em um computador soluções como o gestor de planilhas, controle de 
datas e eventos do calendário e outros softwares, que podem ter sua indepen-
dência e funcionalidades distintas. 
Nesse conceito de componente, existem os chamados frameworks, como o Ne-
tbeans, Eclipse e o Visual Studio, que condensam diversas ferramentas para auxiliar 
o seu trabalho no desenvolvimento de softwares. Eles possuem pacotes previamente 
instalados e permitem a instalação ou incorporação de outros pacotes de funciona-
lidades para que o desenvolvedor tenha um vasto conjunto de componentes para 
utilizar como for necessário.
Essa definição de componentes pode ser vista como uma ramificação dos conceitos 
fabris de produção. Nos dias atuais, é muito difícil uma empresa multinacional geren-
ciar todas as etapas do processo. Uma montadora de carros, por exemplo, só recebe 
os produtos acabados para efetuar a montagem de um carro. Fábricas distintas são 
responsáveis por fabricar bancos, volantes e outras peças necessárias. A fábrica, ana-
logicamente, funciona como um desenvolvedor de software, que é capaz de utilizar 
um recurso pronto para melhorar as funcionalidades ou a composição da página 
web que está sendo construída.
Já para o campo de linguagens de programação, utilizar soluções que já estão construí-
das facilitam a rotina. Se um desenvolvedor tivesse de criar um visual studio toda vez 
que fosse desenvolver um site, não se teria nem um terço dos atuais sites ou soluções 
informatizadas. Essa forma de utilizar componentes que já foram testados e validados 
facilita a rotina de execução das atividades de construção de sistemas. Como os com-
ponentes são considerados elementos que auxiliam no desenvolvimento dos softwa-
res, de acordo com Barners (2009), eles podem ser incluídos e classificados como:
26
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
• especificações: Existem ferramentas que facilitam a criação e consulta de dia-
gramas que representam os sistemas.
• Código executável: Podem representar um programa, plug-in ou recurso 
pronto a ser incorporado em um site. Um exemplo bem simples é o plug-in 
de segurança do home banking que é instalado em seu navegador.
• Código fonte: A utilização de códigos prontos de outros sistemas ou de outras 
linguagens permite que, por exemplo, uma página html se comunique com 
códigos em C# por meio de componentes ligados ao desenvolvimento mútuo 
dessa solução. Outro exemplo é o componente de CSS que torna uma página 
responsiva.
• Projetos (designs): Um projeto pode servir como componente se ele for uma 
parte integrante de um projeto maior. Essa situação ocorre com frequência 
quando sistemas passam a ser incluídos em outras soluções, por exemplo, os 
sistemas de validação de compras online que são incorporados em sites de 
outras instituições. São projetos robustos, completos e que permitem a valida-
ção de segurança da transação.
• testes: Ferramentas de testes podem servir como componentes quando são 
incorporadas por meio de plug-ins, os quais permitem que testes unitários 
sejam executados em todo momento de mudanças de atributos ou regras de 
negócio envolvidas em uma classe.
• documentação: Pode-se destacar como exemplo a documentação responsá-
vel por apresentar os principais diagramas, fluxos e requisitos necessários para 
a construção de um sistema. Ela tem sua linguagem própria e permite o apoio 
e a utilização de outras ferramentas na construção de sistemas.
No entanto, há de se destacar que, para uma disciplina de programação, os princi-
pais componentes estão ligados ao desenvolvimento e implementação de soluções 
informatizadas. Destacam-se como principais momentos ligados aos componentes 
de implementação:
1 Quando um pacote de classes construídas de forma independente é entregue 
como unidades de um produto;
2 Quando os componentes possuem interfaces definidas de forma explícita, permi-
tindo a visualização não ambígua dos serviços fornecidos por ela. 
27
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
Por fim, as interfaces também devem deixar claro de quais serviços necessitam para 
funcionar e também se podem ser compostas por um ou mais componentes.Portan-
to, um componente de desenvolvimento deve ter como característica base a cons-
trução de aplicações por montagem, isto é, que esse componente realize todo ou a 
maioria do trabalho por meio da composição de pedaços existentes para compor 
uma solução robusta. 
Isso quer dizer que um desenvolvedor pode pegar o calendário de uma aplicação e a 
tela de outra para criar um registro de agendamento de salas em uma instituição de 
nível superior. Veja que as soluções viviam em sistemas diferentes, como componen-
tes de outras soluções, e, juntas, buscam atender a uma outra demanda. Esse tipo de 
abordagem permitiu estudos sobre padrões de projeto que facilitassem a junção de 
componentes de soluções distintas para atender a um mesmo fim (BARNERS, 2009). 
Padrões como facade e bridge podem permitir que esses componentes conversem, 
mesmo que sejam implementados em linguagens distintas.
Um componente de software deve deixar claro e explícito quais interfaces ele utiliza 
para realizar suas transações. Uma interface é um contrato que especifica a fun-
cionalidade do componente. Nos componentes, elas são representadas por inter-
faces de serviços e por conectar outras tarefas necessárias para seu funcionamento. 
O componente não pode depender do contexto no qual ele vai atuar, a não ser atra-
vés dessa interface.
Muitos desenvolvedores confundem os conceitos de in-
terface de software e os elementos programáveis, que 
são do tipo interface. Quando se diz interface de software, 
trata-se da maneira como um software se comunica com 
um recurso (cabos, outros sistemas, outras tecnologias). 
As interfaces programáveis são aquelas nas quais são de-
finidas as chamadas dos principais métodos a serem exe-
cutados em um conjunto de classes que as implementa 
(BORATTI, 2007).
28
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
1.1.4.1 EXEMPLOS DE UTILIZAÇÃO DE COMPONENTES
As linguagens de programação têm se concentrado apenas em especificar as inter-
faces de serviços oferecidos, e não as de serviços usados pelos componentes. Isso 
prejudica o desenvolvimento com qualidade, pois acabam sendo geradas soluções 
excelentes para a resolução de problemas locais, mas que não permitem ser expan-
didas para outros sistemas. Fatores como programação incorreta e má-utilização dos 
conceitos de orientação a objetos podem gerar essas complicações.
Imagine que você está em uma fábrica de desenvolvimento de software e que, ao 
atender a uma requisição do usuário, recebeu o pedido para incorporar a assinatu-
ra digital nos documentos que são gerados pelo site de compras online do cliente. 
A boa programação de recursos e componentes pode gerar um menor trabalho den-
tro dessa empresa. Se outra solução (site institucional de uma faculdade) já utilizar 
a assinatura digital e esteja confirmado que esse componente funciona, o desenvol-
vedor pode economizar tempo e linhas de código, utilizando o código pronto para 
adaptá-lo ao site de seu cliente. Se a assinatura digital não estiver desenvolvida na 
programação de suas classes e organização de seus pacotes, pensando em coesão, 
coerência, acoplamento e boas práticas de programação, dificilmente o desenvol-
vedor conseguirá aproveitar a assinatura digital no site de compras sem levar outros 
problemas ou classes desnecessárias presentes no site institucional para o software 
de seu cliente. Portanto, desenvolver qualquer software ou componente com quali-
dade pode gerar menor retrabalho e maior eficiência na produção de softwares.
29
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
CONCLUSÃO 
Nesta unidade, foram abordados aspectos relativos aos conceitos de programação 
orientada a objetos e seus principais recursos. A importância das classes, métodos e 
atributos não pode ser desconsiderada quando um desenvolvedor de software atua 
de maneira a prezar pela qualidade de seu produto. O desenvolvimento de software 
a partir de padrões passa por uma documentação adequada, representativa e de 
fácil compreensão, utilizando termos técnicos que são padronizados pela UML. A mo-
delagem de problemas computacionais auxilia os envolvidos a trazerem o mundo 
real para o mundo computacional. Se ela for incorreta, todo o processo de desenvol-
vimento orientado a objetos será prejudicado.
Para construir softwares com qualidade, deve-se respeitar as principais formatações, 
normas e padrões da orientação a objetos, permitindo que classes sejam represen-
tativas, coesas, coerentes e que especifiquem de forma completa todos os elemen-
tos necessários para modelar os problemas. Na orientação a objetos, destacam-se 
também os conceitos de herança, polimorfismo, encapsulamento, classes e atributos, 
que formam o conjunto de representatividade do desenvolvimento de software.
Nesse contexto, é possível visualizar os principais conceitos envolvidos na construção, 
utilização e funcionalidades dos componentes. Eles estão presentes na fabricação 
de soluções informatizadas para melhorar a produtividade e aproveitar de maneira 
mais racional os recursos que já foram desenvolvidos e testados. Os componentes 
representam partes independentes, que utilizam interfaces para se conectar e enviar 
comandos a outros sistemas. Eles podem ser vistos como partes autônomas e inde-
pendentes na formação de um software robusto e completo.
30
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
OBJETIVO 
Ao final desta 
unidade, 
esperamos 
que você:
> Analisar os principais 
elementos de 
interfaces dos 
componentes.
> Avaliar as principais 
interações entre 
componentes e 
outros sistemas.
> Diferenciar projetos 
de software 
e projetos de 
componentes.
> Discutir as principais 
características de 
interfaces, contêiner, 
projetos e interações 
de componentes.
UNIDADE 2
31
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
2 INTERFACES, 
CONTÊINERES, INTERAÇÃO 
E PROJETOS DE 
COMPONENTES
O desenvolvimento de componentes de software envolve contextos importantes para 
a construção de partes relevantes e independentes do sistema. Essa construção ne-
cessita de fatores para facilitar a organização e a comunicação com outros sistemas. 
Um dos principais pilares da orientação a objetos é a comunicação entre sistemas e 
objetos, e, para isso, é necessário pensar no desenvolvimento de componentes por 
meio de interfaces que sejam bem claras e permitam a comunicação entre as neces-
sidades de funcionamento de um componente e os serviços que ele pode utilizar. 
Para armazenar diversos componentes, existe o conceito de contêiner, que segue a 
ideia principal de ser um repositório de componentes disponíveis assim que for ne-
cessária a sua utilização. Como os componentes possuem diversos contextos, proces-
sos e características peculiares, você verá formas de gerenciar sua construção e sua 
comunicação mediante projetos de componentes. As principais etapas, processos 
e procedimentos serão elucidados por meio de sua relevância e importância para a 
construção de sistemas eficientes. Essa é uma etapa do curso na qual são visualiza-
dos muitos recursos gráficos para facilitar a vida dos desenvolvedores na produção de 
softwares, em especial desktop.
Por fim, serão abordados conceitos sobre as formas de interação dos componentes 
com os demais elementos que vão requerer seus serviços. Você aprenderá elementos 
que podem ser incorporados aos projetos de componentes e garantir o sucesso de 
sua aplicabilidade em outros conceitos de software.
32
Programação orientada a objetosii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
2.1 INTERFACES, CONTÊINERES, INTERAÇÃO E 
PROJETOS DE COMPONENTES 
2.1.1 INTERFACES
Os principais conceitos de orientação a objetos estão ligados a sistemas que repre-
sentam as características humanas. Essas características devem ser replicadas na sua 
essência para que não existam problemas na criação e utilização dos sistemas. Um 
fator que facilita a forma como os sistemas podem se comunicar são as interfaces. 
Elas são responsáveis por fornecer os serviços dos componentes para os demais en-
volvidos no contexto do software no qual ele está inserido. As interfaces devem ser 
bem claras sobre a sua forma de comunicação, isto é, devem ter características que 
as diferenciem sobre como e quando permitem a comunicação do componente. 
Na interface do componente, são descritos os fatores a seguir: 
• Propriedades: as características configuráveis dos componentes, que serão le-
vadas em conta durante a sua execução. 
• métodos: rotinas chamadas por métodos são aquelas executadas por terceiros 
para solicitar os serviços fornecidos pelo componente. Exemplo: quando uma 
máquina de cartão solicita a comunicação com o banco do cliente após ele 
digitar a senha em uma máquina de cartão de crédito.
Outros elementos fundamentais em uma interface de componente são o seu núme-
ro de versão e série, que permite o rastreio sobre a data e o lote de sua produção, a 
sua linguagem de programação, pois, dependendo de como ela foi desenvolvida, são 
necessários elementos que permitam a comunicação entre itens programados em 
linguagens diferentes.
Você sabia que o plug de tomada, o famoso “T”, é uma interface, e pode ser analo-
gicamente um exemplo para prover serviços entre linguagens diferentes? No Brasil, 
existe um padrão de tomadas e pinos de energia em dispositivos eletrônicos único no 
33
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
mundo. Esse fator prejudica brasileiros que levam seus dispositivos para o exterior e 
não levam adaptadores de energia para carregá-los. Da mesma forma acontece com 
os softwares e seus componentes. Por mais que um sistema necessite de um serviço 
provido por um componente, ele deve conhecer as características de sua interface, 
assim como acontece quando um turista brasileiro precisa conhecer os padrões de 
tomada de energia no país para o qual ele está se dirigindo. O dispositivo “T” faz o 
papel da interface, permitindo uma comunicação entre dois dispositivos diferentes, 
padronizando e intermediando a sua comunicação. Com o software não é diferente. 
Uma interface entende as requisições vindas de um sistema e as transmite na forma 
que o componente consiga entender. O mesmo processo acontece quando as res-
postas do componente são levadas ao sistema que fez a requisição. Assim, as interfa-
ces têm papel fundamental nas linguagens de programação.
As interfaces são responsáveis por definir as dependências de outros componentes/
serviços através de chamada de contratos definidos por funções. Essas funções nas 
interfaces devem ser feitas de forma a permitir que os serviços providos por ela sejam 
implementados em todas as classes que estão dentro desse contexto. Ela funciona 
muito bem como um mecanismo de comunicação e invocação de métodos entre 
classes distintas, pois determina premissas mínimas necessárias para o contexto no 
qual ela está trabalhando. A figura a seguir apresenta um exemplo de programação 
de interface no C#.
FIGURA 6 - INTERFACE PROGRAMADA NA LINGUAGEM C#
Fonte: SHUTTERSTOCK, 2018.
34
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
Conhecendo a interface de um componente, é possível utilizá-la para compor aplica-
ções. Portanto, a definição de uma interface deve preconizar: a linguagem desenvol-
vida, o propósito da interface, o contexto de classes que ela pretende atender, e quais 
serviços ela deseja disponibilizar.
As interfaces de componentes podem ser descritas de diversas formas, pois em cada 
linguagem de programação ela pode ter características únicas de construção, porém 
seu propósito é sempre o mesmo: prover a comunicação e os serviços entre classes e 
elementos distintos. Em uma linguagem de descrição de interface (IDL) e nos mode-
los multilinguagem (permitem várias linguagens distintas trabalhando em um mes-
mo propósito, como linguagens de marcação e linguagens de script, por exemplo), 
pode-se destacar como funcionalidades relevantes das interfaces de componentes:
1. Utilização dos mecanismos de comunicação.
2. Interação com serviços.
3. Interação com suporte de execução.
Várias interfaces podem ser suportadas por um mesmo componente, permitindo que 
um método deva ser implementado em todas as classes envolvidas naquela solicita-
ção. Um exemplo prático é o seguinte: imagine que, em um sistema, todas as classes, 
ao receber o nome de um atributo, devem verificar se esse nome contém somente 
letras e se tem até o máximo de 250 caracteres. Por se tratar de uma obrigação do sis-
tema, várias classes presentes nele devem implementar a sua forma de contabilizar 
as letras e verificar se somente existem caracteres esperados pelo problema. 
Interfaces diferentes também podem ser fornecidas para cada tipo de usuário. 
Esse princípio norteia que uma interface deve atender a um componente ou classe 
específica. O princípio de segregação de interfaces facilita aspectos de reuso e acopla-
mento de códigos, garantindo que uma classe ou componente terá somente acesso 
aos dispositivos autorizados para ele e que sejam necessários a seu funcionamento. 
Isso acontece muito na rotina dos seres humanos, quando se contrata um serviço 
sem saber sobre todas as cláusulas contratuais. Se a leitura do contrato que está 
sendo assinado não for feita previamente, corre-se o risco de se ter que fazer funções, 
contextos ou atitudes indesejadas em condições normais. Nas classes, isso ocorre da 
mesma forma; portanto, programar uma interface e permitir que ela tenha acesso 
somente a métodos razoáveis para seu contexto é uma boa prática de programação.
35
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
Dentro do desenvolvimento de software, o conceito de interfaces também traz faci-
lidades para a relação entre classes. Elas podem definir formas e chamadas obriga-
tórias a serem cumpridas para que um conjunto de componentes ou classes possa 
atuar de forma conjunta para a resolução de um problema. As interfaces são respon-
sáveis por otimizar comandos de softwares e prover um conjunto de instruções que, 
obrigatoriamente, deve ser implementado àqueles que pertencem a seu contexto. 
Boas práticas de programação determinam que as interfaces devem seguir conceitos 
de qualidade, como, por exemplo, atender a contextos comuns, evitando a super-
posição de métodos que não pertençam a um contexto. De forma análoga, pode-se 
entender a interface como um contrato. Quando uma classe se liga a uma interface 
de software, deve seguir suas regras e suas definições, assim como os seres humanos 
quando assinando um contrato de prestação de serviços. Nesse contrato, existem as 
cláusulas que devem ser cumpridas e os requisitos mínimos necessários para realizar 
as atividades de forma coesa e eficiente. Com a interface de software não é diferente. 
Todos os métodos em uma interface são apresentados de forma simples, apresen-
tando um contrato sobre quais tipos de variáveis e respostas os principais métodos 
devem ter, deixando a cargo das classes a forma como vão implementá-los.
2.1.1.1 EXEMPLOS DE INTERFACESO conceito de interfaces se faz presente na vida do desenvolvedor de software, prin-
cipalmente quando ele pretende criar maneiras de separar e definir quais são as for-
mas de comunicação prioritárias entre classes e componentes.
As interfaces também podem ser usadas para definir contratos padronizados entre os 
componentes. Nela podem ser descritos os métodos que permitirão a comunicação 
e o fornecimento de serviços fundamentais para suas requisições. Ferramentas como 
o Visual Studio têm recursos que facilitam a criação de interfaces dentro do contexto 
de seu projeto. Para desenvolver uma interface, existem botões que já permitem ao 
desenvolvedor criá-las com maior facilidade.
A seguir, um exemplo de uma interface. Geralmente, elas seguem padrões de come-
çar seus nomes com a letra I. Não é obrigatório, porém, quanto mais você criar hábi-
tos desses conceitos, mais fácil entenderá os códigos de outros desenvolvedores. Para 
construir uma interface, a palavra reservada interface deve ser utilizada.
36
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
Interface ICliente{
void logar();
void imprimir();
void deslogar();
}
Nessa interface produzida, o desenvolvedor definiu que as funções obrigatórias para 
o contexto de um cliente na solução devem ser a de logar, imprimir e deslogar den-
tro do sistema. Esse tipo de chamada, colocando os nomes dos métodos e finalizan-
do com ponto-e-vírgula, cria um contrato entre todos que utilizam essa interface. 
Toda classe que implementá-la terá como obrigatório utilizar os métodos logar, im-
primir e deslogar. Se uma classe Cliente implementar a interface, ela deve seguir as 
premissas de seguir no cabeçalho de sua função, colocando o nome da classe, acom-
panhada pelo símbolo ‘:’ e o nome da interface que vai implementar. Nesse caso, se 
uma classe Cliente fosse implementar a interface ICliente, a sua chamada ficaria da 
seguinte forma:
class Cliente :ICliente
Quando esse comando fosse executado, obrigatoriamente a classe Cliente deve criar 
um corpo para os três métodos da interface ICliente, conforme o exemplo a seguir:
class Cliente :ICliente{
void logar(){
Console.WriteLine(“Seja bem-vindo!”);
}
void imprimir(){
Console.WriteLine(“Você pode imprimir!”);
}
void deslogar(){
Console.WriteLine(“Obrigado por utilizar o sistema!”);
}
}
37
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
A vantagem de se utilizar uma interface é que se outra classe, por exemplo, a classe 
Aluno, implementar a interface, ela pode escrever o corpo dos métodos de forma di-
ferente, para atender ao seu contexto. Veja a seguir:
class Aluno :ICliente{
void logar(){
Console.WriteLine(“Seja bem-vindo, aluno, bons estudos!”);
}
void imprimir(){
Console.WriteLine(“Você pode imprimir a apostila neste semestre!”);
}
void deslogar(){
Console.WriteLine(“Obrigado por utilizar o sistema. Bons estudos!”);
}
}
Outro fator relevante é que uma classe pode implementar quantas interfaces desejar. 
Supondo que exista uma interface chamada IAluno, que tem o método matricular, se 
a classe Aluno precisar dos métodos de um cliente e do método de matrícula, deverá 
fazer o seguinte comando:
class Aluno :ICliente, IAluno{
void logar(){
Console.WriteLine(“Seja bem-vindo aluno, bons estudos!”);
}
void imprimir(){
Console.WriteLine(“Você pode imprimir a apostila neste semestre!”);
}
void deslogar(){
Console.WriteLine(“Obrigado por utilizar o sistema. Bons estudos!”);
}
void matricular(){
Console.WriteLine(“Você está matriculado!”);
}
}
38
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
Portanto, construir uma interface de maneira adequada pode permitir a construção 
de classes e métodos que sigam o padrão eficiente na construção de componentes.
A Microsoft auxilia desenvolvedores apresentado exemplos de interfaces 
para que a comunidade saiba a maneira correta de programá-la e como 
ela pode interferir na comunicação entre componentes. Procure no site de 
documentos da Microsoft as palavras chave “IContainer Interface” e amplie 
seus conhecimentos com exemplos aplicados a sua rotina de desenvolvedor.
2.1.2 CONTÊINERES
Um contêiner é um ambiente de execução para componentes que foram disponibi-
lizados para outros sistemas. Eles agrupam conjuntos de componentes úteis para a 
execução das principais tarefas de um software, sendo os responsáveis pela ligação 
entre os componentes e o mundo exterior. De forma a comparar essa parte da pro-
gramação com o mundo real, imagine um contêiner em um cais no porto. Ele é uma 
caixa fechada que agrupa vários elementos para serem transportados de navio a ou-
tros países ou cidades. Esse contexto também vale no desenvolvimento de softwares, 
pois, dentro dos contêineres, existem elementos que facilitam o fornecimento de 
serviços e estão agrupados em unidades menores, que permitem que um software 
tenha funcionalidades relevantes por meio de um grupo de itens presentes na inter-
face de comunicação com o usuário (BORATTI, 2007). 
O contêiner tem como principal responsabilidade processar os pedidos de execução 
de serviços e os repassar ao componente, que tem como principal função processá-
-los. Ele evita que o componente tenha que interagir com o sistema operacional, pois 
ele é o suporte de comunicação com os serviços de aplicação. Ele atua permitindo 
que o componente seja independente do ambiente de execução, tornando-o mais 
portável e mais fácil de reutilizar. As interfaces do contêiner são:
39
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
• Definidas pelo modelo de componentes. 
• Vistas como uma API completa para execução de componentes.
• Recursos para tornar o código do componente mais portável.
• Reconhecidas como os primeiros passos para ser construída a comunicação 
do sistema com o usuário.
Pode haver diferentes tipos de contêiner: componentes sem estado, com estado tran-
siente (volátil) e com estado persistente. Eles utilizam recursos de software, hardware 
e serviços da plataforma de execução para executar o componente. 
Os contêineres possuem serviço de nomes que os permite localizar instâncias de 
componentes. Eles têm um serviço de comunicação responsável pela troca de in-
formações, além de um serviço de persistência e transação responsáveis, respectiva-
mente, por armazenar os estados dos componentes e manter a sua consistência nas 
operações. Por fim, seu serviço de segurança é capaz de autenticar componentes e 
verificar a autorização para executar os serviços requisitados.
O contêiner efetua callbacks quando necessita indicar falhas na obtenção ou na utili-
zação de recursos do suporte de execução. O contêiner pode:
• Entregar mensagens do serviço de comunicação. 
• Salvar o estado do componente.
• Restaurar-se em caso de reinicialização.
• Relatar a violação de regras de funcionamento ou de segurança.
• Apresentar uma interface simples, na qual outros elementos gráficos podem 
ser adicionados.
Os principais contêineres do Visual Studio podem ser visualizados na aba de ferra-
mentas, e destacam-se os painéis, os pointers e os Tab Controls. Em uma interface 
gráfica no C#, vários elementos podem ser adicionados a ele e, ao mesmo tempo, 
permitirem a comunicação e a interação com o usuário. Na figura a seguir, é possível 
visualizar um exemplo de contêiner que teve seu espaço preenchido com elementos 
de um calendário.
40
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada noD.O.U em 23/06/2017SUMÁRIO
FIGURA 7 - CONTÊINER DE CONTEÚDO REPRESENTANDO UM CALENDÁRIO
Fonte: SHUTTERSTOCK, 2018.
O código a seguir demonstra um exemplo de Tab Controls.
// Create a TabControl and set its properties 
1. 
2.TabControl dynamicTabControl = new TabControl(); 
3.dynamicTabControl.Name = “ExemploCapitulo2”; 
4.dynamicTabControl.BackColor = Color.Blue; 
5.dynamicTabControl.ForeColor = Color.Black; 
6.dynamicTabControl.Font = new Font(“Times”, 16); 
7.dynamicTabControl.Width = 400; 
8.dynamicTabControl.Height = 300; 
Nele podem ser identificados o tamanho da altura e largura do Tab Control, a cor de 
fundo e outras cores auxiliares. Com essa estrutura, o Tab Control pode receber abas, 
conforme o código a seguir:
41
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
// Add TabelaPagina1 
1. 
2.TabPage tabelaPagina1 = new TabPage(); 
3.tabPage1.Name = “pagina1”; 
4.tabPage1.Text = “Aluno”; 
5.tabPage1.BackColor = Color.White; 
6.tabPage1.ForeColor = Color.Black; 
7.tabPage1.Font = new Font(“Verdana”, 12); 
8.tabPage1.Width = 200; 
9.tabPage1.Height = 200; 
10.dynamicTabControl.TabPages.Add(tabelaPagina1 ); 
11. 
12.// Add TabelaPagina2 
13. 
14.TabPage tabelaPagina2 = new TabPage(); 
15.tabPage2.Name = “pagina2”; 
16.tabPage2.Text = “Disciplinas”; 
17.tabPage2.BackColor = Color.Pink; 
18.tabPage2.ForeColor = Color.White; 
19.tabPage2.Font = new Font(“Verdana”, 12); 
20.tabPage2.Width = 100; 
21.tabPage2.Height = 100; 
22.dynamicTabControl.TabPages.Add(tabelaPagina2); 
Esse código permite a criação de uma aba para alunos e outra aba para disciplinas.
Conhecer os recursos das ferramentas é de extrema relevância para seus estudos. 
Explore sempre os recursos de interface visual do desenvolvedor e aproveite todas as 
facilidades que ele propicia ao desenvolvimento de softwares.
O Visual Studio, assim como o Netbeans e o Eclipse (IDEs para desenvolvimento Java) 
possuem abas com as principais funções, métodos e classes prontos para o desenvol-
vimento de sistemas. Veja quais recursos estão disponíveis na sua ferramenta e apro-
veite as maneiras de otimizar sua rotina de trabalho. A figura a seguir mostra uma das 
interfaces de comunicação do Visual Studio com os desenvolvedores.
42
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
FIGURA 8 - INTERFACE DO VISUAL STUDIO
Fonte: SHUTTERSTOCK, 2018.
2.1.3 INTERAÇÃO
Um sistema eficiente deve ser construído para se comunicar de maneira clara com o 
usuário. Esses elementos estão agrupados em conjunto de conceitos que envolvem 
as interações. Sua principal responsabilidade junto aos componentes é prover as téc-
nicas e recursos de interação para a troca de dados e solicitação da execução de ser-
viços. Quando um usuário realiza um clique em um botão e recebe uma mensagem 
como resposta, pode-se dizer que um evento realizou uma interação com o usuário. 
A interação facilita a comunicação de componentes em um mesmo servidor local 
ou em servidores localizados em contextos distintos, também chamado de comu-
nicação remota. O ideal é que o desenvolvedor abstraia a localização e o comporta-
mento dos componentes, permitindo que as interações sejam adequadas ao tempo 
de resposta esperado pelo usuário. As interações foram programadas para atender a 
características específicas, como o clique de um mouse ou a digitação de uma tecla 
do teclado. Esses fatores permitiram a evolução de elementos gráficos em softwares, 
dando a eles características dinâmicas e maior experiência no uso das interfaces de 
softwares (SHARP, 2008).
43
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
O desenvolvedor pode utilizar esses recursos para facilitar o feedback das ações para 
os usuários. Isso torna o sistema desenvolvido mais amigável. Em geral, as interações 
podem acontecer por meio de:
Chamada remota de procedimento/método: os componentes estão em máquinas 
diferentes. A chamada tem que ser enviada como uma mensagem pela rede, e a res-
posta é recebida pelo mesmo meio.
Chamada local de procedimento/método: os componentes estão na mesma máqui-
na. Os recursos para a troca de mensagens tornam-se mais simples e intuitivos, per-
mitindo que as respostas e interações aconteçam com menor probabilidade de erro.
As notificações de eventos ocorridos são difundidas por produtores e entregues a 
consumidores de eventos. Os consumidores podem ser ou não componentes de in-
terface gráfica, e os produtores podem ser servidores de aplicação, outros softwa-
res complexos, ou até mesmo outros componentes. A figura a seguir apresenta uma 
mensagem de interação importante para o usuário durante a utilização de seus re-
cursos computacionais. Quando o operador do sistema está fazendo alguma tarefa 
que demanda mais tempo, como, por exemplo, o download de uma música ou de 
arquivos internos de seu computador, o sistema mostra uma mensagem, que é sem-
pre atualizada, mostrando o progresso da ação.
FIGURA 9 - EXEMPLO DE INTERAÇÃO COM O USUÁRIO DURANTE TRANSFERÊNCIA 
E CÓPIA DE ARQUIVOS
Fonte: SHUTTERSTOCK, 2018.
44
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
O desenvolvedor de software deve escolher as melhores maneiras de interagir com o 
usuário. Um evento definido de forma incorreta pode gerar expectativas, sensações 
e frustrações nos usuários. Um desenvolvedor que pensa na qualidade de softwares 
escolhe os recursos de eventos, mensagens e formas de interação mais adequados 
ao contexto que está atendendo dentro das ações no software. A figura a seguir apre-
senta uma interação na qual o usuário deve tomar uma decisão. As cores e ícones 
foram utilizados para melhor conduzir as suas escolhas (SHARP, 2008).
FIGURA 10 - MENSAGEM DE AVISO DE UM SISTEMA COMPUTACIONAL
Fonte: SHUTTERSTOCK, 2018.
Para saber mais e explorar suas capacidades de construir eventos com qua-
lidade, acesse o site Macoratti e procure os tópicos em C#. Ele apresenta di-
versos recursos e tutoriais para explorar as principais formas de programação 
de eventos e interações com o usuário.
45
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
2.1.4 PROJETOS
Os projetos de componentes favorecem as principais etapas de pensamento e organi-
zação para estruturar as principais funcionalidades a que um componente deve aten-
der, além de permitir um pensamento organizado e lógico para escolher formas de 
interações, comunicações e interfaces presentes na construção de um componente 
eficiente. Geralmente, em projetos de componentes, definem-se (GREENE et al., 2008):
1. O mecanismo de comunicação entre componentes. 
2. As questões não resolvidas pelo TCP/IP. 
3. O formato comum dos dados envolvidos na troca de serviços dos componentes.
4. A localização de componentes.
5. A segurança dos componentes.
6. Os protocolos usados pelos suportes de execução de componentes
O desenvolvimento de software é estudado em disciplinas de Engenharia de Softwa-
re e auxilia no levantamento de passos e etapas fundamentais para a construção de 
um projeto de componentes eficiente. Com base nas funcionalidades requeridas do 
sistema, definem-se quais componentes são necessários para sua construção, como 
eles devem se comunicar, a linguagem de programação utilizada, formas de comu-
nicação e quais serviços serão trocados entre os componentes envolvidos, bem como 
as respostas e requisições efetuadas. Nesses projetos, a reutilização de componentes 
que já foramdesenvolvidos pode sintetizar as atividades de um novo projeto.
Os desenvolvedores e analistas de sistemas devem pensar em soluções que possam ser 
adaptadas em vários tipos de projetos. Imagine que sua empresa está elaborando um 
plug-in inteligente de reconhecimento de voz. Esse tipo de tecnologia pode ser adapta-
do a vários sistemas informatizados, desktop, WEB e mobile. Um projeto deve levar em 
conta que: o componente deve fornecer serviços a outros componentes que os utilizarão 
por meio das interfaces do componente. Pensar as formas de comunicação, interação e 
interface pode ser o requisito fundamental para o sucesso do projeto. Deve ser possível 
ajustar a forma como os serviços são executados, alterando valores de propriedades, pa-
rametrizando-os conforme as necessidades de comunicação. O componente deve ser 
sujeito à composição, além de ser independente de outros componentes. 
46
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
Um bom projeto de componentes realiza suas atividades de modelagem do do-
mínio definindo as necessidades, os envolvidos, as entradas e saídas do problema. 
Nessa etapa, a viabilidade do projeto é discutida, sendo realizados estudos sobre os 
principais elementos que devem ser alvo de desenvolvimento para atender aos requi-
sitos da solução. O documento construído nessa etapa é a Especificação do Software, 
considerado um dos principais artefatos para consulta sobre o componente a ser de-
senvolvido. Para facilitar a construção desse documento, o modelo conceitual ajuda 
no gap semântico, modelando as principais entidades do mundo real que farão parte 
da resolução do problema por meio do componente produzido. A UML (Unified Mo-
deling Language) auxilia na construção dos principais artefatos da especificação de 
software dos projetos. A figura a seguir apresenta um esboço do diagrama de casos 
de uso, que auxilia os projetistas na etapa de modelagem conceitual das funcionali-
dades principais de um componente, evidenciando seus atores e como eles se comu-
nicam com as formas de entregar serviços que o sistema possui.
FIGURA 11 - DIAGRAMA DE CASOS DE USO
Fonte: SHUTTERSTOCK, 2018.
Outra modelagem importante no projeto de componentes é a forma dinâmica com 
que o software vai interagir com o meio. A UML volta a ser protagonista nesse mo-
mento por meio de diagramas de estado, atividades, sequência, entre outros. A figura 
a seguir apresenta um exemplo de diagrama de sequência.
47
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
FIGURA 12 - EXEMPLO DE DIAGRAMA DE SEQUÊNCIA DA UML
Fonte: SHUTTERSTOCK, 2018.
Por fim, a UML pode auxiliar na organização e no projeto de componentes mediante 
um diagrama, com foco nos principais elementos e interações dos componentes. 
O diagrama de componentes apresenta os elementos, as nomenclaturas e os paco-
tes onde tais componentes podem estar agrupados. A figura a seguir demonstra um 
exemplo de diagrama de componentes e pacotes.
FIGURA 13 - EXEMPLO DE DIAGRAMA DE COMPONENTES
Database Server
MySQL database
Web Server
Database interface
Presentation layer
(web interface)
Log file
Workstation
Web browser
HTTP/HTTPS connection
TCP/IP
or local socket
Keyboard/monitor
User
Fonte: WIKIMEDIA COMMONS. UML Deployment Diagram. Disponível em: <https://commons.wikimedia.org/wiki/File:UML_Deploy-
ment_Diagram.svg>. Acesso em: 19 dez. 2018.
48
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
Os componentes podem ter as principais interações modeladas, definindo requisi-
ções, regras de negócio e comportamento. Essas características podem ser visuali-
zadas na especificação dos componentes, a qual cria uma especificação detalhada 
das interfaces dos componentes, definindo as assinaturas de suas operações e suas 
propriedades.
CONCLUSÃO 
A construção de componentes reutilizáveis passa por conhecer elementos como 
interações, contêiner e interfaces para a construção de projetos de componen-
tes eficientes. As interfaces construídas nos softwares devem fomentar a organiza-
ção por meio de funcionalidades simples e que permitam a divisão de atividades 
e responsabilidades, de acordo com a natureza dos problemas a serem resolvidos. 
Fatores importantes na construção de componentes de software são as maneiras 
distintas que um usuário ou sistema pode receber uma resposta. A interação deve 
ser bem pensada e organizada para não prejudicar a aceitação do software no mer-
cado de consumidores a que atenderá. Portanto, planejar um componente, desde 
a sua concepção até a sua construção, não é uma tarefa complicada, mas deve se-
guir padrões bem definidos de qualidades em projetos, para que as modelagens e 
diagramas sejam feitos de forma correta e clara. Após a definição dos principais ele-
mentos que vão compor a interface do software, contêineres podem recebê-los de 
forma organizada para apresentar uma interface correta e esperada do componente. 
Seguindo passos definidos pela Engenharia de Software e aprofundando os recursos 
de IDEs de desenvolvimento e linguagens de programação, a construção de compo-
nentes pode se tornar uma tarefa mais simples e pertencente a seu cotidiano.
49
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
OBJETIVO 
Ao final desta 
unidade, 
esperamos 
que possa:
> Recordar as 
principais etapas 
do escopo de 
componentes.
> Avaliar os objetivos 
de um componente 
para a empresa.
> Descrever 
características 
presentes nas etapas 
de planejamento 
e construção de 
componentes.
> Avaliar os conceitos 
de abstração que 
podem existir nos 
componentes.
UNIDADE 3
50
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
3 ESCOPO, OBJETIVO 
E ABSTRAÇÃO DE 
COMPONENTES
Os componentes de software possuem muitos recursos que podem auxiliar outros 
sistemas na execução de tarefas menores. Eles são, muitas vezes, chamados de plu-
g-ins, que têm funções robustas e expressivas. Dentro desse contexto, é notório que 
podem existir problemas nas fases iniciais do projeto, permitindo que o componente 
não seja entregue de maneira adequada ao contratante do serviço. Nesta unidade, 
serão abordados aspectos teóricos e exemplificações dos impactos na organização 
de projetos de desenvolvimento de componentes, com ênfase principal nas etapas 
envolvidas no escopo dos componentes, a delimitação dos principais objetivos que 
o componente deverá atender e, por fim, serão apresentados aspectos que facilitam 
características de abstração desses elementos para as pessoas envolvidas no desen-
volvimento e na utilização dos dispositivos. Também serão evidenciados aspectos 
importantes da construção de documentação adequada para o desenvolvimento do 
software e como devem ser organizados os passos fundamentais para a construção 
ou a reutilização de componentes proveitosos e com qualidade.
3.1 CONCEITO DE ESCOPO DE COMPONENTES
3.1.1 RECURSOS UTILIZADOS NO ESCOPO DE 
COMPONENTES
Qualquer projeto organizado precisa de um ponto de partida para que suas ativida-
des sejam feitas de forma ordenada e eficiente. No contexto de dispositivos informa-
tizados, isso não foge à regra, sendo um fator preponderante para a organização e a 
explanação de ideias dentro da rotina do desenvolvimento. Sabe-se que existem re-
cursos gráficos para organizar elementos, permitir interações e a comunicação efetiva 
do usuário com o sistema desenvolvido, porém, eles devem seguir critérios que sejam51
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
possíveis de se resolver em tempo hábil, que atendam ao conhecimento da equipe 
de desenvolvimento de software e que sejam entregues produtos que o cliente irá 
utilizar. Portanto, planejar os principais passos e recursos que serão empregados nas 
etapas de construção dos componentes torna-se fundamental para entregas com 
qualidade. Nesse caso, refere-se ao escopo dos componentes. Eles podem ser auxilia-
dos por meio da construção de diagramas de caso de uso, caso de teste e diagrama 
de atividades, que permitem a compreensão do software de maneira efetiva por par-
te da equipe de desenvolvedores. Nessa etapa, são definidos os principais elementos 
que irão participar e contextualizar o componente: a quem ele se destina, como será 
utilizado, qual seu público-alvo, qual a escalabilidade e nível de utilização do compo-
nente.
Um grande número de gestores ainda não se preocupa com as etapas de do-
cumentação de software, como diagramas, especificações de desenvolvimento 
de software e muitos desenvolvedores não a mantêm atualizada. Lembre-se de 
que esses documentos são fundamentais para a manutenção dos softwares. 
Algumas correntes da programação e de metodologias ágeis não são adeptas a 
tanta documentação em um projeto, mas deixar de documentar não é incenti-
vado por nenhum tipo de metodologia de desenvolvimento de software.
Na etapa de escopo, os gestores desenvolvem recursos para facilitar o trabalho de de-
senvolvedores e projetistas, para que a construção de componentes não tenha maio-
res prejuízos. Imagine se a posição, as cores ou os recursos de contêiner não forem do 
gosto do cliente no produto final? Isso pode gerar um retrabalho muito elevado para 
adequar as soluções. Além de gerar uma insatisfação na equipe de desenvolvedores, 
os custos do projeto aumentarão com a grande quantidade de retrabalho. Em pro-
gramação orientada a objetos, a escolha inadequada de elementos do projeto pode 
interferir diretamente no acoplamento de classes, no desenvolvimento de interfaces 
de softwares e interfaces visuais. Isso torna o desenvolvimento moroso e pode torná-
-lo inviável no que concerne ao aspecto financeiro (Greene, 2008) .
A etapa de planejamento e definição de escopo de componentes pode utilizar recur-
sos para facilitar a organização e a determinação de passos a serem executados para 
52
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
o êxito do projeto. Como é nessa etapa que ocorre a definição de serviços, técnicas 
e metodologias empregadas para a construção do componente, devem compor a 
equipe de escopo de projeto pessoas que compreendam as etapas principais de seu 
desenvolvimento, além de conhecer fortemente os recursos humanos e técnicos da 
empresa. Em reuniões com o cliente para a captação de requisitos, suas necessida-
des devem ser limitadas ao conhecimento dos desenvolvedores, permitindo, assim, 
que um componente atenda, de forma mais coerente, as necessidades do contra-
tante. Porém, sabe-se que esse mundo ideal está longe de existir dentro da rotina 
de empresas de software: os clientes solicitam muitas demandas fora da realidade 
da empresa e do orçamento contratado, os desenvolvedores acabam trabalhando 
sobrecarregados, sem controle, qualidade e com uma eficiência bem limitada. Acre-
dita-se que esse seja um dos fatores principais para comprovar a chamada “teoria do 
caos” no desenvolvimento de softwares. É muito incomum que um projeto de desen-
volvimento de componentes e softwares aconteça sem maiores transtornos. A figura 
a seguir apresenta o ciclo de alguns processos que são envolvidos no planejamento 
de escopo do desenvolvimento de componentes.
1 Os autores do livro são responsáveis por uma experiência completa de apren-
dizado para programação orientada a objetos através de um dos livros mais 
usados em C#. Os autores também são autores de artigos internacionais em 
computação.
FIGURA 14 - PLANEJAMENTO DE ETAPAS DO ESCOPO DE PROJETO DE COMPONENTES
Fonte: SHUTTERSTOCK, 2018.
53
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
Já que a criação de componentes envolve etapas de documentação, sua criação, elu-
cidação e construção devem ser os primeiros artefatos a servir como base de escopo 
para os projetos, pois neles estarão presentes elementos fundamentais, como as prin-
cipais classes, como elas devem se correlacionar no projeto e, por fim, de que manei-
ra se dará a comunicação entre sistemas e usuários.
Elaborar uma boa documentação auxilia na diminuição do retrabalho, na programa-
ção de classes orientadas a objetos que sejam mais representativas ao problema, na 
utilização de recursos adequados para a construção de dispositivos e componentes 
necessários para a disseminação de serviços informatizados. A especificação de re-
quisitos de software torna-se um artefato fundamental para a rotina dos desenvolve-
dores, pois neles estão identificados os principais diagramas, as análises realizadas, 
podendo auxiliar na atualização de componentes existentes ou até mesmo na sua 
utilização em outros sistemas mais complexos, evidenciando, assim, a relevância da 
documentação adequada para as etapas iniciais do projeto. Sem esses fatores, difi-
cilmente a reutilização dos componentes acontecerá, pois a cada nova implementa-
ção, sem uma documentação adequada, elementos essenciais podem ser alterados 
e prejudicar o funcionamento geral do componente. Na figura a seguir, é apresenta-
da a importância do planejamento de uma documentação eficiente para o sucesso 
do projeto.
FIGURA 15 - REUNIÃO PARA DEFINIÇÃO DA DOCUMENTAÇÃO DO PROJETO
Fonte: SHUTTERSTOCK, 2018.
54
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
Existem etapas, de acordo com estudiosos da área, que devem ser seguidas para 
uma boa formação de escopo de projetos de componentes, das quais se destacam 
(Barners , 2009):
Seleção de componentes: No escopo dos componentes, é fundamental escolher os 
elementos necessários para trabalhar na construção ou na utilização de componen-
tes. Nesse caso, deve-se escolher, dentre os recursos necessários, os desenvolvedores 
que conheçam mais sobre as tecnologias definidas, os recursos gráficos e visuais que 
atendam corretamente às expectativas do cliente, além de identificar, na empresa 
em que trabalha, se não existe solução similar já desenvolvida. Nesse contexto, as 
alterações podem ser menores que construir um sistema integralmente do zero. As 
horas definidas para esse contexto de desenvolvimento, caso exista um componente 
similar, podem ser deslocadas para um atendimento necessário dentro do projeto, 
permitindo, assim, que o sistema seja desenvolvido de forma racional. Isso é valido 
se e somente se o componente existente foi desenvolvido mediante os critérios de 
qualidade de desenvolvimento de softwares.
Qualificação de componentes: Essa etapa é fundamental para um desenvolvimento 
confiável de componentes, pois nela são averiguados aspectos de performance, con-
fiabilidade e usabilidade dos componentes. Sem esses três fatores, o software estará 
fadado ao insucesso. Esses fatores verificarão se o componente a ser reutilizado ou 
desenvolvido é adequado ao contexto que ele pretende atender, identificando se 
existem interfaces de comunicações compatíveis, se as funcionalidades serão úteis ao 
novo contexto e, por fim, se ele tem aderência aos requisitos arquiteturais do sistema.
Adaptação de componentes: Os componentes construídos ou reutilizados precisamser alvo do escopo do projeto sobre os principais elementos de viabilidade em rela-
ção à sua adequação ao novo sistema do qual fará parte. Em grande parte dos casos, 
a comunicação entre sistemas ou componentes não funcionará em um primeiro mo-
mento. Para tal, é necessário levantar as necessidades e os recursos fundamentais, 
para que os componentes tenham um funcionamento adequado e integrado.
2 David Barnes leciona nas áreas de Ciências da Informação e Tecnologia e 
Segurança e Análise de Risco. Seus interesses de pesquisa incluem sistemas 
operacionais, segurança de computadores e redes, análise forense e risco. 
Informações sobre cursos que ele ensina podem ser encontradas em www.
personal.psu.edu/drb21. Ele tem um A.B. em economia pela Universidade de 
Duke e um J.D. da Escola de Direito Dickinson University.
55
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
A etapa de adaptação de componentes é uma das principais dentro do desen-
volvimento, pois, se não for possível a comunicação entre os recursos utilizados, 
o projeto pode se tornar um fracasso. A importância de encontrar elementos 
adaptáveis é vivenciada, em grande parte, por brasileiros que viajam ao exterior. 
No Brasil, a tomada de três pinos é o padrão presente na maioria dos disposi-
tivos informatizados, como notebooks e computadores, porém esse padrão só 
existe no Brasil. Um palestrante ou apresentador de trabalhos internacionais 
pode ter problemas ao utilizar os recursos de energia em outros países se não 
encontrar uma forma adequada de adaptar suas tomadas aos dispositivos de 
energia presentes nesses países. Se um palestrante não conseguir conectar seu 
notebook à energia, sua apresentação pode ficar comprometida. Imagine se o 
mesmo acontecesse com um software em produção para um cliente exigente. 
Portanto, jamais deixe de planejar planos contingenciais para a incompatibili-
dade de comunicação presente em softwares.
As interfaces de software também podem gerar conflitos nessa etapa, pois as funções 
presentes em uma interface podem não atender a um contexto específico de outro 
software no qual o componente será utilizado. Portanto, verificar todas as classes e as 
interfaces é fundamental para que o sistema seja adequado e pertinente ao contexto 
esperado. Problemas também podem surgir se o desenvolvimento de componentes 
for realizado por empresa terceirizada, em que a falta de padronização pode se elevar 
dependendo da complexidade do produto ou do prazo curto para entrega. Os ges-
tores, na fase de escopo de componentes, não podem deixar passar despercebidos 
esses fatores. Seus impactos podem ser catastróficos ao fluxo de desenvolvimento. A 
figura a seguir apresenta a importância de toda a equipe averiguar os requisitos de 
interfaces de hardware e software do projeto de componentes.
56
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
FIGURA 16 - PESQUISAS EM INTERFACES DE HARDWARE E SOFTWARE PARA A INCLUSÃO 
DE NOVOS COMPONENTES
Fonte: SHUTTERSTOCK, 2018.
Composição de componentes: A composição de componentes determina qual será 
a infraestrutura necessária para o funcionamento do componente em outro sistema. 
Pode parecer um fator simples, mas, se não for levado a sério, pode comprometer 
todo o bom andamento do desenvolvimento e a implantação dos componentes. 
Nesse momento, a escolha dos elementos é preponderante para uma organização 
e coerência nas funcionalidades de um componente. Existem desenvolvedores que 
podem tender a tentar colocar vários recursos dentro de um único componente, mui-
ta das vezes de forma desnecessária, transformando-o em um elemento com grande 
peso para a execução da aplicação. Quando se está adaptando um componente, é 
fundamental checar se todos os recursos obrigatórios para essa conexão e funciona-
mento existem: se a linguagem em que o componente está sendo desenvolvido é 
adequada para o software que o espera, se existem elementos de hardwares (placas, 
conectores, hardwares para transmissão e/ou comunicação de dados) e de softwares 
(sistemas operacionais, operadores, controladores) que delimitam ou restringem o 
funcionamento do componente. Isso pode acontecer também no nível de código, 
em que classes precisam ser adaptadas, incorporadas de recursos, para representa-
rem de forma adequada o contexto do software.
57
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
O sistema operacional é um software que funciona como interface entre os 
principais recursos de hardware e os comandos executados pelo usuário. Des-
tacam-se os recursos da linha Windows e Linux. Observe nas figuras a seguir 
elementos presentes nesses dois sistemas operacionais.
FIGURA 17 - WINDOWS
Fonte: SHUTTERSTOCK, 2018.
58
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
FIGURA 18 - INTERFACE DO LINUX
Fonte: SHUTTERSTOCK, 2018.
Atualização de componentes: A atualização dos componentes deve ser feita para 
sanar possíveis conflitos que podem surgir na incorporação de um componente a 
outro contexto de software. Mudanças em interfaces de comunicação e modo de 
interação com o usuário são elementos presentes nessa etapa do desenvolvimento. 
Planejar e delimitar um tempo adequado para essa etapa é uma obrigação dos ges-
tores de controle do projeto. Nessa etapa, as versões dos componentes e dos softwa-
res podem sofrer alterações, e sua estrutura passa por melhorias substanciais.
Etapa de escopo de componentes: Por fim, nessa etapa, deve-se avaliar se os com-
ponentes existentes são reusáveis, para evitar que sejam gastas homem-hora desne-
cessárias no desenvolvimento de softwares que já existem, e que somente precisa-
riam ser adequados. Esse fator também deve ser avaliado pelos gestores de escopo, 
em que uma criteriosa avaliação sobre o tempo necessário para adequar um com-
ponente pré-existente deve existir para aferir se é compensatório ou não modificar o 
componente ou construí-lo do zero.
59
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
3.1.1.1 EXEMPLOS DE PROBLEMAS EM ESCOPO DE 
COMPONENTES
Quando o escopo de um projeto não é realizado de forma adequada, algumas si-
tuações podem acontecer e gerar transtornos para os clientes e os desenvolvedores. 
Destacam-se:
Problemas com retrabalho: esse fator pode gerar insatisfações em desenvolvedores 
e clientes. Os clientes podem se sentir insatisfeitos devido à falta de entregas no pra-
zo e dentro do que eles esperavam. Se na etapa de escopo os diagramas não forem 
bem modelados, ou não refletirem a realidade do cliente, corre-se o perigo de se ge-
rar uma versão sem funcionalidade para um cliente, ou para outro tipo de dispositivo 
informatizado.
Problemas com infraestrutura: o contexto de necessidades de hardware e software 
pode impactar no funcionamento adequado de componentes. Se um modo físico de 
conexão não se adequar ao componente, ele não fará a comunicação com os demais 
dispositivos, permitindo, assim, que ele fique inoperante para o contexto para o qual 
ele foi desenvolvido. O desenvolvimento de softwares não permite que recursos infor-
matizados sejam produzidos e não sejam aproveitados.
Problemas de aumento de custos: quando o número de horas planejadas é excedi-
do devido a problemas de planejamento e contextualização do software, pode tornar 
o projeto inviável financeiramente (para o cliente pagar, ou para a empresa manter 
os custos).
3.2 PRINCIPAIS OBJETIVOS DOS COMPONENTESSobre os componentes, é importante ressaltar que eles podem ser construídos em 
qualquer linguagem, inclusive naquelas que não são orientadas a objetos. Esse fa-
tor deve ser avaliado quando dois componentes passam a se comunicar dentro de 
um projeto. A forma como os componentes de software podem atender a diversos 
projetos e, por consequência, podem realizar diversas atividades dentro de um con-
junto de recursos informatizados diz muito sobre seus objetivos para os contextos 
informatizados. Eles tendem a auxiliar os softwares com tarefas menores, atômicas e 
60
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
interpretáveis, permitindo que sejam diferenciáveis e se destaquem dentro do fun-
cionamento para o usuário. Um exemplo simples são os plug-ins auxiliares, que rea-
lizam tarefas fora do contexto original do software e atuam de forma a complemen-
tar o funcionamento do sistema. Um plug-in de identificação biométrica tem suas 
funções, suas classes e suas interfaces bem delimitadas, podendo atuar em sistemas 
gerenciais de uma empresa realizando a validação de recursos fundamentais para a 
segurança do sistema. De forma geral, o objetivo de um componente representa a 
sua única funcionalidade para um sistema complexo, permitindo que a ideia de se-
paração de contextos, formas, elementos seja notoriamente visualizada em projetos 
que utilizam componentes acoplados para realizar tarefas de seu funcionamento. 
Essa divisão de tarefas diminui a complexidade de um software, facilitando sua ma-
nutenção e correção de eventuais problemas.
Os componentes seguem as características de pacotes e encomendam, funcionam e 
provêm serviços de acordo com as requisições efetuadas pelo sistema principal. Eles 
são considerados sistemas autocontidos, tendo como principal característica estar 
envolvidos em camadas próprias e funcionarem por meio de requisições e respostas. 
Isso facilita a dinâmica de desenvolvimento, pois cada pedaço do seu software passa 
a representar características específicas.
Podem se destacar como principais objetivos gerais dos componentes (Sharp, 2008) 
3 :
1. Definir as tarefas a serem executadas no sistema;
2. Determinar o momento em que as atividades devem ser executadas;
3. Delimitar o grupo de sistemas, pessoas, usuários a executar um grupo de ativi-
dades;
4. Padronizar as requisições de softwares e componentes;
5. Padronizar a comunicação entre dispositivos;
6. Aumentar a comunicação e o reuso em atividades de desenvolvimento de sof-
tware.
Porém, existem objetivos específicos a um grupo de componentes e funcionalidades. 
Esses objetivos atuam de forma a representar a principal função do componente 
para o software como um todo. Um componente de assinatura digital, por exemplo, 
assim como componentes de reconhecimento de voz, fala, imagem e movimento, 
auxiliam nas características de segurança dos sistemas. Eles são vistos pelos usuários 
como componentes indispensáveis para a utilização segura do software. Nesse caso, 
61
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
eles também podem ser utilizados como validadores de acesso ou para confirmar 
uma transação importante no sistema.
3 John Sharp é o principal tecnólogo da Content Master, parte do CM Group 
Ltd, uma empresa de consultoria e criação técnica. Especialista em desenvol-
vimento de aplicativos com o Microsoft .NET Framework e problemas de inte-
roperabilidade, John produziu vários tutoriais, white papers e apresentações 
sobre sistemas distribuídos, serviços da Web e a linguagem C#. Ele é autor de 
vários livros populares, incluindo o Microsoft Windows Communication Foun-
dation, o Step by Step e o Microsoft Visual C# Step by Step.
Outros grupos de componentes se responsabilizam por facilitar a comunicação entre 
serviços de linguagens diferentes, tendo como principal objetivo participar de uma 
comunicação eficiente e coesa entre elementos de naturezas distintas.
São exemplos as atuações ligadas à gerência e ao controle de pacotes dentro de um 
sistema, componentes temporais que identificam tempo, elementos ligados à audi-
toria e à segurança de sistemas. Vale ressaltar também que, em dispositivos móveis, 
o conceito e os objetivos dos componentes estão mais fáceis de serem visualizados. 
Quando um dispositivo móvel é visualizado, visualizam-se objetivos e funções dife-
rentes para cada um dos componentes instalados no aparelho, que vão de controle 
do sono até elementos para o entretenimento e a comunicação.
3.3 ABSTRAÇÃO DE COMPONENTES
Todo ser humano aprende com suas experiências e vivências durante seu dia a dia. 
Esse conhecimento não pode ser desconsiderado e muito menos deixado de lado no 
desenvolvimento de componentes. A abstração é considerada a habilidade psicoló-
gica que os seres humanos têm de se concentrar num certo nível de um problema 
ou contexto, sem levar em consideração outros fatores que não sejam interessantes 
para o momento. Esses elementos devem estar presentes dentro dos componentes, 
pois a sua atuação deve ser discreta e eficaz, permitindo que as tarefas para as quais 
ele foi destinado sejam executadas de maneira coerente. A abstração deve ser utili-
zada como técnica de resolução de problemas nas diversas áreas de engenharia e 
computação, trazendo características esperadas para as soluções desenvolvidas. As 
linguagens de modelagem e de programação oferecem recursos para que se possa 
trabalhar a abstração, desde a sua modelagem, até a sua programação.
62
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
A abstração é um dos pilares da orientação a objetos. O gap semântico, que é a 
capacidade de trazer o mundo real para o mundo computacional, está ligado 
diretamente a esse contexto. O desenvolvedor deve pensar em componentes 
que representem ações de seres humanos sendo realizadas por computadores. 
A figura a seguir apresenta formas como os seres humanos imaginam a resolu-
ção de problemas reais.
FIGURA 19 - MÁQUINA ATUANDO NA VIDA DAS PESSOAS
Fonte: SHUTTERSTOCK, 2018.
63
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
Um componente é desenvolvido por meio de linguagens de programação, e suas 
tarefas são executadas para atender às necessidades de clientes ou de outros sis-
temas informatizados. A abstração está na capacidade de o componente não ser 
notado enquanto um conjunto de linhas de código, mas, sim, para o contexto que 
ele deseja atender. Em outras palavras, quanto mais próximo do real um dispositivo 
computadorizado é, maior é seu nível de abstração. Áreas como a robótica utilizam 
fortemente esses conceitos para trazer características humanoides a robôs. Softwares 
que possuem um bom conjunto de mensagens, claras, eficientes e que atendam 
às expectativas dos usuários, permitem por algum momento confundir sua cabeça, 
sobre se ele está interagindo com uma máquina ou um ser humano. Portanto, qual-
quer software desenvolvido em C# deve preconizar uma excelente interação com 
o contexto que ele pretende desenvolver, inclusive quando essa interação acontece 
com outro dispositivo informatizado. Existem transações, contextos, comandos em 
um sistema operacional realizando codificações de máquina e comunicando-se com 
dispositivos eletrônicos do computador que o ser humano não imagina. Essa capaci-
dade torna mais aceitável a utilização de recursos computacionais e mais compreen-
sível sua atuação junto a outros sistemas (Deitel, 2007) .4
4 Harvey M. Deitel, CEO da Deitel & Associates, Inc., tem 40 anos de experiênciano campo da computação, incluindo ampla experiência acadêmica e acadê-
mica. Ele é um dos principais instrutores de informática e apresentadores de 
seminários do mundo. Dr. Deitel ganhou B.S. e M.S. graus do Massachusetts 
Institute of Technology e um Ph.D. da Universidade de Boston. Ele tem 20 
anos de experiência em ensino universitário, Harvey M. Deitel, CEO da Deitel 
& Associates, Inc., tem 40 anos de experiência no campo da computação, in-
cluindo ampla experiência acadêmica e acadêmica. Ele é um dos principais 
instrutores de informática e apresentadores de seminários do mundo. Dr. Dei-
tel ganhou B.S. e M.S. graus do Massachusetts Institute of Technology e um 
Ph.D. da Universidade de Boston. Ele tem 20 anos de experiência em ensino 
universitário, incluindo a posse e atua como presidente do Departamento de 
Ciência da Computação da Boston College antes de fundar a Deitel & Asso-
ciates, Inc. com seu filho, Paul J. Deitel. Ele é autor ou co-autor de dezenas de 
livros e pacotes multimídia e atualmente está escrevendo muito mais. Com 
traduções publicadas em japonês, russo, espanhol, italiano, chinês básico, 
chinês tradicional, coreano, francês, polonês e português, os textos da Deitel 
ganharam reconhecimento internacional. O Dr. Deitel ministrou seminários 
profissionais internacionalmente para grandes corporações, organizações go-
vernamentais e vários ramos das forças armadas.
A abstração está presente em quase todos os contextos existentes na computação 
e no desenvolvimento de softwares com qualidade. O conceito de função presente 
no contexto de orientação a objetos permite abstrair os detalhes de implementação 
da funcionalidade que será executada pelo código, permitindo que o usuário foque 
64
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
somente as funcionalidades propiciadas, e não como ela é implementada. Outra for-
ma de aplicar a abstração dos conceitos do mundo real é a utilização correta dos 
diagramas da UML. O uso de diagramas que descrevem o software oferece uma visão 
abstrata do funcionamento, independentemente de como ele está implementado. 
Os diagramas de classe oferecem uma visão abstrata de como estarão presentes no 
software as principais entidades, como elas irão funcionar e existir dentro desse con-
texto. Já o diagrama de atividades permite a visualização de como essas classes, telas 
e interfaces irão se comunicar para a conclusão dos fatos. Outros diagramas, como 
os de caso de uso podem dar a ideia dos principais usuários e funcionalidades do 
sistema, permitindo, assim, que o usuário esqueça que o software é um conjunto de 
códigos de linguagem de programação e passe a visualizá-lo como um componente 
capaz de resolver seus problemas.
Veja o caso de sistemas que trabalham como repositórios de componentes. Eles são 
vistos como um conjunto de soluções para facilitar a vida de desenvolvedores que 
necessitam de componentes prontos. A aba de componentes gráficos para a cons-
trução de contêiner do C# segue esse princípio. Essa aba tem tanta importância para 
os desenvolvedores de software que estão aprendendo a desenvolver que muitos 
deles não se dão conta que se trata de um conjunto de códigos suportados por uma 
interface. Esse é o conceito principal de abstração, vivenciado na fase de aprendizado 
(Boratti, 2007).
Existem regras para a construção de componentes para os dispositivos móveis. 
Pesquise sobre as premissas para publicar componentes e aplicativos para os 
principais fabricantes de dispositivos móveis.
Portanto, a construção de componentes necessita de organização, conceito e que os 
softwares construídos sejam adequados ao contexto que devem atender. O desenvol-
vimento dos softwares deve ser realizado com coerência e seguir passos organizados.
 
65
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
CONCLUSÃO 
Os componentes precisam ser planejados e documentados de maneira adequada, 
para que consigam atuar de forma apropriada, em conjunto com outros recursos 
informatizados. O planejamento de atividades, controle de especificidades, recursos 
e compatibilidades formam o sucesso de um componente. Esse planejamento é ne-
cessário para que a empresa, os desenvolvedores e os clientes não se sintam frustra-
dos com o desenvolvimento de um recurso informatizado. Os clientes desejam com-
ponentes que atendam às suas necessidades e que tenham uma interface amigável, 
coesa, coerente e próxima da realidade. A abstração deve estar presente em compo-
nentes para ser aceita pelo mercado que será atendido. Um projeto de componente 
bem elaborado evita a insatisfação por parte dos desenvolvedores em ter que refazer 
trabalhos de desenvolvimento. Para que isso não aconteça, os gestores devem pensar 
no escopo do projeto, definir etapas, conceitos, diagramas e documentações perti-
nentes, para evitar a produção de um componente não coerente com as expectativas 
dos clientes e dos usuários. Quando um componente possui os recursos necessários 
para funcionar, um controle gerencial do seu escopo, níveis de abstração e aceitação 
elevados, terá como consequência um nível elevado de sucesso.
66
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
OBJETIVO 
Ao final desta 
unidade, 
esperamos 
que você:
> Definir as principais formas 
de divisão adequada de 
componentes.
> Avaliar as principais formas 
de comunicação de 
componentes que estão 
conectados através de 
meio físico.
> Recordar as formas de 
comunicação entre 
dispositivos que estão em 
locais distintos.
> Identificar os principais 
serviços de componentes 
informatizados.
UNIDADE 4
67
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
4 GRANULARIDADE, 
LOCALIZAÇÃO E SERVIÇO DE 
COMPONENTES
Na construção de sistemas informatizados, principalmente aqueles orientados a ob-
jetos, os desenvolvedores devem “dividir para conquistar”*, porém eles devem saber 
como dividir e até como separá-los dentro do contexto. Nesse tipo de produção, a 
divisão de softwares é fundamental para atender a diversos requisitos de outros sis-
temas e das necessidades de seus usuários. Aqui, entra o conceito de serviços, que 
também auxilia na divisão da construção de softwares. 
O desenvolvedor deve saber dividir os sistemas para que um software possua re-
presentatividade e serviços sólidos para o contexto que deseja atender. Elementos 
e aspectos de comunicação entre componentes que estão separados por grandes 
distâncias ou estruturas físicas também devem ter atenção total por parte do desen-
volvedor de componentes. A forma de localização de serviços de software mudou 
diversos contextos dentro da informática, como, por exemplo, a ideia de lojas com di-
versos serviços de aplicativos, como o que acontece em dispositivos móveis. Portanto, 
os três principais conceitos apresentados nesta unidade auxiliarão a definir melhor 
as suas formas de trabalho e como os seus dispositivos informatizados atenderão às 
necessidades dos clientes ou de outros softwares.
* Jargão da área de computação, utilizado no mesmo sentido das guerras.
4.1 4 GRANULARIDADE, LOCALIZAÇÃO E SERVIÇOS 
DE COMPONENTES
4.1.1 GRANULARIDADE DE COMPONENTES 
A divisão das etapas dentro de um desenvolvimento de software envolve projetos, 
determinações de diagramas e a divisão da construção de elementos informatiza-
dos. Dentro desta etapa, a construção de pedaços de software pode gerar dúvidas de 
quanto o desenvolvedor deve dividir um software. A granularidade tornou-se um novo 
68
Programação orientada a objetos ii 
FACULDADECAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
termo utilizado pelos programadores que usam componentes. Essa divisão granular 
permite uma avaliação mais coerente dentro da importância de um software para a 
rotina de um componente. A granularidade é a palavra que descreve a função forneci-
da por um componente (ou conjunto de componentes) que funcionam juntos. 
Dentro desse conceito, pode-se descrever que a granularidade pode representar um 
dispositivo de assinatura digital, ou seja, um grânulo do sistema. Para um exemplo 
simplificado, um componente de granularidade baixa poderia oferecer a funcionali-
dade de soma de dois números para compor um sistema de nota fiscal. Da mesma 
forma, seria a representação de um grânulo maior, se ele fosse o responsável pela 
transmissão da nota fiscal para outro sistema informatizado que recebe as transmis-
sões de valores para o governo. Essa pequena porção do sistema também pode ser 
vista como um dispositivo compacto que pode gerar o desenvolvimento de softwa-
re com custo baixo e, muito provavelmente, pouco personalizável (BARNERS, 2009). 
A figura a seguir apresenta características da granularidade de software.
FIGURA 20 - DIVISÃO DE SERVIÇOS DE SOFTWARE
FONTE: SHUTTERSTOCK, 2018.
Sua funcionalidade é muito discreta, mas extremamente relevante para o contexto. 
Portanto, a criação de componentes deve ser orquestrada para que, independen-
temente do tamanho, siga preceitos de serviços necessários para um software. Um 
componente com a granularidade alta é capaz de gerar uma parcela maior de fun-
cionalidades, gerar processos mais demorados, mas também fornecer sistemas mais 
complexos, e que podem demorar mais tempo. Em geral, a granularidade de softwa-
res pode permitir que um repositório com vários elementos úteis para os softwares 
utilize vários recursos. 
69
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
A figura seguir exemplifica essa divisão de tarefas baseadas na arquitetura dos sis-
temas.
FIGURA 21 - SERVIÇOS DE SOFTWARE
FONTE: SHUTTERSTOCK, 2018.
A granularidade permite que se crie um conjunto de bibliotecas de softwares me-
nores que podem ser solicitados à medida que o software principal necessite. Esse 
tipo de serviço pode ser visto como uma biblioteca de acesso a arquivos e compo-
nentes, um conjunto de banco de dados, ou um sistema quase completo baseado 
em estruturas ou serviços, como um sistema CRM, ERP, comércio eletrônico ou outro 
(BORATTI, 2007). 
Nesse contexto, sistemas mais encorpados podem ser vistos como um arcabouço de 
aplicativos. Sistemas administrativos em grandes empresas são vistos como partições 
de pequenos sistemas que se unem para um propósito geral. A figura a seguir exem-
plifica a importância de sistemas como o CRM (Customer Relationship Management) 
e o ERP (Enterprise Resourcing Planning) para a gestão na empresa, e como suas 
partes são importantes para o software.
70
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
FIGURA 22 - SISTEMAS ERP E SUA RELEVÂNCIA PARA A EMPRESA
FONTE: SHUTTERSTOCK, 2018.
Veja que na figura são apresentados os fatores de comunicação e utilização dos vá-
rios módulos. Assim, espera-se que cada um dos módulos tenha um funcionamento 
individualizado, porém, conectado com os demais recursos presentes. Cada um dos 
ícones representa um módulo do sistema (RH, Compras, Financeiro) e as ações indi-
viduais de cada um impactam nos demais elementos presentes no sistema. Se faltar 
dinheiro, não haverá compras. Se o setor de faturamento registrar o envio de valores 
em espécie para a conta bancária, os demais módulos poderão realizar as atividades 
que geram impactos financeiros. Veja que o gestor, como é demonstrado na figura, 
tem acesso a todos os módulos de forma interligada, permitindo assim, acompanhar 
de forma real e instantânea o esboço dos impactos de uma tomada de decisões em 
um módulo nos demais elementos. Isso favorece a evolução dos tempos, nos quais 
as informações são fornecidas de fontes distintas e as decisões precisam ser tomadas 
em tempo hábil, para que a empresa não perca representatividade dentro do mer-
cado de sua atuação. Os sistemas ERP facilitam essa tomada de decisões estratégicas 
por atuarem com dados relevantes para o contexto, que são agrupados de forma 
conectada e a análise pode ser mais completa.
71
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
Um sistema do tipo Enterprise Resourcing Planning (ERP) possui partes que 
podem funcionar de forma independente. Como exemplo, pode-se destacar 
o módulo de recursos humanos, o módulo contábil ou o modo de paga-
mento. Para as pessoas que atuam no setor contábil, esse módulo possui 
diversas funcionalidades que também podem ser vistas como um sistema. 
Empresas que vendem essa solução podem ativar somente os módulos ne-
cessários para o sistema funcionar. Pense que cada módulo ou caso de uso 
tem a independência de ações dentro do sistema, e podem ser requisitados 
à medida que a empresa necessita.
Muitas empresas de software trabalham na produção de unidades menores e re-
presentativas para um contexto, pois, dependendo do tamanho da empresa ou 
de suas condições financeiras, a contratante não precisará de todos os módulos. 
Nesse caso, o desenvolvimento orientado a objetos deve permitir que as funcionalida-
des tenham independência quando precisarem e, ao mesmo tempo, sejam capazes 
de se adaptarem a outros contextos, com softwares maiores. Desse modo, esse tipo 
de abordagem movimenta milhões na indústria de software, pois permite que as 
soluções sejam feitas de forma específica para um cliente em potencial. Imagine que 
um sistema complexo, por não trabalhar em partes, deixe de lado muitas empresas 
que não podem pagar, ou não precisem de todas as funcionalidades disponibilizadas 
por um sistema mais robusto.
Com a evolução das técnicas ágeis de desenvolvimento de software, a programação 
orientada por granularidade tomou grande espaço, inclusive permitindo que a mo-
delagem, organização e projetização de desenvolvimento de componentes fossem 
mais centradas nas partes menores do sistema. A evolução de interfaces, meios de 
disponibilização de serviços e a evolução das linguagens de programação permitiram 
que a utilização de sistemas informatizados seguisse critérios “de dividir um proble-
ma para conquistar uma solução, abrangendo maior número de clientes. Os soft-
wares mobile também seguem essa linha de granularidade, tanto que o seu celular 
72
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
possui aplicativos que seguem as suas necessidades, e os de parentes e amigos têm 
outra dinâmica de funcionamento. As relações pessoais também passaram a inter-
ferir na rotina de produção de softwares. A evolução da orientação a objetos permite 
que classes, interfaces e conceitos de abstração, reuso e divisão dos problemas pas-
sem a incorporar componentes mais sólidos para serem utilizados. Em alguns casos, 
projetos que eram para ser menores unidades de um sistema ganharam indepen-
dência e destaque devido à sua atuação no mercado.
Por exemplo, um componente de compras na internet pode ter o maior percentual 
da funcionalidade de um sistema de comércio eletrônico completo, incluindo regis-
tro e login, carrinho de compras, serviços de catálogo, faturamento, correspondência, 
entre outras ações. 
A figura a seguir exemplifica a solução de compras on-line.
FIGURA 23 - EXEMPLO DESOLUÇÕES COMPLETAS PARA COMPRAS ON-LINE
Fonte: SHUTTERSTOCK, 2018.
A Netflix também segue essa mesma linha, pois é um serviço que propicia o cadastro, 
catálogo de vídeos e também pode se conectar a dispositivos como celulares, com-
putadores e TVs. Ele pode ser acessado como um componente individual, mas, na 
realidade, é uma estrutura de componentes integrados para fornecer uma solução 
de granularidade alta.
73
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
Portanto, o desenvolvedor de softwares, em conjunto com a equipe de projetos, deve 
definir o tamanho da divisão das funcionalidades. Nesse momento, é possível anali-
sar as formas de atuação, dispositivos que são fundamentais para o funcionamento 
correto de outro elemento informatizado. Um projeto dividido deve respeitar as indi-
vidualidades das soluções, mas deve pensar de forma coordenada sobre como elas 
atuarão na resolução de problemas. Ambas têm seus pontos positivos e negativos. 
A personalização dos componentes, a forma de distribuição e o público-alvo deter-
minam o tamanho da granularidade de seu software. Imagine que você irá desenvol-
ver um sistema de compra e venda para o maior hipermercado do Brasil e também 
irá atender um supermercado de bairro. O desenvolvedor precisa entender que um 
software com alta granularidade pode ser mais adequado à empresa de maior porte, 
que pode escolher quais módulos, serviços ou interações que o cliente deseja. Inclu-
sive, deve ser avaliada a integração do software com outros elementos presentes na 
empresa. Já para o supermercado de menor porte, o menor grânulo permite que as 
funcionalidades presentes no software atendam à maioria dos serviços necessários 
para o seu funcionamento. Nesse contexto, é mais fácil a empresa se adequar às fun-
cionalidades e rotinas do componente do que o contrário. Normalmente, esse fator 
acontece porque os componentes de granularidade baixa são discretos, e você acaba 
escrevendo mais códigos (maior fidelização a suas características centrais) de ligação, 
que fazem esses componentes funcionarem juntos, da maneira como o cliente deseja. 
Esse tipo de componente com granularidade baixa acaba se tornando bem a “cara” 
do requisitante, com códigos, telas, cores e fontes mais a cargo do cliente que está 
solicitando. Situação inversa acontece com grandes empresas, pois quando se tra-
balha em duas empresas que utilizam o mesmo sistema de gestão, por exemplo, as 
telas, a aparência e, muitas vezes as funcionalidades são as mesmas. Nesse contexto, 
o desenvolvedor deve escrever um código mais genérico para atender a pormenores 
requisitados pelos clientes contratantes. Essas adequações são simples, pois em pro-
jetos com grandes granularidades, as funcionalidades são pensadas de forma dinâ-
mica, para funcionarem em conjunto e atenderem, de forma genérica, às principais 
necessidades de um grupo-alvo de clientes. 
Em um componente de granularidade alta, o código de ligação é escrito no interior 
do componente; portanto, na maioria das vezes, a padronização ou a adequação a 
situações específicas são definidas por parâmetros (inclusive com um caso de uso 
específico para a gestão de parâmetros no sistema). Os parâmetros definem termos e 
formas de prestação de serviços entre os componentes informatizados para atender 
as vontades do cliente.
74
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
4.1.2 LOCALIZAÇÃO DE COMPONENTES
Após a construção de elementos informatizados, eles precisam ser armazenados em 
locais onde outros dispositivos podem requisitar seus serviços. Esses locais fornecem 
repositórios de serviços importantes para armazenar componentes e softwares com-
pletos. Esses tipos de repositórios facilitam a organização e o fornecimento de técni-
cas e serviços importantes para softwares relevantes.
Os componentes podem estar localizados em diversos locais lógicos, como um mes-
mo servidor de interação local ou servidores diferentes como, por exemplo, o de co-
municação remota. O ideal é que o desenvolvedor abstraia e defina a localização 
dos componentes, facilitando sua consulta e publicando os meios de comunicação 
com outros aplicativos, podendo agir da mesma forma, independentemente de os 
componentes estarem na mesma máquina ou em máquinas diferentes. Esse tipo 
de localização define a forma como os softwares irão fazer as devidas requisições ao 
sistema de armazenamento de componentes. Também definem a velocidade das 
requisições e, dependendo do local onde estão instalados, podem ter referências de 
segurança para as requisições. A figura a seguir explicita um exemplo de serviços 
que compartilham o mesmo repositório de componentes em locais distintos. Isso 
acontece, por exemplo, quando em um mesmo servidor de uma loja de compras 
online estão armazenados os dados de todas as peças do estoque de uma empresa. 
A solicitação para a compra de um item desse estoque pode partir de computadores 
que estão totalmente distantes e sem comunicação entre si. Esse recurso de reposi-
tório precisa receber as requisições e realizar as demandas de atualização no saldo 
dos produtos restantes para que não sejam vendidos elementos de forma repetitiva. 
Outro exemplo bem prático que pode fazer alusão ao que é expresso na figura é que 
esse repositório explanado pode representar o repositório de arquivos de uma loja 
virtual de celular. Todos os celulares de uma marca ou um grupo podem ter acesso a 
esses recursos de lojas virtuais, podendo fazer os downloads dos elementos que se-
jam mais interessantes a suas necessidades. Esse repositório controla os downloads 
efetuados e, ao mesmo tempo, também gere os novos recursos, que são disponibi-
lizados para todos os participantes desse repositório. Essa ideia de agrupamento e 
organização de pequenos elementos pode ser visualizada quando você acessa seu 
celular e vê vários recursos que podem ser baixados de sua loja virtual.
75
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
FIGURA 24 - REPOSITÓRIO DE COMPONENTES COMPARTILHANDO 
SERVIÇOS DE SOFTWARE
Fonte: SHUTTERSTOCK, 2018.
A localização de um componente pode definir regras de requisições de di-
versos elementos para a solicitação de serviços de componentes. Redes lo-
cais são responsáveis por transmissões mais rápidas. Outros servidores mais 
distantes podem gerar tráfego de requisições, portanto, o desenvolvedor 
deve promover recursos com o código para que existam meios de manter 
as requisições de componentes, mesmo que exista tráfego de requisições 
demorado ou instável.
Para abstrair a localização de componentes, o ideal é que os mecanismos usados 
para interação dos dispositivos responsáveis pelas requisições sejam usados tam-
bém para comunicação remota, isto é, permitam a requisição de elementos local-
mente distantes.
76
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
Já os mecanismos de interação local permitem que elementos localizados dentro da 
mesma rede ou do mesmo local lógico possam se comunicar. Isso funciona como, 
por exemplo, a requisição de serviços instalados na mesma rede ou no mesmo com-
putador (DEITEL, 2007).
BARNERS (2009) afirma que outros exemplos de localização de componentes po-
dem permitir a comunicação por meio de:
• chamada de procedimento/método,
• notificação de eventos/mensagens,
• mecanismos de comunicação remota, 
• chamada remota de proced./método (RPC),
• notificação de eventos/mensagens remotos.
A figura a seguir representa um exemplo de formas distintasde comunicação de ser-
viços na nuvem. As tecnologias cloud e iot (internet das coisas) funcionam por meio 
da comunicação de dispositivos informatizados conectados na internet. Eles são co-
nectados para realizar solicitações de tarefas mediante comandos de ferramentas 
existentes para serviços que conectam hardware e software. Os dispositivos estão fisi-
camente distantes, se comunicam na internet para abrir portas, acender luzes, dentre 
outros serviços. 
FIGURA 25 - COMUNICAÇÃO DE DISPOSITIVOS LOCALMENTE SEPARADOS POR MEIO DE 
REQUISIÇÕES E MENSAGENS
Fonte: SHUTTERSTOCK, 2018.
77
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
A chamada remota de procedimento/método é capaz de identificar uma 
chamada local por meio das requisições de um software a um repositório de 
componentes. Os dispositivos que se comunicam, em geral, estão em má-
quinas diferentes; portanto, a requisição precisa ser enviada como uma men-
sagem pela rede, na qual o suporte de execução se encarrega de enviá-la.
Outro fator importante é a localização de componentes prontos. Eles são responsá-
veis por buscar serviços fornecidos pelo componente, considerando a semelhança 
de seus conteúdos. Isso acontece, por exemplo, com as lojas de componentes para 
download no celular. Cada loja tem os tipos de componentes adequados para os dis-
positivos esperados para cada tipo de aparelho.
Cada loja virtual possui suas características, suas linguagens de programação 
e suas premissas, para que os desenvolvedores publiquem seus componen-
tes ou aplicativos. O motivo é que cada linguagem precisa de uma comuni-
cação esperada para que os dispositivos sejam compatíveis com o tipo de 
celular que deseja obter os componentes. Isso também pode acontecer com 
softwares específicos para tipos distintos de computadores ou notebooks. O 
que muitas vezes facilita essa comunicação é o sistema operacional, que é 
outro tipo de componente capaz de gerenciar interfaces (GRENNE, 2008).
78
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
4.1.3 SERVIÇOS DE COMPONENTES
Os componentes, assim como os softwares, têm por essência fornecer facilidades 
àqueles que o utilizam. Dentro da principal referência dos componentes está a pres-
tação de serviços de software em escalas menores. O componente deve fornecer ser-
viços a outros componentes ou softwares, que os utilizarão por meio das interfaces 
que devem ser desenvolvidas para facilitar a comunicação e a troca de mensagens, 
que é a principal essência da orientação a objetos. Os serviços de um software são a 
essência de sua existência, permitindo, assim, delimitar suas ações, formas de comu-
nicação e interfaces, para desempenhar suas funções.
As principais funções de um componente envolvem troca de requisições para aten-
der demandas. Geralmente, o elemento que faz a requisição espera um serviço ou 
uma mensagem de execução de atividades. Esses elementos funcionam de forma 
complementar uns aos outros. Espera-se que cada serviço seja representativo e liga-
do às principais características dos componentes (SHARP, 2008). 
Deve ser possível ajustar a forma como os serviços são executados, por meio de mu-
danças de parâmetros ou com requisições adequadas, que podem ser facilitadas 
por interfaces de software. O componente deve se sujeitar à composição de outros 
componentes para que possam fornecer adequadamente os recursos necessários. 
Ele deve procurar ser independente de outros componentes, para que possa atuar 
como serviço (recurso computacional necessário para a execução de uma atividade) 
a um grande número de softwares. Quando um componente chega nessa situação, 
significa que o desenvolvedor chegou ao desenvolvimento pleno da orientação a ob-
jetos. A figura a seguir exemplifica os diversos serviços que soluções informatizadas 
podem propiciar.
79
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
FIGURA 26 - SERVIÇOS DE SOFTWARE
Fonte: SHUTTERSTOCK, 2018.
Os componentes de software, quando utilizam corretamente os conceitos 
de abstração, possuem características que deixam bem claro quais servi-
ços são capazes de fornecer. Um componente de impressão de boletos, por 
exemplo, deve ser significativo para o sistema para o qual fornece serviços, 
em que a impressão, a comunicação e o registro de boletos devem ser efe-
tuados de maneira síncrona e atômica, realizando a transmissão de boletos 
de um sistema comercial. Cada um tem sua funcionalidade e seu serviço 
para um usuário ou outro sistema. 
Os componentes devem ser utilizados de maneira consciente dentro do contexto 
dos sistemas informatizados. Sua forma, divisão e serviços só devem ser utilizados se 
forem necessários a execuções de tarefas do fluxo principal dos sistemas.
80
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
CONCLUSÃO 
Nesta unidade, foram apresentadas formas de organizar, guardar e permitir a co-
municação de serviços importantes de componentes de software. A forma como os 
serviços são apresentados para os componentes deve dizer muito sobre como eles 
são produzidos. Os elementos de software devem se comunicar por meio de requi-
sições a repositórios de componentes, permitindo que sejam realizadas as principais 
chamadas aos serviços providos pelos softwares. A quantidade de serviços que será 
providenciada pelos componentes depende da granularização com que o compo-
nente foi desenvolvido. 
As partes de um componente devem ser independentes, eficientes e prover serviços 
completos a outros grupos de softwares. Quanto mais complexo for um componente, 
deve-se pensar na forma como ele deve ser produzido. Serviços mais simples podem 
ser feitos por grânulos menores, nos quais cada um deles tenha um serviço represen-
tativo e, de preferência, uma localização próxima de seu principal requisitor. 
A forma como os grânulos são guardados facilita a comunicação entre dispositivos 
dependentes. Quanto mais próximos os dispositivos estiverem, mais fácil fica sua co-
municação. Muitas vezes, é necessário um espaço maior para seu armazenamento. 
Os componentes podem estar salvos em elementos locais, como um computador 
ou um serviço local. Da mesma forma, existem componentes salvos em dispositivos 
remotos distantes, permitindo que as requisições de serviços concorram com várias 
requisições de outros dispositivos requisitados ao mesmo tempo. O desenvolvedor 
deve prever tais situações para que a troca de mensagens entre os componentes não 
seja prejudicada.
81
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
OBJETIVO 
Ao final desta 
unidade, 
esperamos 
que possa:
> Apresentar os conceitos de 
reúso de software.
> Avaliar as principais 
técnicas de refatoração de 
códigos de componentes.
> Apresentar as principais 
técnicas de reúso.
> Apresentar conceitos 
relevantes sobre a 
refatoração de software.
UNIDADE 5
82
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
5 REÚSO E REFATORAÇÃO 
DE COMPONENTES DE 
SOFTWARE
Nesta unidade, serão tratados os principais conceitos de qualidade de componentes 
que já estão construídos e, por algum motivo, apresentam características inconsisten-
tes que podem prejudicar o desempenho do componente na execução de suas ati-
vidades. Isso pode acontecer por problemas de heranças de classe, atributos ou mé-
todos obsoletosque geram tarefas desnecessárias para os componentes. Portanto, 
as técnicas capazes de organizar e melhorar a qualidade dos componentes são defi-
nidas pelas técnicas de refatoração e serão apresentadas de forma teórica e prática.
Outros elementos sobre a qualidade de software é a capacidade de permitir que 
componentes organizados conversem ou interajam com outros softwares. O reú-
so permite que outros softwares sejam utilizados pelos componentes e vice-versa, 
através de adaptações na organização de códigos e melhorias necessárias para que 
os componentes possam conversar. Nessa seção, esses conceitos serão praticados e 
exemplificados. Vamos lá? 
83
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
5.1 REÚSO E REFATORAÇÃO NOS COMPONENTES 
DE SOFTWARE
5.1.1 REÚSO DE COMPONENTES DE SOFTWARE
O desenvolvimento de software passou por diversas inovações nos últimos tempos 
devido à necessidade de atender cada vez mais os clientes e que possuíam nível de 
exigência elevado. Essa mudança gerou diversas ferramentas para facilitar a produti-
vidade, a eficiência e as boas práticas nos programas a serem produzidos. Alguns des-
ses algoritmos e métodos têm efeitos tão positivos nas aplicações que outros projetos 
também podem se beneficiar de suas funcionalidades. A esse processo chamamos 
de reúso de software, que se trata da utilização de programas e métodos consoli-
dados em diversas aplicações, às quais inicialmente ela não foi planejada para sua 
utilização. De uma forma mais simples de ser compreendido, o reúso de software 
consiste em aplicar um componente a outras funcionalidades que ele não atuava. 
Imagine que um componente de assinatura digital era utilizado para assinar os do-
cumentos que tramitavam em um sistema. Agora, com o reúso de componentes, ele 
pode atuar em um sistema de registro de pedidos on-line, onde a confirmação de 
uma compra também pode ser feita por assinatura digital. Esse processo acontece 
constantemente em fábricas de software, quando em um sistema, são elaborados 
métodos que resolvem os problemas de todos os sistemas que a empresa desenvolve 
(métodos de máscara de campos, métodos de validação, envio de e-mail, geração e 
controle de pagamentos de GRU, DAE ou DARF, entre outros).
De acordo com Barners (2009), o reúso de software pode atuar em diversas maneiras 
para permitir o compartilhamento de métodos e programas:
• reúso de métodos e objetos: o tipo de reúso mais utilizado nos dias atuais. 
Ele permite que objetos, métodos ou funcionalidades de outros sistemas pos-
sam atuar de maneira eficiente em um novo software.
• reúso de sistemas: consiste na utilização de um sistema dentro de outro sis-
tema. Alguns softwares governamentais necessitam de funções dos sistemas 
de pagamento, orçamento e de patrimônio para que os sistemas adminis-
trativos funcionem de forma correta. Quando um sistema faz parte de outro, 
nesses moldes, é uma definição desse tipo de reúso.
84
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
• reúso de componentes: um tipo de reúso menos usual, mas também impor-
tante para utilização de estruturas e sistemas complexos. Estão ligados dire-
tamente à utilização de componentes da arquitetura de software, onde cada 
componente é responsável por uma funcionalidade atômica do sistema.
A escolha da técnica de reúso deve seguir as necessidades do cliente e do 
sistema que os componentes reutilizados vão atender. Uma escolha inade-
quada pode gerar muito retrabalho e também inviabilizar o novo software, 
transformando-o em um dispositivo lento e ineficiente.
Segundo Sharp (2008), as vantagens da utilização do reúso estão ligadas a aspectos 
diversos como:
1. Diminuição no tempo de desenvolvimento, evitando construir um elemento 
que já funciona corretamente e foi devidamente testado. 
2. Diminuição dos custos de produção do software, pois um número menor de ho-
ras será utilizado para a adaptação das novas funcionalidades, em comparação 
com a necessidade de produzi-las. 
Esses aspectos também estão acompanhados de uma maior produtividade da equi-
pe de desenvolvimento, pois os esforços para a produção, pesquisa e desenvolvimen-
to de novos componentes serão otimizados. Aliados a isso, a economia dos custos 
envolvidos na produção de software também diminuirão vertiginosamente.
Já as desvantagens do reúso estão ligadas ao controle de versões e compatibilidades 
entre os softwares envolvidos, prejudicando futuras evoluções do programa e uma 
maior atenção, por parte dos gestores de projetos. Além disso, a orientação a objetos 
deve estar presente de forma adequada, senão a utilização do reúso pode trazer mais 
85
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
transtornos do que propriamente benefícios, exigindo diversas adaptações e corre-
ções no código. Os maiores problemas de insucesso de reúso de um software estão 
ligados à falta de conhecimento da equipe de desenvolvedores na maneira com que 
o software está organizado (arquitetura) ou desenvolvido (componentes, camadas, 
entre outros).
A FIG. 27 representa de forma sintética as vantagens e desvantagens do reúso e seus 
possíveis impactos.
FIGURA 27 - MATRIZ DE AVALIAÇÃO ENTRE REÚSO E PRODUTIVIDADE
+ reuso
- produtividade
=
- clientes prospectados
- contratos fechados
+ reuso
+ produtividade
=
+ eficiência
+ valor agregado
+ fortalecimento portfólio
- reuso
- produtividade
=
+ manutenção corretiva
- eficiência
- valor agregado
- enfraquecimento do portfólio
- reuso
+ produtividade
=
+ produtos
+ domínios do conhecimento
+ colaboradores
Fonte: https://engenhariasoftware.wordpress.com/category/gestao-de-projetos/page/4/
Planejar o reúso é fundamental para ele aconteça de forma adequada. A seguir, 
Boratti (2007) apresenta alguns passos e ações importantes a serem tomadas:
• Envolvimento dos gerentes de projetos, gestores e stakeholders.
• Foco em um domínio ou atividade a ser reutilizada.
86
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
• Ciclo de vida do software.
• Conhecimento e experiência da equipe no software ou solução.
• Prazos para o desenvolvimento.
As principais técnicas de reúso estão listadas a seguir, de acordo com Sommerville 
(2011):
Utilização de bibliotecas e de aPi: classes implementam métodos que podem ser 
utilizados por diversos sistemas. São as principais técnicas que representam os com-
ponentes.
Framework de aplicação: implementam camadas, métodos e padrões de desenvol-
vimento que facilitam a vida do desenvolvedor. Atuam como um conjunto de ferra-
mentas com um único propósito.
Padrões de design e arquitetura: padronizam as aplicações através de metodologias 
comumente utilizadas pela comunidade de desenvolvedores. Já tem um arcabouço 
de utilização para atacar e resolver os principais problemas existentes em softwares. 
Existem formas comumente utilizadas na comunidade de software como os padrões 
SOLID e GRASP.
Componentes: integração de funcionalidades oriundas de subsistemas (um exem-
plo típico é um componente que permite que documentos sejam assinados digi-
talmente).
encapsulamento de sistemas legados: quando o que já foi desenvolvido não pode 
ser descartado, eles podem fazer parte em sua totalidade de outro sistema.
arquitetura orientada a serviços: desenvolvimento de sistemas compartilhando ser-
viços de negócio para serem reutilizados, através da composição de novas soluções.
desenvolvimento orientado a aspectos: separação de prioridades (modularização).
Para o desenvolvimento orientado a objetos,o reúso de aplicações, métodos e fun-
ções são importantes para a melhoria da produtividade da equipe de software. Se-
guir os padrões adequados e criar classes e objetos, de acordo com as especificações, 
87
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
auxilia de forma bem prática a utilização do reúso aplicando a orientação a objetos. 
Nesse caso, para ilustrar o contexto de utilização de reúso, você pode utilizar uma 
classe que contém atributos que podem se enquadrar dentro de diversos contextos. 
Para demonstrar a utilização da OO no contexto de reúso, vamos utilizar uma classe 
chamada Usuario, que possui atributos específicos desse contexto, como id, login, 
senha, nome, e a sua data de cadastro. A FIG. 28, a seguir, apresenta o diagrama de 
classes da UML que permite sua modelagem.
FIGURA 28 - CLASSE USUARIO
Fonte: Elaborado pelo autor, 2019.
A classe Usuario poderá atuar em sistemas de diversos contextos para representar 
um ator que interaja com o sistema. Quando a classe é desenvolvida em OO, ela con-
segue ser facilmente adaptada e alterada; caso necessário, para atender a demandas 
bem específicas do novo software.
Essa classe pode trabalhar em diversos contextos, como um software para um super-
mercado, para uma locadora de veículos, pois esses sistemas necessitam de usuários 
para acessarem o sistema. O reúso consiste em utilizar essa classe em vários contex-
tos existentes e que eles sejam adequados.
5.1.1.1 PROJETOS DE COMPONENTES COM REÚSO
Para conquistar cada vez mais espaço junto ao mercado, empresas de desenvolvi-
mento de software buscam melhorar as soluções já desenvolvidas, permitindo que 
elas atendam a um público maior, através de maior número de funcionalidades e 
88
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
casos de uso. Esses tipos de projetos tendem a evoluir à medida que as necessidades 
dos usuários estão sendo sanadas. Empresas públicas tendem a ampliar os serviços 
disponibilizados devido a opiniões do público em geral. Essas evoluções devem ser 
feitas permitindo que os softwares mantenham seu padrão de utilização e estejam 
adaptadas às novas demandas. A utilização do reúso deforma consciente, adequada 
e previne diversos problemas que podem ocorrer. Para que projetos possam ser evo-
luídos de forma coesa e sem maiores problemas, alguns fatores devem ser seguidos, 
conforme Greene (2008):
• Atualizar a documentação incluindo as novas funcionalidades.
• Definir corretamente as ampliações de funcionalidades da solução.
• Verificar os impactos da inclusão de novas funcionalidades nas que já funcio-
navam.
• Utilizar o reúso nos contextos que sejam permitidos.
• Realizar testes de regressão nas atividades que já existiam e avaliar os impactos.
Os softwares também necessitam acompanhar as novas tendências para que o usuá-
rio final não fique desmotivado a usá-lo. O desenvolvedor deve acompanhar as evo-
luções tecnológicas, de versões de API ou bibliotecas utilizadas, buscando manter 
seu software dentro dos padrões de uso e aceitação do público em geral. A FIG. 29 
apresenta a importância das etapas de um projeto de reúso de componentes.
FIGURA 29 - PRINCIPAIS ETAPAS QUE DEVEM EXISTIR EM REÚSO DE COMPONENTES
Fonte: SHUTTERSTOCK, 2019.
89
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
5.2 REFATORAÇÃO DE COMPONENTES DE 
SOFTWARE
A refatoração é uma técnica empregada na qualidade de desenvolvimento de soft-
ware que facilita a manutenção e organização das linhas de código, de modo que 
esse código seja reutilizado em outras soluções, além de preconizar a organização de 
contextos dentro das classes, agrupando termos que podem ser organizados dentro 
de uma classe ou método.
Refatoração é uma técnica disciplinada para reestruturar um trecho de códi-
go existentes, alterando sua estrutura interna sem alterar seu comportamen-
to observável.
A seguir, são apresentadas formas de refatoração para auxiliar na qualidade do soft-
ware, de acordo com Boratti (2007):
extrair método: transforme o fragmento em um código cujo seu nome explique o 
propósito do método. Essa metodologia funciona quando um método torna-se ex-
tremamente complexo, e partes iguais podem virar um novo método.
Código Original.
void imprimeHistoricoAluno (Aluno aluno) {
Double nota=0;
// imprime dados aluno
Console.writeln (“***************************”);
Console.writeln (“*** Dados do Aluno ****”);
Console.writeln (“***************************”);
90
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
// calcula dados dos alunos 
while (aluno.temMaisNotas ()){
Aluno listaAluno = (Aluno) aluno.proximoAluno ();
nota += listaAluno.getNota ();
}
// imprime detalhes
Console.writeln (“nome: ” + aluno.getNome());
Console.writeln (“nota total: ” + nota);
}
Como fica após a refatoração
void imprimeDadosHistoricoAluno (Aluno aluno) {
Double nota=0;
imprimeCabecalhoAluno(aluno);
calculaNotasAluno(aluno, notas);
imprimeDadosAluno(aluno, notas);
}
Cada bloco virará uma função interna, facilitando a organização do código. 
mover método: esta técnica se fundamenta na criação de um novo método com 
corpo similar na classe que ele mais usa. Transforme o método original em uma de-
legação ou, se for o caso, remova-o. Veja a curiosidade a seguir. Ela apresenta mais 
exemplos dessa técnica.
Veja esse exemplo. Se um método faz mais sentido em outra classe, ele deve 
ser removido para ela. Essa experiência você adquirirá através do funciona-
mento do sistema.
Link para acesso: http://ramonsilva.net/desenvolvimento/tecnicas-comuns-
-de-refatoracao/
http://ramonsilva.net/desenvolvimento/tecnicas-comuns-de-refatoracao/
http://ramonsilva.net/desenvolvimento/tecnicas-comuns-de-refatoracao/
91
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
renomear método: esta refatoração é utilizada para adequar métodos que não re-
presentam àquilo que elas realmente fazem. Isso acontece depois que várias fun-
cionalidades são adicionadas a um método, e ele muda sua natureza, podendo ser 
incrementado ou modificado para que a leitura do método fique mais simples. Outro 
exemplo que é necessária a refatoração de um nome de método é quando a em-
presa muda os padrões de construção de softwares, dando a certos tipos de classes 
nomes específicos ligados às regras de negócio que eles visam atender.
//Código original
private String identificacaoRfid;
public String setIdentificacaoRfid(String identificacaoRfid){
this. identificacaoRfid = identificacaoRfid;
}
Public void getIdentificacaoRfid(){
return this. identificacaoRfid;
}
// Para ficar mais adequado a um contexto
private String rfid;
public String setRfid(String rfid){
this.rfid=rfid;
}
Public void getEtiquetaDeVerificacaoEstoque(){
return this.rfid;
}
Os nomes de alguns métodos ficaram mais curtos, e o de retornar a etiqueta ficou 
mais representativo ao contexto, permitindo que novos programadores consigam 
entender do que se trata esse tipo de abordagem em qualquer momento do código.
mover atributo: troque todas as referências da variável temporária pela expressão 
fixa dentro de um software. Isso auxilia a entender e agrupar argumentos em classes 
corretas. Ao mover os atributos, você poderá criar novas classes.
92
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
Atributos podemser removidos para melhorar o contexto. Isso pode partir 
através de um diagrama de classes ou de banco de dados. Analise o contexto 
para facilitar a mudança dos elementos. Veja o exemplo no link a seguir.
Link: http://ccsl.ime.usp.br/borboleta/bancodedadosevolutivos
Encapsular atributo: apesar de ser um requisito obrigatório da orientação a objetos, o 
encapsulamento das informações auxilia na organização e na proteção da qualidade 
do código. Avalie quais atributos podem e devem ser protegidos pelo encapsulamen-
to, utilizando novas classes para que outras classes ou métodos não a utilizem sem as 
devidas precauções.
//Classe Pessoa 
Public Class Pessoa {
private String nome;
private int idade;
private String cidadeNascimento;
private Date dataNascimento;
private String nomeMedico;
private String tipoSanguineo;
private String pais;
}
//Classe pessoa com o encapsulamento em endereço.
public Class Pessoa {
private String nome;
private int idade;
private Certidao certidao;
}
Link: http://ccsl.ime.usp.br/borboleta/bancodedadosevolutivos
93
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
Public Class Certidao{
private String cidadeNascimento;
private Date dataNascimento;
private String nomeMedico;
private String tipoSanguineo;
private String pais;
}
// A classe Certidao encapsulou todos os dados de nascimento da pessoa den-
tro de um único contexto.
Existem diversas técnicas de refatoração de código que podem ser aplicadas. Elas 
devem ser pensadas com os conceitos de orientação a objetos, sem perder a sua efi-
ciência no reúso.
Quer saber mais sobre a refatoração? Veja o link que tratam do tema em:
<https://www.slideshare.net/ivanricarte/introducao-a-refatoracao>.
Este livro apresenta boas técnicas de refatoração. Para ler, acesse:
https://goo.gl/iXnCYS. 
Formas de refatoração podem e devem ser aplicadas em todas as partes do softwa-
re. Na chamada camada de visão, onde estão localizadas as páginas html ou xhtml, 
técnicas de refatoração podem incluir ou atualizar componentes. A FIG. 30 apresenta 
elementos que podem ser utilizados na refatoração de códigos nas páginas web.
<https://www.slideshare.net/ivanricarte/introducao-a-refatoracao>
https://goo.gl/iXnCYS
94
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
FIGURA 30 - ELEMENTOS PRESENTES NAS INTERFACES WEB
Fonte: SHUTTERSTOCK, 2019.
CONCLUSÃO 
Uma excelente forma de disseminar cada vez mais os componentes de software é 
utilizar elementos de qualidade no projeto de linhas de código. Esses elementos per-
mitem que mais componentes sejam utilizados em diversos sistemas, diminuindo 
custos, tarefas e o desenvolvimento de soluções que já estão prontas, evitando assim 
a possibilidade de erros presentes em códigos para soluções que já estavam em ple-
no funcionamento. Aprendemos também que existem abordagens de qualidade 
em linhas de código que permitem que o código seja organizado, seguindo critérios 
mais lógicos, possibilitando que sua organização gere melhor rendimento, visibilida-
de e maturidade nos códigos desenvolvidos. As técnicas de refatoração podem ser 
excelentes para organizar sistemas que apresentam problemas diversos, como o de-
sempenho inadequado, registros de lixo digital em banco de dados, entre outros.
A união das técnicas de refatoração permite que o reúso seja aplicado de forma mais 
simples e intuitiva, de modo que os sistemas legados, componentes e softwares de-
senvolvidos tenham qualidade em toda a sua estrutura, desde o planejamento até a 
sua execução. Assim os custos de empresas e de microempresários do ramo de soft-
wares diminuem, e os recursos podem ser alocados em outras áreas. Para que elas 
sejam usadas com qualidade os conceitos de orientação a objetos devem ser sólidos 
e bem coerentes.
95
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
OBJETIVO 
Ao final desta 
unidade, 
esperamos 
que possa:
> Apresentar os 
principais elementos 
presentes nos padrões 
de projeto orientado a 
objetos.
> Apresentar as 
principais técnicas do 
padrão SOLID.
> Auxiliar a compreensão 
sobre os conceitos 
de qualidade do 
aluno por meio de 
técnicas e padrões de 
programação orientada 
a objetos.
UNIDADE 6
96
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
6 PADRÕES DE PROJETO 
PARA CONSTRUÇÃO DE 
COMPONENTES COM REÚSO
Para a determinação de classes e componentes com codificações corretas, foram fei-
tos durante a História diversos estudos que facilitaram a obtenção da qualidade nas 
linhas de código de sistemas informatizados. Dentre os estudos realizados, foi criado 
um conjunto de premissas que facilitaram a vida de desenvolvedores e projetistas de 
componentes. Estamos falando dos padrões de projetos que reúnem boas práticas e 
definições de grandes pesquisadores na área de computação, para definir elementos 
que são fundamentais para que os componentes construídos sejam reutilizados por 
outros softwares ou empresas. A práticas foram definidas como cinco etapas que de-
vem ser executadas para que classes, objetos e interfaces tenham seu papel estrutu-
rado dentro do conjunto dos softwares. Portanto, a orientação a objetos vai utilizar os 
critérios definidos por padrões de desenvolvimento de softwares para trazer eficiên-
cia e coerência aos elementos produzidos. Vamos juntos nos estudos?
97
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
6.1 PADRÕES DE PROJETO PARA A CONSTRUÇÃO 
DE COMPONENTES COM REUSO
Neste capítulo vamos abordar elementos fundamentais para padronizar os seus pro-
jetos de componentes.
6.1.1 INTRODUÇÃO AOS PADRÕES DE SOFTWARE
A engenharia de software e a construção de sistemas são áreas da informática que 
trabalham na construção de sistemas com qualidade, possibilitando aos desenvol-
vedores elaborarem seus softwares utilizando técnicas mais apuradas e eficientes. 
Dessa forma, evita-se que aspectos de má qualidade de softwares sejam utilizados na 
produção de sistemas importantes para as empresas, elevando, assim, os custos de 
produção e a insatisfação de clientes. Após vários estudos e avaliações da qualidade 
dos códigos entregues, constatou-se que alguns elementos não deveriam ficar de 
fora do desenvolvimento de software, principalmente aqueles ligados à construção 
de códigos por parte dos desenvolvedores, porque estavam gerando cada vez mais 
atrasos nos cronogramas e insatisfação nos clientes.
O livro Agile, principles, patterns, and practices (MARTIN, 2006), produzido pelo fa-
moso Tio Bob, traz características relevantes sobre a qualidade no código de desen-
volvedores. Além de informar sobre aspectos de desenvolvimento ágil e de técnicas 
para melhorar o reúso do código, ele apresenta cinco boas práticas de organização 
e construção de código que foram comumente conhecidas pelo padrão SOLID, que 
representa as cinco primeiras siglas de cada uma dessas características importantes 
para a qualidade do software, e são listadas a seguir (MARTIN, 2000):
Single Responsability Principle, Open/Closed Principle, Liskov Substitution Principle, 
Interface Segregation Principle, Dependency Inversion Principle.
Quando esses princípios são executados de forma correta dentro do contexto do de-
senvolvimento do software, a quantidade de erros tende a diminuir, o código pode 
ser utilizado de uma forma dinâmica e a manutenção evolutiva/corretiva torna-se 
mais fácil de ser executada.
98
Programação orientada a objetosii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
Deseja conhecer mais sobre a história e alguns princípios de qualidade em 
codificação e como eles se tornaram referência mundial em qualidade de 
projetos orientado a objetos? Acesse o link 
https://goo.gl/pmXyZ5 
e veja a tradução do livro que originou os padrões de software.
6.1.2 PRINCÍPIO DE RESPONSABILIDADE ÚNICA
O princípio de responsabilidade única (SRP) auxilia na compreensão de um dos prin-
cipais pilares da orientação a objetos: a coesão. Quando se analisa a coesão, tende-se 
a pensar sobre a capacidade de um contexto ser bem explicado através somente de 
suas partes. Da mesma forma, uma classe coesa na orientação a objetos é aquela que 
deve ter somente um motivo para mudar, pois só uma responsabilidade é ligada a ela. 
Imagine que você trabalha em uma classe Veiculo que possui os seguintes métodos:
public void cadastrarVeiculo(Veiculo veiculo)....
public int calcularMultasVeiculo(Veiculo, Multa multa)..
public void listarVeiculosNaoLicenciados()...
Veja que, no contexto analisado, existem duas funções que são pertinentes ao con-
texto de uma classe Veiculo, mas é notório que um dos métodos não apresenta ca-
racterísticas em comum com a classe Veiculo. Porém, você pode pensar que uma 
multa faz parte de um veículo, contudo, nesse contexto de software, a classe que 
deveria ter o método de calcular multas deveria ser uma classe Multa. 
99
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
O princípio de responsabilidade única auxilia o desenvolvedor a entender que uma 
classe deve tratar única e exclusivamente do contexto ao qual ela pertence, pois em 
situações que serão necessárias correções é mais fácil trabalhar com contextos iguais. 
Quando se tem uma classe com mais de uma função contextual (classe de Veicu-
lo atuando com cálculo de multas), você perde a capacidade de rastreamento de 
problemas, dificulta a manutenção do código e aumenta a análise de impacto de 
mudanças em uma classe, pois a cada nova mudança deve-se verificar se as funcio-
nalidades em outra classe que estão ligadas ao contexto analisado também não so-
freram alterações. Tais fatores são prejudiciais para a utilização do reúso de software, 
pois essa classe deverá ser utilizada com outras que podem não pertencer ao novo 
contexto que ela está sendo utilizada (BARNERS, 2009).
A figura 31 apresenta o conceito de única responsabilidade para não sobrecarregar 
as funções do sistema.
FIGURA 31 - DESTAQUE DAS RESPONSABILIDADES EM GRANDES EMPRESAS E SISTEMAS
Fonte: SHUTTERSTOCK, 2019.
100
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
A classe a seguir permite a conexão e a busca de dados diretamente em um 
banco de dados. Veja que o programador programou a classe de forma a 
não respeitar o SRP. A classe trata de pesquisas no banco de dados relativo a 
disciplinas, porém o foco do método implementado é uma lista que retorna 
professores. O programador utilizou juntamente com o C# uma linguagem 
chamada hql (Hibernate Query Language). Por mais que exista um objeto 
disciplina que compõe a query, não é correto esse método ficar nessa classe, 
pois a resposta obtida será uma lista de professores.
public class DisciplinaDAO extends AppDAO {
 @PlcQuery(“querySel”)
 public native List<ProfessorEntity> findList(
 PlcBaseContextVO context,
 @PlcQueryOrderBy String dynamicOrderByPlc,
 @PlcQueryFirstLine Integer primeiraLinhaPlc, 
 @PlcQueryLineAmount Integer numeroLinhasPlc,
 @PlcQueryParameter(name=”id”, expression=”obj.id = :id”) Long id,
 @PlcQueryParameter(name=”nome”, expression=”obj.nome like :nome || 
‘%’ “) String nome,
 @PlcQueryParameter(name=”cargaHoraria”, expression=”obj.caragaHora-
ria = :cargahoraria”) int cargaHoraria,
 @PlcQueryParameter(name=”disciplina”, expression=”obj1 = :disci-
plina”) Disciplina
 );
}
6.1.3 PRINCÍPIO DE SEGREGAÇÃO DE INTERFACES
Esse princípio é voltado para o cuidado na construção de interfaces, permitindo que 
os métodos de uma estrutura de interface sejam coerentes dentro do ambiente apli-
cado. Como se sabe, ao implementar uma interface, o usuário deve implementar to-
dos os métodos abstratos da interface, pois ela cria . Quando se tem métodos em de-
101
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
masia, pode ser necessário fazer implantações em classes que podem não aproveitar 
de forma nenhuma o novo método. Por isso, as interfaces devem ser enxutas e per-
mitir que somente os métodos pertinentes ao seu contexto sejam implementados.
O Princípio de Segregação de Interface (ISP) nos diz que os clientes (classes) não de-
vem ser forçados a implementar interfaces que eles não usam, portanto não seja ge-
nérico nas interfaces, para que, por exemplo, uma classe Industria não tenha que im-
plementar métodos ligados a classes de Funcionarios ou Produtos. O ideal é construir 
uma interface para cada um dos seus contextos, permitindo, assim, que cada classe 
só implemente o que ela deve fazer e que tenha uma razoabilidade lógica dentro de 
seu contexto. Dessa maneira, quando alterações acontecerem em somente uma das 
classes, elas não refletirão em outras classes e gerarão grande quantidade de códigos.
Veja exemplos de Segregação de Interfaces no link: https://robsoncastilho.
com.br/2013/04/14/principios-solid-principio-da-segregacao-de-interface-
-isp/ 
6.1.4 PRINCÍPIO DO ABERTO FECHADO
O Princípio do Aberto Fechado (OCP) envolve a seguinte definição: os elementos de 
software devem ser abertos para a extensão e fechados para modificações. Apesar de 
ser uma definição simples, envolve muitos aspectos da qualidade de desenvolvimen-
to de software. Os programas e seus principais componentes devem estar aptos a 
implementarem o conceito de abstração de códigos, permitindo, assim, criar códigos 
novos ao invés de utilizar os existentes quando desejo implementar um comporta-
mento de um código existente para novas funcionalidades solicitadas. 
https://robsoncastilho.com.br/2013/04/14/principios-solid-principio-da-segregacao-de-interface-isp/
https://robsoncastilho.com.br/2013/04/14/principios-solid-principio-da-segregacao-de-interface-isp/
https://robsoncastilho.com.br/2013/04/14/principios-solid-principio-da-segregacao-de-interface-isp/
102
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
Apesar de esse princípio parecer ir contra os preceitos de reúso de software, ele é 
extremamente importante para a qualidade do desenvolvimento de aplicativos. Um 
software orientado a objetos deve permitir a extensibilidade, sendo que um compor-
tamento é implementado e transmitido as demais classes, evitando maior codifica-
ção de linhas de código. Quando uma funcionalidade já está funcionando, o ideal é 
permitir que outras classes usem ou adaptem suas funções, sem alterar a codificação 
original (BORATTI, 2007).
Os comportamentos que possibilitam ao OCP estar presente no código são a heran-
ça, as interfaces e a composição. Quando a modelagem prevê que uma herança ou 
uma interface possa difundir métodos de maneiras e funcionamentos distintos, o 
ideal é alterar as necessidades pontuais nas classes, evitando maior propagação de 
erros de código.
class Matricula {
 void efetuarMatricula(String tipo, Integer codigo, Double valor) {
 if (“POS”.equals(tipo)) {
 new IntegracaoFaculdade().matricularPos(codigo, valor);
 } else if (“GRADUACAO”.equals(tipo)) {
 new IntegracaoFaculdade().matricularGraduacao(codigo, valor);
 } else if (“ENSINOMEDIO”.equals(tipo)) {
 new IntegracaoFaculdade ().matricularEnsinoMedio(valor);
 }
 }
}
Essa classe precisará de mudanças sempre que um novo tipo de matrícula 
surgir. Podemos adequar:
class Matricula {
 void efetuarPagamento(IntegracaoFaculdade integracaoFaculdade, DadosPa-
gamento dadosPagamento) {
 integracaoFaculdade.matricular(dadosPagamento);
 }
}
Considere que IntegracaoFaculdade e DadosPagamento são interfaces e po-
dem ter várias implementações.
103
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
6.1.5 PRINCÍPIO DE SUBSTITUIÇÃO DE LISKOV
A Substituição de Liskov (LSP) é um princípio que nos informa sobre o melhor fun-
cionamento da herança entre classes, cuja definição é: classes derivadas devem po-
der ser substituídas por suas classes base. Isso significa que uma classe derivada 
deve ser estendida de sua classe base, sem alterar o seu comportamento. A utili-
zação do polimorfismo é essencial nesse contexto. Em classes em que a hierarquia 
de heranças é bem estabelecida e cada classe consegue realizar normalmente seu 
comportamento, dizemos que o LSP está dentro da conformidade esperada. Porém, 
quando existem problemas complexos de comportamento de classes que deviam 
agir com um comportamento A e realizam um comportamento B, o princípio não 
foi seguido corretamente.
Com a substituição de Liskov, podemos dizer que sempre que uma classe aguarda 
uma instância de A, podendo ser substituída por uma instância de A ou de B, pode-
mos constatar que nesse princípio toda classe base pode ser substituída por uma 
subclasse na sua cadeia de herança (SOMMERVILLE, 2001).
Na LSP, uma subclasse deve reescrever os métodos de sua classe pai, onde não seja 
possível a quebra de comportamento da classe base para o contexto em que ela já 
funcionava. Em outras palavras, se você usar uma herança e no momento que sobres-
crever um método da classe pai fazer com que ele tenha comportamento totalmen-
te distinto do esperado pela classe base, você estará violando o referido princípio. 
Veja mais sobre essa situação no exemplo clássico do quadrado e do retângulo. Pela 
geometria tradicional, podemos identificar o quadrado como sendo um retângulo 
em que a base e a altura são iguais. Ao implementar uma herança de quadrado (sub-
classe) para o retângulo (base), a alteração de implementação da base e da altura a 
ser feita em métodos sobrescritos na classe do quadrado pode violar o comporta-
mento nativo do retângulo, permitindo que objetos sofram alterações não espera-
das em suas respostas. No exemplo a seguir verificamos a classe eletrodoméstico, 
que será a base, e os filhos serão as classes Ventilador e Climatizador. Elas têm um 
comportamento muito parecido, porém um climatizador pode operar no modo de 
aquecimento, devido aos diferentes modos de ligar o eletrodoméstico. Para resolver 
tal problema, deve-se utilizar uma classe abstrata na classe base chamada ligar, e ela 
deve ser implementada em cada um dos métodos dos filhos.
104
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
class Eletrodomestico{
 private float tensao;
 private String marca;
 private String tipo;
 private String nome;
}
class Ventilador extends Eletrodomestico {
 private boolean ligar;
 
 public boolean geLigarVentilador(){
 return ligar=true;
 }
}
 
class Climatizador extends Eletrodomestico {
 private boolean ligar;
 private boolean aquecer;
 private boolean modoAquecer=false;
 
 public float geLigarClimatizador (){
 if(aquecer)
 this.modoaquecer=true;
 return ligar=true
 }
}
 class Empresa{
 private Date data;
 
 public void ligarEletrodomesticos(List eletrodomesticos){
 for(Eletrodomesticos e : eletrodomestico){
 
 if(eletrodomestico.getTipo().equals(“Ventilador”)){
 System.io.println(eletrodomestico.getNome() + “ Ligado----- 
“ + eletrodomestico. geLigarVentilador());
 }
105
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
 if(eletrodomestico.getTipo().equals(“Climatizador”)){
 System.io.println(eletrodomestico.getNome() + “ Ligado----- “ 
+ eletrodomestico.geLigarClmatizador (true));
 }
 }
 } 
}
Resolução:
class Eletrodomestico{
 private float tensao;
 private String marca;
 private String tipo;
 private String nome;
abstract void ligar( );
}
6.1.6 PRINCÍPIO DE INVERSÃO DE DEPENDÊNCIAS
O princípio da inversão de dependência (DIP) preconiza que módulos de alto nível 
não devem depender de módulos de baixo nível, permitindo, assim, que ambos de-
pendam de abstrações. Já as abstrações não devem depender de detalhes, mas sim 
os detalhes dependerem das abstrações. Com isso, classes não ficam tão vulneráveis 
a pequenas mudanças relacionadas a detalhes de implementações. 
Para construir classes que sigam esses princípios, os seguintes passos devem ser se-
guidos: 
• Todas as variáveis membro da classe devem ser interfaces ou classes abstratas.
• Todos os pacotes contendo classes concretas devem se comunicar somente 
através de interfaces ou classes abstratas.
106
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
• Nenhuma classe deve derivar de uma outra classe concreta.
• Nenhum método deve sobrescrever um método já implementado.
• Todas as instâncias de objetos devem ser criadas através de Padrões de Proje-
tos de criação como Factory.
De forma geral, não devemos depender de implementações, e sim de abs-
trações.
Vamos observar o seguinte bloco de código:
 public class Motor
{
 public void Ligar() { }
}
 
public class Carro
{
 private Motor motor;
 
 public void DarPartida()
 {
 motor.Ligar();
 }
}
Agora observe que a implementação da classe Carro depende diretamente 
da classe Motor, ou seja, qualquer manutenção ou nova implementação deve 
obrigatoriamente ocorrer na classe Motor. Agora observe o seguinte código:
 public interface IMotor
{
 public void Ligar();
}
public class Motor implements IMotor
{
 public void Ligar() { }
}
107
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
public class Carro
{
 private IMotor motor;
 
 public void DarPartida ()
 {
 motor.Ligar();
 }
}
Perceba que não temos mais dependência da implementação da classe, e 
sim da sua interface.
CONCLUSÃO 
O Padrão SOLID é fundamental para a qualidade de linhas de código, pois com ele o 
desenvolvedor pode melhorar qualidade da interação com outros componentes e, ao 
mesmo tempo, diminuir a quantidade de códigos desnecessários.
Para tanto, delegue somente uma responsabilidade ao contexto da classe e utilize 
interfaces de forma organizada, buscando diminuir a complexidade do sistema.
Outra característica relevante é que a herança deve ser bem organizada, pois ela po-
derá gerar quebras de paradigmas do padrão SOLID. Não se esqueça de preconizar a 
dependência de interfaces, e não das classes. E por fim, a aplicação do padrão SOLID 
facilita o reúso e diminui a complexidade do software.
108
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
REFERÊNCIAS 
BARNERS, David.Programação orientada a objetos com java. 4. ed. Prentice hall, 2009. 
BORATTI, Isaías Camilo. Programação orientada a objetos em java. Visual Books, 2007.
DAMAS, Luis Manuel Dias. Linguagem “C”. 10. ed. Rio de Janeiro: LTC, 2007. 410p.
DEITEL, Harvey M. C#: como programar. São Paulo: Pearson Makron Books, 2007. 1153p.
GREENE, Jhennifer; STEELMAN, Andrew. Use a cabeça: C#. Rio de Janeiro: Alta Books, 
2008. 618p.
ROCHA, H. Programação Orientada a Objetos com Java2SE, 2003. Disponível em <http://
argonavis.com.br/download/java2.html>. Acesso em: 09 dez. 2018.
SCHILDT, Herbert. C completo e total. São Paulo: Pearson Makron Books, 1997. 827p.
SHARP, John. microsoft visual C# 2008: passo a passo. Porto Alegre: Bookman, 2008. 
624p. 
SILVA FILHO, Antonio Mendes da. introdução à programação orientada a objetos. Rio de 
Janeiro: Campus, 2010.
BARNERS, Davi. Programação orientada a objetos com java. 4. ed. Prentice Hall, 2009. 
BORATTI, Isaías Camilo. Programação orientada a objetos em java. Visual Books, 2007.
DAMAS, Luis Manuel Dias. Linguagem “C”. 10. ed. Rio de Janeiro: LTC, 2007.
DEITEL, Harvey M. C#: como programar. São Paulo: Pearson Makron Books, 2007.
GREENE, Jhennifer; STEELMAN, Andrew. Use a cabeça: C#. Rio de Janeiro: Alta Books, 
2008.
SCHILDT, Herbert. C completo e total. São Paulo: Pearson Makron Books, 1997.
http://argonavis.com.br/download/java2.html
http://argonavis.com.br/download/java2.html
109
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
SHARP, John. microsoft visual C# 2008: passo a passo. Porto Alegre: Bookman, 2008. BAR-
NERS, Davi. Programação orientada a objetos com java. 4. ed. Cidade: Prentice Hall, 2009. 
BORATTI, Isaías Camilo. Programação orientada a objetos em java. Cidade: Visual Books, 
2007.
DAMAS, Luis Manuel Dias. Linguagem “C”. 10. ed. Rio de Janeiro: LTC, 2007. 410 p.
DEITEL, Harvey M. C#: como programar. São Paulo: Pearson Makron Books, 2007. 1153 p.
GREENE, Jhennifer; STEELMAN, Andrew. Use a cabeça: C#. Rio de Janeiro: Alta Books, 
2008. 618 p.
SHARP, John. microsoft visual C# 2008: passo a passo. Porto Alegre: Bookman, 2008. 624 
p.
BARNERS, Davi. Programação orientada a objetos com java. 4. ed. Prentice hall, 2009. 
BORATTI, Isaías Camilo. Programação orientada a objetos em java. Visual Books, 2007.
DAMAS, Luís Manuel Dias. Linguagem “C” “C”. 10. ed. Rio de Janeiro: LTC, 2007. 410p.
DEITEL, Harvey M. C#: como programar. São Paulo: Pearson Makron Books, 2007. 1153p.
GREENE, Jhennifer; STEELMAN, Andrew. Use a cabeça: C#. Rio de Janeiro: Alta Books, 
2008. 618p.
SHARP, John. microsoft visual C# 2008: passo a passo. Porto Alegre: Bookman, 2008. 
624p.
BARNERS, Davi. Programação orientada a objetos com java. 4. ed. Belo Horizonte: Pear-
son, 2009. 
BORATTI, Isaías Camilo. Programação orientada a objetos em java. Florianópolis: Visual-
Books, 2007.
DAMAS, Luís Manuel Dias. Linguagem C.10. ed. Rio de Janeiro: LTC, 2007. 410 p.
110
Programação orientada a objetos ii 
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017SUMÁRIO
DEITEL, Harvey M. C#: como programar. São Paulo: Pearson Makron Books, 2007. 1.153 p.
GREENE, Jhennifer; STEELMAN, Andrew. Use a cabeça: C#. Rio de Janeiro: Alta Books, 
2008. 618 p.
MARTIN, Robert C.; MARTIN, Micah. agile principles, patterns, and practices in C. EUA: 
Pearson Education, 2006.
MARTIN, Robert C. design principles and design patterns. Object Mentor, n. 34, v. 1, p. 
597, 2000.
SHARP, John. Microsoft visual C# 2008: passo a passo. Porto Alegre: Bookman, 2008. 624 p.
SOMMERVILLE, Ian et al. software engineering. 9th ed. EUA: Pearson Education, 2011.
EAD.MULTIVIX.EDU.BR
CONHEÇA TAMBÉM NOSSOS CURSOS DE PÓS-GRADUAÇÃO A DISTÂNCIA NAS ÁREAS DE:
SAÚDE • EDUCAÇÃO • DIREITO • GESTÃO E NEGÓCIOS
111
FACULDADE CAPIXABA DA SERRA/EAD
Credenciada pela portaria MEC nº 767, de 22/06/2017, Publicada no D.O.U em 23/06/2017
Programação orientada a objetos ii 
SUMÁRIO
EAD.MULTIVIX.EDU.BR
CONHEÇA TAMBÉM NOSSOS CURSOS DE PÓS-GRADUAÇÃO A DISTÂNCIA NAS ÁREAS DE:
SAÚDE • EDUCAÇÃO • DIREITO • GESTÃO E NEGÓCIOS
	FIGURA 1 - Diagrama de Classes
	FIGURA 2 - Diagrama de Casos de Uso
	FIGURA 3 - Diagrama de Sequência
	FIGURA 4 - Criação de três objetos Casa com suas respectivas características
	FIGURA 5 - Exemplo de diagrama de componentes
	FIGURA 6 - Interface programada na linguagem C#
	FIGURA 7 - Contêiner de conteúdo representando um calendário
	FIGURA 8 - Interface do Visual Studio
	FIGURA 9 - Exemplo de interação com o usuário durante transferência e cópia de arquivos
	FIGURA 10 - Mensagem de aviso de um sistema computacional
	FIGURA 11 - Diagrama de casos de uso
	FIGURA 12 - Exemplo de diagrama de sequência da UML
	FIGURA 13 - Exemplo de diagrama de componentes
	FIGURA 14 - Planejamento de etapas do escopo de projeto de componentes
	FIGURA 15 - Reunião para definição da documentação do projeto
	FIGURA 16 - Pesquisas em interfaces de hardware e software para a inclusão de novos componentes
	FIGURA 17 - Windows
	FIGURA 18 - Interface do Linux
	FIGURA 19 - Máquina atuando na vida das pessoas
	FIGURA 20 - Divisão de serviços de software
	FIGURA 21 - Serviços de software
	FIGURA 22 - Sistemas ERP e sua relevância para a empresa
	FIGURA 23 - Exemplo de soluções completas para compras on-line
	FIGURA 24 - Repositório de componentes compartilhando serviços de software
	FIGURA 25 - Comunicação de dispositivos localmente separados por meio de requisições e mensagens
	FIGURA 26 - Serviços de software
	FIGURA 27 - Matriz de avaliação entre reúso e produtividade
	FIGURA 28 - Classe Usuario
	FIGURA 29 - Principais etapas que devem existir em reúso de componentes
	FIGURA 30 - Elementos presentes nas interfaces web
	FIGURA 31 - Destaque das responsabilidades em grandes empresas e sistemas
	1 Revisão de conceitos de orientação a objetos e Conceitos de componentes
	1.1 1. Revisão de Conceitos de Orientação a Objetos e Conceitos de Componentes
	1.1.1 Introdução ao desenvolvimento de softwares orientado a objetos
	1.1.2 Classes e Objetos
	1.1.3 Atributos e Métodos
	1.1.4 Introdução aos componentes de software
	1.1.4.1 Exemplos de utilização de componentes
	Conclusão 
	2 Interfaces, contêineres, interação e projetos de componentes
	2.1 INTERFACES, CONTÊINERES, INTERAÇÃO E PROJETOS DE COMPONENTES 
	2.1.1 Interfaces
	2.1.1.1 Exemplos de interfaces
	2.1.2 Contêineres
	2.1.3 Interação
	2.1.4 Projetos
	CONCLUSÃO 
	3 Escopo, objetivo e abstração de componentes
	3.1 Conceito de escopo de componentes
	3.1.1 Recursos utilizados no escopo de componentes
	3.1.1.1 Exemplos de problemas em escopo de componentes
	3.2 Principais objetivos dos componentes
	3.3 Abstração de componentes
	Conclusão 
	4 Granularidade, Localização e Serviço de Componentes
	4.1 4 GRANULARIDADE, LOCALIZAÇÃO E SERVIÇOS DE COMPONENTES
	4.1.1 Granularidade de componentes 
	4.1.2 Localização de componentes
	4.1.3 Serviços de componentes
	Conclusão 
	5 Reúso e Refatoração de Componentes de software
	5.1 REÚSO E REFATORAÇÃO NOS COMPONENTES DE SOFTWARE
	5.1.1 Reúso de componentes de software
	5.1.1.1 Projetos de componentes com reúso
	5.2 Refatoração de componentes de software
	Conclusão 
	6 Padrões de projeto para construção de componentes com reúso
	6.1 Padrões de projeto para a construção de componentes com reuso
	6.1.1 Introdução aos padrões de software
	6.1.2 Princípio de responsabilidade única
	6.1.3 Princípio de segregação de interfaces
	6.1.4 Princípio do aberto fechado
	6.1.5 Princípio de substituição de Liskov
	6.1.6 Princípio de Inversão de dependências
	Conclusão 
	REFERÊNCIAS