{"id":34855,"date":"2019-10-31T22:00:51","date_gmt":"2019-10-31T19:00:51","guid":{"rendered":"https:\/\/prohoster.info\/blog\/10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik\/"},"modified":"2019-10-31T22:00:51","modified_gmt":"2019-10-31T19:00:51","slug":"10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/news\/10-printsipov-obektno-orientirovannogo-programmirovaniya-o-kotoryh-dolzhen-znat-kazhdyj-razrabotchik","title":{"rendered":"10 princ\u00edpios da programa\u00e7\u00e3o orientada a objetos que todo desenvolvedor deve conhecer","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"10
\n
\nEu frequentemente encontro desenvolvedores que nunca ouviram falar dos princ\u00edpios SOLID (n\u00f3s fomos detalhados a respeito aqui<\/a><\/noindex>. \u2014 Nota do autor) ou da programa\u00e7\u00e3o orientada a objetos (POO), ou ouviram, mas n\u00e3o os utilizam na pr\u00e1tica. Este artigo descreve as vantagens dos princ\u00edpios de POO que ajudam o desenvolvedor no seu trabalho di\u00e1rio. Alguns deles s\u00e3o bem conhecidos, outros nem tanto, por isso o artigo ser\u00e1 \u00fatil tanto para iniciantes quanto para programadores j\u00e1 experientes.
\n<\/a><\/noindex><\/p>\n

Lembramos:<\/b> para todos os leitores do \u00ab\u0425\u0430\u0431\u0440\u0430\u00bb \u2014 desconto de 10.000 rublos na inscri\u00e7\u00e3o em qualquer curso da Skillbox usando o c\u00f3digo promocional \u00ab\u0425\u0430\u0431\u0440\u00bb.<\/i><\/p>\n

A Skillbox recomenda:<\/b> Curso online educacional \u00abDesenvolvedor Java\u00bb<\/a><\/noindex>.<\/p><\/blockquote>\n

<\/p>\n

DRY (Don\u2019t Repeat Yourself)<\/h3>\n

\nUm princ\u00edpio bastante simples, cuja ess\u00eancia \u00e9 clara atrav\u00e9s do nome: \u00abN\u00e3o se repita\u00bb. Para o programador, isso significa a necessidade de evitar c\u00f3digo duplicado, al\u00e9m de permitir o uso de abstra\u00e7\u00e3o no trabalho.<\/p>\n

Se houver duas partes do c\u00f3digo que se repetem, elas devem ser combinadas em um \u00fanico m\u00e9todo. Se um valor fixo \u00e9 usado mais de uma vez, deve ser transformado em uma constante p\u00fablica.<\/p>\n

Isso \u00e9 necess\u00e1rio para simplificar o c\u00f3digo e facilitar sua manuten\u00e7\u00e3o, que \u00e9 a principal tarefa da POO. N\u00e3o se deve abusar da combina\u00e7\u00e3o, j\u00e1 que o mesmo c\u00f3digo n\u00e3o passaria na verifica\u00e7\u00e3o tanto com OrderId quanto com SSN.<\/p>\n

Encapsula\u00e7\u00e3o de mudan\u00e7as<\/h3>\n

\nOs produtos de software da maioria das empresas est\u00e3o em constante evolu\u00e7\u00e3o. Portanto, \u00e9 necess\u00e1rio fazer mudan\u00e7as no c\u00f3digo e mant\u00ea-lo. Voc\u00ea pode simplificar sua vida atrav\u00e9s da encapsula\u00e7\u00e3o. Isso permitir\u00e1 testar e manter a base de c\u00f3digo existente de forma mais eficaz. Aqui est\u00e1 um dos exemplos<\/a><\/noindex>.<\/p>\n

Se voc\u00ea est\u00e1 escrevendo em Java, ent\u00e3o por padr\u00e3o, atribua o modificador private a m\u00e9todos e vari\u00e1veis<\/a><\/noindex>.<\/p>\n

Princ\u00edpio da abertura\/fechamento<\/h3>\n

\nEste princ\u00edpio pode ser facilmente lembrado ao ler a seguinte afirma\u00e7\u00e3o: \u00abEntidades de software (classes, m\u00f3dulos, fun\u00e7\u00f5es, etc.) devem estar abertas para extens\u00e3o, mas fechadas para modifica\u00e7\u00e3o\u00bb. Na pr\u00e1tica, isso significa que elas podem permitir mudan\u00e7as em seu comportamento sem alterar o c\u00f3digo fonte.<\/p>\n

O princ\u00edpio \u00e9 importante quando as altera\u00e7\u00f5es no c\u00f3digo-fonte exigem uma revis\u00e3o, testes em m\u00f3dulos e outras procedimentos. O c\u00f3digo que segue o princ\u00edpio de abertura\/fechamento n\u00e3o \u00e9 alterado ao ser ampliado, portanto, causa muito menos problemas.<\/p>\n

Aqui est\u00e1 um exemplo de c\u00f3digo que viola esse princ\u00edpio.<\/p>\n

\"10
\n
\nSe precisar fazer alguma altera\u00e7\u00e3o, isso levar\u00e1 muito tempo, pois ser\u00e1 necess\u00e1rio modificar todas as partes do c\u00f3digo que possuem liga\u00e7\u00e3o com o fragmento desejado.<\/p>\n

A prop\u00f3sito, abertura\/fechamento \u00e9 um dos princ\u00edpios SOLID.<\/p>\n

Princ\u00edpio da responsabilidade \u00fanica (SRP)<\/h3>\n

\nOutro princ\u00edpio do conjunto SOLID. Ele afirma que \"existe apenas uma raz\u00e3o para modificar uma classe\". A classe resolve apenas uma tarefa. Ela pode ter v\u00e1rios m\u00e9todos, mas cada um deles \u00e9 utilizado apenas para resolver um problema espec\u00edfico. Todos os m\u00e9todos e propriedades devem servir somente a isso. <\/p>\n

\"10
\n
\nO valor desse princ\u00edpio reside em que ele diminui a liga\u00e7\u00e3o entre cada componente do software e o c\u00f3digo. Se mais de uma funcionalidade for adicionada a uma classe, isso introduz uma liga\u00e7\u00e3o entre duas fun\u00e7\u00f5es. Assim, se uma delas for alterada, h\u00e1 uma grande chance de prejudicar a segunda, relacionada \u00e0 primeira. Isso significa um aumento nos ciclos de teste para detectar todos os problemas antecipadamente.<\/p>\n

Princ\u00edpio da invers\u00e3o de depend\u00eancia (DIP)<\/h3>\n

\n\"10
\n
\nO exemplo de c\u00f3digo acima mostra que AppManager depende de EventLogWriter, que, por sua vez, est\u00e1 intimamente ligado ao AppManager. Se for necess\u00e1rio um m\u00e9todo diferente para exibir uma notifica\u00e7\u00e3o, seja por push, SMS ou email, ser\u00e1 preciso alterar a classe AppManager.<\/p>\n

O problema pode ser resolvido utilizando o DIP. Assim, em vez de AppManager, requisitamos o EventLogWriter, que ser\u00e1 introduzido por meio de um framework.<\/p>\n

O DIP permite substituir m\u00f3dulos individuais por outros sem problemas, alterando o m\u00f3dulo de depend\u00eancia. Isso possibilita modificar um m\u00f3dulo sem impactar os demais.<\/p>\n

Composi\u00e7\u00e3o em vez de heran\u00e7a<\/h3>\n

\n\"10Existem duas principais formas de reutiliza\u00e7\u00e3o de c\u00f3digo \u2014 heran\u00e7a e composi\u00e7\u00e3o, cada uma com suas vantagens e desvantagens. Normalmente, a segunda \u00e9 preferida, pois \u00e9 mais flex\u00edvel.<\/p>\n

A composi\u00e7\u00e3o permite modificar o comportamento de uma classe em tempo de execu\u00e7\u00e3o, ajustando suas propriedades. Ao implementar interfaces, utiliza-se o polimorfismo, que oferece uma implementa\u00e7\u00e3o mais flex\u00edvel.<\/p>\n

At\u00e9 mesmo \"Effective Java\" de Joshua Bloch recomenda dar prefer\u00eancia \u00e0 composi\u00e7\u00e3o em vez da heran\u00e7a.<\/p>\n

O Princ\u00edpio da Substitui\u00e7\u00e3o de Liskov (LSP)<\/h3>\n

\nOutro princ\u00edpio do conjunto SOLID. Ele afirma que os subtipos devem ser substitu\u00edveis pelo supertipo. Ou seja, m\u00e9todos e fun\u00e7\u00f5es que operam no superclasse devem ser capazes de funcionar sem problemas com suas subclasses.<\/p>\n

O LSP est\u00e1 relacionado tanto ao princ\u00edpio da responsabilidade \u00fanica quanto ao princ\u00edpio da separa\u00e7\u00e3o de responsabilidades. Se uma classe oferece mais funcionalidade do que sua subclasse, esta \u00faltima pode n\u00e3o suportar algumas fun\u00e7\u00f5es, violando esse princ\u00edpio.<\/p>\n

Aqui est\u00e1 um trecho de c\u00f3digo que contraria o LSP.<\/p>\n

\"10
\n
\nO m\u00e9todo area(Rectangle r) calcula a \u00e1rea de um Rectangle. O programa falhar\u00e1 ao executar Square, j\u00e1 que Square n\u00e3o \u00e9 um Rectangle neste contexto. De acordo com o princ\u00edpio LSP, fun\u00e7\u00f5es que utilizam refer\u00eancias a classes base devem poder usar objetos de classes derivadas sem instru\u00e7\u00f5es adicionais.<\/p>\n

Este princ\u00edpio, que \u00e9 uma defini\u00e7\u00e3o espec\u00edfica de subtipo, foi proposto por Barbara Liskov em 1987 durante uma confer\u00eancia em uma palestra principal intitulada \"Abstra\u00e7\u00e3o de Dados e Hierarquia\" \u2014 da\u00ed o seu nome.<\/p>\n

O Princ\u00edpio da Separa\u00e7\u00e3o de Interface (ISP)<\/h3>\n

\nMais um princ\u00edpio do SOLID. Segundo ele, uma interface que n\u00e3o \u00e9 utilizada n\u00e3o deve ser implementada. Seguir esse princ\u00edpio ajuda o sistema a permanecer flex\u00edvel e apropriado para refatora\u00e7\u00e3o ao fazer altera\u00e7\u00f5es na l\u00f3gica de opera\u00e7\u00e3o.<\/p>\n

Essa situa\u00e7\u00e3o ocorre com frequ\u00eancia quando a interface cont\u00e9m v\u00e1rias funcionalidades, mas o cliente precisa apenas de uma delas.<\/p>\n

Como a escrita de uma interface \u00e9 uma tarefa complexa, modific\u00e1-la ap\u00f3s a conclus\u00e3o do trabalho, sem quebrar nada, ser\u00e1 problem\u00e1tico.<\/p>\n

A vantagem do princ\u00edpio ISP em Java \u00e9 que primeiro \u00e9 necess\u00e1rio implementar todos os m\u00e9todos, e s\u00f3 ent\u00e3o eles podem ser utilizados pelas classes. Portanto, o princ\u00edpio permite reduzir o n\u00famero de m\u00e9todos.<\/p>\n

\"10
\n <\/p>\n

Programa\u00e7\u00e3o para a interface, n\u00e3o para a implementa\u00e7\u00e3o.<\/h3>\n

\nAqui tudo fica claro pelo nome. A aplica\u00e7\u00e3o deste princ\u00edpio leva \u00e0 cria\u00e7\u00e3o de um c\u00f3digo flex\u00edvel que pode funcionar com qualquer nova implementa\u00e7\u00e3o de interface.<\/p>\n

Deve-se usar o tipo de interface para vari\u00e1veis, tipos de retorno ou o tipo de argumento do m\u00e9todo. Exemplo \u2014 usar SuperClass, e n\u00e3o SubClass.<\/p>\n

Ou seja:<\/p>\n

List numbers= getNumbers();<\/i><\/p>\n

E n\u00e3o:<\/p>\n

ArrayList numbers = getNumbers();<\/i><\/p>\n

Aqui est\u00e1 uma implementa\u00e7\u00e3o pr\u00e1tica do que foi mencionado acima.<\/p>\n

\"10
\n <\/p>\n

Princ\u00edpio de delega\u00e7\u00e3o<\/h3>\n

\nUm exemplo comum s\u00e3o os m\u00e9todos equals() e hashCode() em Java. Quando \u00e9 necess\u00e1rio comparar dois objetos, essa a\u00e7\u00e3o \u00e9 delegada \u00e0 classe correspondente em vez do cliente.<\/p>\n

A vantagem do princ\u00edpio \u00e9 a aus\u00eancia de duplica\u00e7\u00e3o de c\u00f3digo e uma mudan\u00e7a relativamente simples de comportamento. Tamb\u00e9m \u00e9 aplic\u00e1vel \u00e0 delega\u00e7\u00e3o de eventos.<\/p>\n

\"10
\n
\nTodos esses princ\u00edpios permitem escrever um c\u00f3digo mais flex\u00edvel, bonito e confi\u00e1vel, com alta coes\u00e3o e baixo acoplamento. Claro, a teoria \u00e9 boa, mas para que o desenvolvedor realmente comece a usar o conhecimento adquirido, \u00e9 necess\u00e1ria pr\u00e1tica. O pr\u00f3ximo passo ap\u00f3s dominar os princ\u00edpios da OOP pode ser o estudo de padr\u00f5es de design para resolver problemas comuns de desenvolvimento de software.<\/p>\n

A Skillbox recomenda:<\/b><\/p>\n