Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Listei abaixo os principais tópicos que tornam essa análise fundamental para que se verifique a
viabilidade dos projetos a serem desenvolvidos.
A análise de viabilidade exige precisão nos dados, de maneira que as respostas obtidas nas previsões
se mostrem exatas ou muito próximas da realidade. Ter esses dados em mãos é muito importante para
que o projeto saia do papel.
Planejamento Eficiente
Para que se possa fazer uma análise completa, é essencial que haja a definição das problemáticas a
serem sanadas, bem como dos objetivos esperados. Então, quando se faz essa análise também se
têm, consequentemente, melhores soluções para eventuais problemas que venham a surgir.
Projeções Claras
-------------------------------------------------------------------------------------------------------------------------------------------
Orientação a objeto é um conceito que está relacionado com a ideia de classificar, organizar e abstrair
coisas. Veja a definição formal:
"O termo orientação a objetos significa organizar o mundo real como uma coleção de objetos que
incorporam estrutura de dados e um conjunto de operações que manipulam estes dados."
Vamos falar uma linguagem mas simples para isto vamos para um ambiente que você conhece bem: A
sua casa!
Agora vamos olhar a sua estante , o seu guarda-roupa , o seu armário, a sua cozinha. Em todos estes
lugares você classificou coisas no seu domínio e, somente de olhar para eles você já sabe relacionar a
classificação que utilizou em cada um deles e como classificou as coisas que estão neste lugares.
Na estante você agrupou e organizou os livros , no guarda roupa suas camisas, calças, meias, ternos,
etc. Todos os objetos que você classificou nestes lugares foram organizados baseado em alguma
concepção que você possuía sobre eles.
Uma classe é um gabarito para a definição de objetos. Através da definição de uma classe, descreve-se
que propriedades -- ou atributos -- o objeto terá.
Na 'classe' do seu guarda-roupa, uma camisa amarela pode ser colocada em uma outra classe. A
'classe' camisa.
Cada camisa tem uma estrutura que é: a textura, a cor, o tamanho e o modelo.
Se você concordar que existe uma classe camisa. Vai concordar que existem diversos tipos de camisas
com suas características, ou seja , existem diversos objetos camisas que podem ser criados a partir da
classe camisa. Daí temos o conceito de objetos:
O conceito de orientação a objetos é abordado desta mesma maneira sempre. No contexto do software
podemos então dizer que:
Primeiro você classifica e abstrai os elementos no sistema para proporcionar uma certa ordem, e, ao
fazer isto você define uma classe;
Feita a definição da classe você pode criar objetos desta classe. (instanciar)
Existem alguns conceitos básicos que estão vinculados ao conceito de orientação a objetos. São eles:
● Herança
● Encapsulamento
● Polimorfismo
A herança permite implementar a funcionalidade a sua classe de tomar emprestado o resto da estrutura
e comportamento de classes de nível mais alto.
As rodas e o motor são atributos comuns a qualquer carro. Já uma Ferrari possui atributos que somente
ela possui : o seu alto valor por exemplo.
Herança é um mecanismo que permite que características comuns a diversas classes sejam agrupadas
em uma classe base, ou superclasse. A partir de uma classe base, outras classes podem ser
especificadas. Cada classe derivada ou subclasse apresenta as características (estrutura e métodos) da
classe base e acrescenta a elas o que for definido de particularidade para ela
Encapsular significa "ocultar informações" ele define que cada objeto contém todos os detalhes de
implementação necessários sobre como ele funciona e oculta os detalhes internos sobre como ele
executa os serviços.
Quando você acelera um carro você está enviando uma mensagem ao motor do carro usando o
acelerador e o carro sabe que tem que acelerar.
Você não precisa saber como é feita a aceleração no motor você apenas pisa fundo no acelerador, a
implementação de como é feita a aceleração esta encapsulada do cliente.
Polimorfismo significa muitas formas , na orientação a objetos você pode enviar uma mesma mensagem
para diferentes objetos e fazê-los responder da maneira correta. Você pode enviar a mensagem de dar
marcha-ré para cada objeto semelhante a um carro e cada um vai se comportar de maneira diferente
para atender a sua solicitação.
"Polimorfismo é o princípio pelo qual duas ou mais classes derivadas de uma mesma superclasse
podem invocar métodos que têm a mesma identificação (assinatura) mas comportamentos distintos,
especializados para cada classe derivada, usando para tanto uma referência a um objeto do tipo da
superclasse"
Pensar em orientação a objetos realmente não é fácil e também não é a panacéia universal.
Muitas das linguagens de programação mais utilizadas atualmente (talvez a maioria) são multi-
paradigma com suporte à POO. C++, C#, VB.NET, Java, Object Pascal, Objective-C, Python,
SuperCollider, Ruby e Smalltalk são exemplos de linguagens de programação orientadas a objetos.
ActionScript, ColdFusion, Javascript, PHP (a partir da versão 4.0), Perl (a partir da versão 5), Visual
Basic (a partir da versão 4), VimL (ou Vim script) são exemplos de linguagens de programação com
suporte a orientação a objetos. Vivace[3] é um exemplo de linguagem sem suporte à POO.
-------------------------------------------------------------------------------------------------------------------------------------------
“O que é Orientação a Objetos? Por que preciso tanto saber sobre isso?”
Essa é uma dúvida muito comum entre iniciantes no mundo do desenvolvimento de software.
Isso porque, quando falamos em desenvolvimento de software e seus paradigmas, existe uma
sequência de aprendizado natural:
1. Programação Imperativa
2. Programação Orientada a Objetos
3. Programação Funcional
Não que isso seja uma regra fixa e imutável, mas na maioria das vezes é a curva de aprendizado de um
desenvolvedor de sucesso. E, programação orientada a objetos (popularmente conhecida como
POO), como você pode ver, ocupa um papel central nesse processo.
Pois então, é exatamente sobre isso que irei falar nesse post, para assim, te ajudar a posicionar a sua
carreira profissional de acordo com todo esse cenário do mercado de programação.
Portanto, nesse post irei explicar o que é Programação Imperativa e, obviamente, o que é
Programação Orientada a Objetos. Para finalizar, pretendo deixar claro o porquê de POO ser tão
importante no mercado de desenvolvimento de software atual.
Programação imperativa
A Programação Imperativa é aquela que 99.99% dos desenvolvedores aprendem em seus primeiros
contatos com a área de programação. Geralmente, você aprende esse paradigma através de um curso
online como o da Becode ou na própria faculdade, digamos em um curso de Sistemas de Informação
(ou qualquer outro similar), onde a primeira disciplina provavelmente será “Algoritmos Estruturados ou
fundamentos da programação”.
Nessa etapa, o aluno irá ver os conceitos iniciais e extremamente importantes, geralmente pautados no
“Portugol” ou, muitas vezes, na Linguagem C.
Isso é muito comum, pois linguagens como a C possuem em seu cerne o paradigma de
desenvolvimento imperativo, ou seja, todo aplicativo/algoritmo é desenvolvido pensando-se em uma
série de etapas que o software deve cumprir para atingir o seu objetivo.
Um exemplo clássico disso seria pensarmos quais são as etapas para a troca de uma lâmpada? De
forma bem sucinta, podemos enumerar:
1. Desligar o interruptor;
2. Pegar uma escada;
3. Montar a escada;
4. Subir na escada;
5. Desenroscar a lâmpada queimada;
6. Descer da escada;
7. Jogar a lâmpada queimada no lixo;
8. Pegar uma lâmpada nova;
9. Subir na escada;
10. Rosquear a nova lâmpada;
11. Descer da escada;
12. Ligar o interruptor para verificar se a nova lâmpada acende.
Simples não é? 12 passos.
Claro, para a grande maioria dos casos, você pode chegar a uma mesma solução executando passos
diferentes, dependendo da sua escolha. Como, por exemplo, já levar a lâmpada boa quando subir a
primeira vez na escada. É justamente isso que torna a computação algo muito divertido, visto que
podemos chegar a resultados idênticos, por diferentes caminhos.
Essa etapa é natural e muito importante na formação de um desenvolvedor. Portanto, não deve ser
atalhada!
Isso, a princípio pode parecer ruim, “mais uma coisa para aprender”, mas na verdade é o que vai
permitir o desenvolvedor “subir de nível”. Agora, sabendo POO, o desenvolvedor poderá resolver os
mesmo problemas utilizando, não somente o passo-a-passo tradicional, mas também uma modelagem
do problema de uma forma mais natural/real.
Vejamos o mesmo exemplo para trocar de uma lâmpada, agora usando a Programação Orientada a
Objetos (POO). A primeira coisa a fazer é pensarmos em classes. Em outras palavras, coisas
envolvidas no estudo de caso (trocar uma lâmpada):
Definido isso, podemos combinar suas características e ações. Por exemplo: “uma Pessoa pega uma
Lâmpada boa”.
Apenas esse fato de dizer que a “Pessoa” “pega” “Lâmpada” “boa” já nos diz muita coisa, pois tudo
isso pode ser modelado usando o paradigma de Orientação a Objetos. Em outras palavras, tudo não
passa de modelar Objetos que possuem ações e características.
Em nosso caso, “Pessoa” seria uma classe/objeto, “pega” seria uma ação da “Pessoa”, “Lâmpada”
seria uma outra classe/objeto e “boa” seria o estado/característica/atributo da “Lâmpada”.
Então, essa pergunta pode ser respondida em duas etapas: linguagens de programação e
valorização no mercado profissional
Sim, exato! Hoje em dia, o mercado de programação é dominado pelo paradigma orientado a objetos.
Em outras palavras, é raro você trabalhar com uma linguagem de programação atual que não suporte
POO. Sendo assim, fica claro o meu 1º ponto:
[easy-tweet tweet=”Saber POO não é capricho, mas sim uma exigência do mercado.” user=”becodett
@jackson_pires” hashtags=”POO” template=”light”]
“Eu sei programar em ‘linguagem Orientada a Objetos’, mas não domino os fundamentos de POO”
Claro, isso é possível. Contudo, provavelmente você não estará utilizando o melhor que aquela
linguagem de programação tem a oferecer.
Resumindo, existem dois tipos de desenvolvedores: aqueles que fazem e aqueles que fazem e
sabem o que estão fazendo (teoria + prática).
O primeiro é aquele que provavelmente aprendeu a programar totalmente na prática, sem uma base
teórica de qualidade, o que não está errado, mas também não estará em suas plenas capacidades
profissionais.
Já o segundo, além de programar, consegue abstrair os requisitos do mundo real para o software,
utilizando os conceitos de Orientação a Objetos no desenvolvimento do produto. A consequência
disso é a utilização das melhores práticas, um software mais duradouro em termos de manutenibilidade
e uma qualidade final de software superior.
Aí eu te pergunto, qual desenvolvedor será mais valorizado e possuirá mais chances de ter uma
carreira de sucesso? Aquele que sabe programar ou aquele que sabe programar e também entende
os paradigmas de programação
Resumindo…
Se programação orientada a objetos for uma novidade pra você, tenho certeza que mexeu com seus
neurônios, mas ao mesmo tempo te deixou na vontade de entender a fundo como tudo isso funciona.
Obviamente, em um artigo com poucas palavras é quase impossível explicar de forma clara o que vem
de fato a ser a POO. Por outro lado, fica claro também que conhecer esse paradigma faz parte da
evolução natural do desenvolvedor e fazer carreira nessa área depende também de ter ou não esse
conhecimento em seu sangue.
Mesmo com tantos percalços, o mais legal é que esse paradigma, depois de aprendido, pode ser
aplicado a qualquer linguagem de programação que o suporte.
-------------------------------------------------------------------------------------------------------------------------------------------
Basicamente, UML (Unified Modeling Language) é uma linguagem de notação (um jeito de escrever,
ilustrar, comunicar) para uso em projetos de sistemas.
Esta linguagem é expressa através de diagramas. Cada diagrama é composto por elementos (formas
gráficas usadas para os desenhos) que possuem relação entre si.
Diagramas estruturais devem ser utilizados para especificar detalhes da estrutura do sistema (parte
estática), por exemplo: classes, métodos, interfaces, namespaces, serviços, como componentes devem
ser instalados, como deve ser a arquitetura do sistema etc.
UML ajuda muito a deixar o escopo claro, pois centraliza numa única visão (o diagrama) um
determinado conceito, utilizando uma linguagem que todos os envolvidos no projeto podem facilmente
entender.
Mas ajuda desde que utilizada na medida certa, ou seja, apenas quando realmente é necessário.
O maior problema na produção de software, a maior dor, em qualquer país do mundo, chama-se
comunicação ruim.
O objetivo de um diagrama da UML é passar uma mensagem de maneira padronizada, onde todos os
receptores deste mensagem entendem o padrão usado.
No passado utilizou-se UML muito para documentar software existente, fazer projeto preditivo de
sistema (ou seja, via diagrama documentar 100% do que deveria ser feito) etc. Isso quase nunca é
viável.
A UML serve para uma boa comunicação em equipes que produzem software, onde através do uso
de diagramas adotamos uma linguagem que todos entendem, para deixar claro o que deve ser feito.
Quando usar?