{"id":34828,"date":"2019-10-31T22:00:38","date_gmt":"2019-10-31T19:00:38","guid":{"rendered":"https:\/\/prohoster.info\/blog\/single-responsibility-principle-ne-takoj-prostoj-kak-kazhetsya\/"},"modified":"2019-10-31T22:00:38","modified_gmt":"2019-10-31T19:00:38","slug":"single-responsibility-principle-ne-takoj-prostoj-kak-kazhetsya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/news\/single-responsibility-principle-ne-takoj-prostoj-kak-kazhetsya","title":{"rendered":"Princ\u00edpio da Responsabilidade \u00danica. N\u00e3o \u00e9 t\u00e3o simples quanto parece.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Princ\u00edpio da Responsabilidade \u00danica. N\u00e3o \u00e9 t\u00e3o simples quanto parece.\" src=\"\/wp-content\/uploads\/2019\/06\/5b253ff55e3c97b6baf5f7a7ae7f3b98.JPG\" style=\"display:block;margin: 0 auto;\" \/> Princ\u00edpio da responsabilidade \u00fanica, tamb\u00e9m conhecido como princ\u00edpio da \u00fanica responsabilidade,<br \/>\ntamb\u00e9m conhecido como princ\u00edpio da \u00fanica mutabilidade \u2014 \u00e9 um conceito bastante escorregadio para entender e uma quest\u00e3o t\u00e3o nervosa em entrevistas para programadores. <\/p>\n<p><\/p>\n<p>O meu primeiro contato s\u00e9rio com esse princ\u00edpio ocorreu no in\u00edcio do primeiro ano da faculdade, quando n\u00f3s, jovens e inexperientes, fomos levados para a floresta para transformar calouros em estudantes de verdade.<\/p>\n<p><\/p>\n<p>Na floresta, fomos divididos em grupos de 8 a 9 pessoas cada e realizamos uma competi\u00e7\u00e3o \u2014 qual grupo consegue beber uma garrafa de vodka mais r\u00e1pido, sob a condi\u00e7\u00e3o de que a primeira pessoa do grupo serve a vodka em um copo, a segunda bebe, e a terceira come algo. O participante que completar sua tarefa vai para o final da fila do grupo. <\/p>\n<p><\/p>\n<p>Um caso em que o tamanho da fila era m\u00faltiplo de tr\u00eas se mostrava uma boa implementa\u00e7\u00e3o do SRP.<\/p>\n<p><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex> <\/p>\n<h2 id=\"opredelenie-1-edinaya-otvetstvennost\">Defini\u00e7\u00e3o 1. Responsabilidade \u00fanica.<\/h2>\n<p><\/p>\n<p>A defini\u00e7\u00e3o oficial do princ\u00edpio da responsabilidade \u00fanica (SRP) afirma que cada objeto possui sua responsabilidade e raz\u00e3o de existir, e essa responsabilidade \u00e9 \u00fanica.<\/p>\n<p><\/p>\n<p>Vamos considerar o objeto &#171;Bebedor&#187; (<strong>Tippler<\/strong>).<br \/>\nPara seguir o princ\u00edpio SRP, vamos dividir as responsabilidades entre tr\u00eas: <\/p>\n<p><\/p>\n<ul>\n<li>Um serve (<strong>PourOperation<\/strong>)<\/li>\n<li>Um bebe (<strong>DrinkUpOperation<\/strong>)<\/li>\n<li>Um come (<strong>TakeBiteOperation<\/strong>)<\/li>\n<\/ul>\n<p><\/p>\n<p>Cada um dos participantes do processo \u00e9 respons\u00e1vel por um componente do processo, ou seja, tem uma responsabilidade at\u00f4mica \u2014 beber, servir ou comer. <\/p>\n<p><\/p>\n<p>O Apreciador de bebidas, por sua vez, \u00e9 um fachada para essas opera\u00e7\u00f5es:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">class Tippler {\n    \/\/...\n    void Act(){\n        _pourOperation.Do() \/\/ serve\n        _drinkUpOperation.Do() \/\/ beber\n        _takeBiteOperation.Do() \/\/ comer\n    }\n}<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Princ\u00edpio da Responsabilidade \u00danica. N\u00e3o \u00e9 t\u00e3o simples quanto parece.\" src=\"\/wp-content\/uploads\/2019\/06\/8d591a474e3555edfee3ffebc28d079b.JPG\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h4 id=\"zachem\">Por qu\u00ea?<\/h4>\n<p><\/p>\n<p>O programador escreve c\u00f3digo para um macaco, e o macaco \u00e9 desatento, burro e est\u00e1 sempre com pressa. Ele pode compreender de 3 a 7 termos ao mesmo tempo.<br \/>\nNo caso do apreciador de bebidas, esses tr\u00eas termos est\u00e3o presentes. No entanto, se escrevermos tudo em um \u00fanico bloco de c\u00f3digo, aparecer\u00e3o bra\u00e7os, copos, brigas e discuss\u00f5es intermin\u00e1veis sobre pol\u00edtica. E tudo isso ficar\u00e1 dentro de um \u00fanico m\u00e9todo. Tenho certeza de que voc\u00ea j\u00e1 viu esse tipo de c\u00f3digo na sua pr\u00e1tica. N\u00e3o \u00e9 um teste muito humanit\u00e1rio para a psique.<\/p>\n<p><\/p>\n<p>Por outro lado, o homem-macaco \u00e9 treinado para modelar objetos do mundo real em sua mente. Em sua imagina\u00e7\u00e3o, ele pode colidir, reunir novos objetos e tamb\u00e9m desmont\u00e1-los. Imagine um antigo modelo de carro. Voc\u00ea pode imaginar abrir a porta, soltar o revestimento da porta e ver os mecanismos do elevador de vidro, onde estar\u00e3o as engrenagens. Mas voc\u00ea n\u00e3o pode ver todos os componentes do carro ao mesmo tempo, em uma \u00fanica &#171;listagem&#187;. Pelo menos, o &#171;homem-macaco&#187; n\u00e3o pode.<\/p>\n<p><\/p>\n<p>Portanto, os programadores humanos decomp\u00f5em mecanismos complexos em um conjunto de elementos menos complexos e funcionais. No entanto, a decomposi\u00e7\u00e3o pode ser feita de diferentes maneiras: em muitos carros antigos - o duto de ar sai pela porta, enquanto nos modernos - uma falha na eletr\u00f4nica da fechadura impede que o motor arranque, o que traz dificuldades na hora do conserto.<\/p>\n<p><\/p>\n<p>Ent\u00e3o, <strong>SRP \u00e9 um princ\u00edpio que explica COMO decomp\u00f4r, ou seja, onde tra\u00e7ar a linha de separa\u00e7\u00e3o.<\/strong>. <\/p>\n<p><\/p>\n<p>Ele diz que a decomposi\u00e7\u00e3o deve ser feita com base no princ\u00edpio da separa\u00e7\u00e3o de &#171;responsabilidades&#187;, ou seja, pela tarefa de determinados objetos.<\/p>\n<p>\n<img decoding=\"async\" alt=\"Princ\u00edpio da Responsabilidade \u00danica. N\u00e3o \u00e9 t\u00e3o simples quanto parece.\" src=\"\/wp-content\/uploads\/2019\/06\/b1980c3dc9742b921eb818f14fe3527e.JPG\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Vamos voltar ao b\u00eabado e aos benef\u00edcios que o homem-macaco obt\u00e9m ao decomp\u00f4r: <\/p>\n<p><\/p>\n<ul>\n<li>O c\u00f3digo se torna extremamente claro em cada n\u00edvel.<\/li>\n<li>O c\u00f3digo pode ser escrito por v\u00e1rios programadores ao mesmo tempo (cada um escreve um elemento separado).<\/li>\n<li>Facilita a automa\u00e7\u00e3o de testes \u2014 quanto mais simples o elemento, mais f\u00e1cil \u00e9 test\u00e1-lo.<\/li>\n<li>Surge a composicionalidade do c\u00f3digo \u2014 \u00e9 poss\u00edvel substituir <strong>DrinkUpOperation<\/strong> por uma opera\u00e7\u00e3o na qual o b\u00eabado derrama l\u00edquido sob a mesa. Ou substituir a opera\u00e7\u00e3o de derramar por uma opera\u00e7\u00e3o onde voc\u00ea mistura vinho e \u00e1gua ou vodka e cerveja. Dependendo dos requisitos de neg\u00f3cios, voc\u00ea pode fazer tudo isso, sem tocar no c\u00f3digo do m\u00e9todo. <strong>Tippler.Act<\/strong>. <\/li>\n<li>A partir dessas opera\u00e7\u00f5es, voc\u00ea pode compor um glut\u00e3o (usando apenas <strong>TakeBitOperation<\/strong>), um alco\u00f3latra (usando apenas <strong>DrinkUpOperation<\/strong> diretamente da garrafa) e atender a muitas outras demandas de neg\u00f3cios.<\/li>\n<\/ul>\n<p><\/p>\n<p><em>(Oops, parece que isso j\u00e1 \u00e9 o princ\u00edpio OCP, e eu violarei a responsabilidade deste post.) <\/em><\/p>\n<p><\/p>\n<p>E, claro, os contras: <\/p>\n<p><\/p>\n<ul>\n<li>Ser\u00e1 necess\u00e1rio criar mais tipos. <\/li>\n<li>O b\u00eabado beber\u00e1 pela primeira vez algumas horas depois do que poderia.<\/li>\n<\/ul>\n<p><\/p>\n<h2 id=\"opredelenie-2-edinaya-izmenchivost\">Defini\u00e7\u00e3o 2. Mudan\u00e7a \u00fanica.<\/h2>\n<p><\/p>\n<p>Senhores, permitam-me! A classe do bebedor tamb\u00e9m desempenha uma \u00fanica responsabilidade \u2014 ela bebe! E, de fato, a palavra &#171;responsabilidade&#187; \u00e9 um conceito extremamente vago. Algu\u00e9m \u00e9 respons\u00e1vel pelo destino da humanidade, enquanto outro \u00e9 respons\u00e1vel por levantar os pinguins que ca\u00edram no p\u00f3lo.<\/p>\n<p><\/p>\n<p>Vamos considerar duas implementa\u00e7\u00f5es do bebedor. A primeira, mencionada acima, cont\u00e9m tr\u00eas classes \u2014 servir, beber e petiscar.<\/p>\n<p><\/p>\n<p>A segunda, escrita atrav\u00e9s da metodologia &#171;Ir em frente e somente em frente&#187; e cont\u00e9m toda a l\u00f3gica no m\u00e9todo <strong>Act<\/strong>:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">\/\/\u041d\u0435 \u0442\u0440\u0430\u0442\u044c\u0442\u0435 \u0432\u0440\u0435\u043c\u044f  \u043d\u0430 \u0438\u0437\u0443\u0447\u0435\u043d\u0438\u0435 \u044d\u0442\u043e\u0433\u043e \u043a\u043b\u0430\u0441\u0441\u0430. \u041b\u0443\u0447\u0448\u0435 \u0441\u044a\u0435\u0448\u044c\u0442\u0435 \u043f\u0435\u0447\u0435\u043d\u044c\u043a\u0443\n\u0441lass BrutTippler {\n   \/\/...\n   void Act(){\n        \/\/ \u043d\u0430\u043b\u0438\u0432\u0430\u0435\u043c\n    if(!_hand.TryDischarge(from:_bottle, to:_glass, size:_glass.Capacity))\n        throw new OverdrunkException();\n\n    \/\/ \u0432\u044b\u043f\u0438\u0432\u0430\u0435\u043c\n    if(!_hand.TryDrink(from: _glass,  size: _glass.Capacity))\n        throw new OverdrunkException();\n\n    \/\/\u0417\u0430\u043a\u0443\u0441\u044b\u0432\u0430\u0435\u043c\n    for(int i = 0; i&lt; 3; i++){\n        var food = _foodStore.TakeOrDefault();\n        if(food==null)\n            throw new FoodIsOverException();\n\n        _hand.TryEat(food);\n    }\n   }\n}<\/code><\/pre>\n<p><\/p>\n<p>Essas duas classes, do ponto de vista de um observador externo, parecem absolutamente id\u00eanticas e desempenham a \u00fanica responsabilidade &#171;beber&#187;. <\/p>\n<p><\/p>\n<p>Confus\u00e3o!<\/p>\n<p><\/p>\n<p>Ent\u00e3o, vamos \u00e0 internet e descobrimos outra defini\u00e7\u00e3o do SRP \u2014 Princ\u00edpio da Responsabilidade \u00danica (Single Responsibility Principle).<\/p>\n<p><\/p>\n<p>O SCP afirma que &#171;<strong>Um m\u00f3dulo tem uma e apenas uma raz\u00e3o para mudar<\/strong>&#171;. Ou seja, &#171;Responsabilidade \u00e9 uma raz\u00e3o para a mudan\u00e7a&#187;. <\/p>\n<p><\/p>\n<p><em>(Parece que os caras que inventaram a defini\u00e7\u00e3o original estavam confiantes nas habilidades telep\u00e1ticas do homem-macaco)<\/em><\/p>\n<p><\/p>\n<p>Agora tudo se encaixa. Podemos alterar separadamente os procedimentos de servir, beber e petiscar, e no pr\u00f3prio bebedor podemos mudar apenas a sequ\u00eancia e a composi\u00e7\u00e3o das opera\u00e7\u00f5es, por exemplo, movendo o petisco antes de beber ou adicionando a leitura de um brinde.<\/p>\n<p><\/p>\n<p>Na abordagem &#171;Ir em frente e somente em frente&#187;, tudo que pode ser mudado \u2014 \u00e9 alterado apenas no m\u00e9todo <strong>Act<\/strong>. Isso pode ser leg\u00edvel e eficiente quando a l\u00f3gica \u00e9 pouca e muda raramente, mas muitas vezes acaba resultando em m\u00e9todos horr\u00edveis de 500 linhas cada, com mais ifs do que o necess\u00e1rio para a entrada da R\u00fassia na OTAN. <\/p>\n<p><\/p>\n<h2 id=\"opredelenie-3-lokalizaciya-izmeneniy\">Defini\u00e7\u00e3o 3. Localiza\u00e7\u00e3o de mudan\u00e7as.<\/h2>\n<p><\/p>\n<p>Os bebedores frequentemente n\u00e3o entendem por que acordaram em um apartamento estranho, ou onde est\u00e1 seu celular. Chegou a hora de adicionar um detalhamento de log.<\/p>\n<p><\/p>\n<p>Vamos come\u00e7ar o log com o processo de servir:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">class PourOperation: IOperation{\n    PourOperation(ILogger log \/*....*\/){\/*...*\/}\n    \/\/...\n    void Do(){\n        _log.Log($\"Antes de servir com {_hand} e {_bottle}\");\n        \/\/L\u00f3gica de neg\u00f3cios do servir ...\n        _log.Log($\"Depois de servir com {_hand} e {_bottle}\");\n    }\n}<\/code><\/pre>\n<p><\/p>\n<p>Encapsulando-a em <strong>PourOperation<\/strong>, agimos sabiamente em termos de responsabilidade e encapsulamento, mas agora temos um impasse com o princ\u00edpio da variabilidade. Al\u00e9m da pr\u00f3pria opera\u00e7\u00e3o, que pode mudar, a pr\u00f3pria logagem tamb\u00e9m se torna variada. Teremos que separar e criar um logador especial para a opera\u00e7\u00e3o de derramamento:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">interface IPourLogger{\n    void LogBefore(IHand, IBottle){}\n    void LogAfter(IHand, IBottle){}\n    void OnError(IHand, IBottle, Exception){}\n}\n\nclass PourOperation: IOperation{\n    PourOperation(IPourLogger log \/*....*\/){\/*...*\/}\n    \/\/...\n    void Do(){\n        _log.LogBefore(_hand, _bottle);\n        try{\n             \/\/... l\u00f3gica de neg\u00f3cios\n             _log.LogAfter(_hand, _bottle);\n        }\n        catch(exception e){\n            _log.OnError(_hand, _bottle, e);\n        }\n    }\n}<\/code><\/pre>\n<p><\/p>\n<p>Um leitor atento notar\u00e1 que <strong>LogAfter<\/strong>, <strong>LogBefore<\/strong> e <strong>OnError<\/strong> tamb\u00e9m podem mudar separadamente e, seguindo a l\u00f3gica das a\u00e7\u00f5es anteriores, criar\u00e1 tr\u00eas classes: <strong>PourLoggerBefore<\/strong>, <strong>PourLoggerAfter<\/strong> e <strong>PourErrorLogger<\/strong>.<\/p>\n<p><\/p>\n<p>E lembrando que h\u00e1 tr\u00eas opera\u00e7\u00f5es para o bebedor \u2014 obtemos nove classes de logagem. No final, todo o bebedor consiste em 14 (!!!) classes.<\/p>\n<p><\/p>\n<p>Hip\u00e9rbole? Dificilmente! O homem-macaco com a granada de decomposi\u00e7\u00e3o desmembrar\u00e1 o 'derramador' em jarra, copo, operadores de derramamento, servi\u00e7o de fornecimento de \u00e1gua, modelo f\u00edsico de colis\u00e3o de mol\u00e9culas, e no pr\u00f3ximo trimestre tentar\u00e1 desvendar as depend\u00eancias sem vari\u00e1veis globais. E acredite \u2014 ele n\u00e3o vai parar.<\/p>\n<p><\/p>\n<p>Nesse momento, muitos chegam \u00e0 conclus\u00e3o de que o SRP s\u00e3o contos de fadas de reinos cor-de-rosa e v\u00e3o se distrair...<\/p>\n<p><\/p>\n<p>\u2026 sem nunca saber da exist\u00eancia da terceira defini\u00e7\u00e3o de SRP: <\/p>\n<p><\/p>\n<p>&#171;O princ\u00edpio da responsabilidade \u00fanica afirma que <strong>coisas que s\u00e3o semelhantes para modifica\u00e7\u00e3o devem ser mantidas em um s\u00f3 lugar<\/strong>&#171;. ou \u201c<strong>O que muda junto deve ser mantido em um s\u00f3 lugar<\/strong>\u201d<\/p>\n<p><\/p>\n<p>Ou seja, se mudamos a logagem da opera\u00e7\u00e3o, devemos mud\u00e1-la em um s\u00f3 lugar.<\/p>\n<p><\/p>\n<p>Esse \u00e9 um ponto muito importante \u2014 j\u00e1 que todas as explica\u00e7\u00f5es do SRP, que foram feitas anteriormente, falavam sobre a necessidade de fracionar tipos at\u00e9 que eles se fracionem, ou seja, imp\u00f5em um &#171;limite superior&#187; sobre o tamanho do objeto, e agora estamos falando tamb\u00e9m sobre um &#171;limite inferior&#187;. Em outras palavras, <strong>O SRP n\u00e3o s\u00f3 exige &#171;fracionar at\u00e9 que fracione&#187;, mas tamb\u00e9m n\u00e3o exagerar \u2014 &#171;n\u00e3o fragmentar coisas interligadas&#187;<\/strong>. Esta \u00e9 uma grande batalha entre a navalha de Occam e o homem-macaco!<\/p>\n<p>\n<img decoding=\"async\" alt=\"Princ\u00edpio da Responsabilidade \u00danica. N\u00e3o \u00e9 t\u00e3o simples quanto parece.\" src=\"\/wp-content\/uploads\/2019\/06\/2e349a5b119a511d716341f3f6725844.JPG\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>Agora deve ser mais f\u00e1cil para o bebedor. Al\u00e9m de n\u00e3o precisar dividir o logador IPourLogger em tr\u00eas classes, tamb\u00e9m podemos unir todos os logadores em um \u00fanico tipo:<\/p>\n<p><\/p>\n<pre><code class=\"plaintext\">class OperationLogger{\n    public OperationLogger(string operationName){\n\/*..*\/}\n    public void LogBefore(object[] args){\n\/*...*\/}\n    public void LogAfter(object[] args){\n\/*..*\/}\n    public void LogError(object[] args, exception e){\n\/*..*\/}\n}<\/code><\/pre>\n<p><\/p>\n<p>E se adicionarmos um quarto tipo de opera\u00e7\u00e3o, a loga\u00e7\u00e3o para ele j\u00e1 estar\u00e1 pronta. O c\u00f3digo das opera\u00e7\u00f5es em si \u00e9 limpo e livre de ru\u00eddos de infraestrutura.<\/p>\n<p><\/p>\n<p>Como resultado, temos 5 classes para resolver a tarefa de consumo:<\/p>\n<p><\/p>\n<ul>\n<li>Opera\u00e7\u00e3o de enchimento<\/li>\n<li>Opera\u00e7\u00e3o de consumo<\/li>\n<li>Opera\u00e7\u00e3o de acompanhamento<\/li>\n<li>Logger<\/li>\n<li>Facade de bebedor<\/li>\n<\/ul>\n<p><\/p>\n<p>Cada uma delas \u00e9 respons\u00e1vel estritamente por uma funcionalidade, tendo uma \u00fanica raz\u00e3o para mudan\u00e7a. Todas as regras semelhantes para altera\u00e7\u00e3o est\u00e3o pr\u00f3ximas. <\/p>\n<p>\n<b class=\"spoiler_title\">Exemplo da vida real<\/b><\/p>\n<p>Certa vez, est\u00e1vamos escrevendo um servi\u00e7o de registro autom\u00e1tico de cliente b2b. E surgiu um m\u00e9todo GOD com 200 linhas de conte\u00fado semelhante:<\/p>\n<p><\/p>\n<ul>\n<li>V\u00e1 ao 1C e crie uma conta<\/li>\n<li>Com essa conta, v\u00e1 ao m\u00f3dulo de pagamentos e crie-a l\u00e1<\/li>\n<li>Verifique se a conta com essa numera\u00e7\u00e3o n\u00e3o foi criada no principal <a class=\"wpil_keyword_link\" href=\"https:\/\/prohoster.info\/pt\/server\/dts-dronten\/\"   title=\"servidor\" data-wpil-keyword-link=\"linked\"  data-wpil-monitor-id=\"2485\">servidor<\/a><\/li>\n<li>Crie uma nova conta<\/li>\n<li>Adicione o resultado do registro no m\u00f3dulo de pagamentos e o n\u00famero do 1C ao servi\u00e7o de resultados do registro<\/li>\n<li>Adicione \u00e0 tabela a informa\u00e7\u00e3o da conta<\/li>\n<li>Crie um n\u00famero de ponto para este cliente no servi\u00e7o de pontos. Passe o n\u00famero da conta 1C para este servi\u00e7o.<\/li>\n<\/ul>\n<p><\/p>\n<p>E havia cerca de 10 opera\u00e7\u00f5es de neg\u00f3cios com uma interconex\u00e3o terr\u00edvel nesta lista. O objeto da conta era necess\u00e1rio para quase todos. O identificador do ponto e o nome do cliente eram necess\u00e1rios em metade das chamadas.<\/p>\n<p><\/p>\n<p>Depois de uma hora de refatora\u00e7\u00e3o, conseguimos separar o c\u00f3digo de infraestrutura e alguns detalhes do trabalho com a conta em m\u00e9todos\/classes separados. O m\u00e9todo God ficou mais leve, mas ainda restavam 100 linhas de c\u00f3digo que n\u00e3o queriam se desenrolar. <\/p>\n<p><\/p>\n<p>Apenas alguns dias depois, veio a compreens\u00e3o de que a ess\u00eancia desse m\u00e9todo &#171;aliviado&#187; \u2014 \u00e9 um algoritmo de neg\u00f3cios. E que a descri\u00e7\u00e3o inicial do TSK era bastante complicada. E precisamente a tentativa de dividir esse m\u00e9todo em partes ser\u00e1 uma viola\u00e7\u00e3o do SRP, e n\u00e3o o contr\u00e1rio. <\/p>\n<p><\/p>\n<h2 id=\"formalizm\">Formalismo.<\/h2>\n<p><\/p>\n<p>Chegou a hora de deixar nosso bebedor em paz. Seque as l\u00e1grimas \u2014 certamente voltaremos a ele algum dia. Mas agora formalizemos os conhecimentos deste artigo. <\/p>\n<p><\/p>\n<h4 id=\"formalizm-1-opredelenie-srp\">Formalismo 1. Defini\u00e7\u00e3o do SRP<\/h4>\n<p><\/p>\n<ol>\n<li>Separe os elementos de modo que cada um deles tenha uma \u00fanica responsabilidade.<\/li>\n<li>Responsabilidade \u00e9 interpretada como \"motivo para mudan\u00e7a\". Isso significa que cada elemento tem apenas um motivo para mudan\u00e7a, em termos de l\u00f3gica de neg\u00f3cios.<\/li>\n<li>Mudan\u00e7as potenciais na l\u00f3gica de neg\u00f3cios devem ser localizadas. Elementos alter\u00e1veis em sincronia devem estar pr\u00f3ximos.<\/li>\n<\/ol>\n<p><\/p>\n<h4 id=\"formalizm-2-neobhodimye-kriterii-samoproverki\">Formalismo 2. Crit\u00e9rios necess\u00e1rios de autoavalia\u00e7\u00e3o.<\/h4>\n<p><\/p>\n<p>N\u00e3o encontrei crit\u00e9rios suficientes para cumprir o SRP. Mas h\u00e1 condi\u00e7\u00f5es necess\u00e1rias:<\/p>\n<p><\/p>\n<p>1) Pergunte a si mesmo \u2014 o que faz esta classe\/m\u00e9todo\/m\u00f3dulo\/servi\u00e7o. Voc\u00ea deve responder com uma defini\u00e7\u00e3o simples. (Obrigado) <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/users\/brightori\/\" class=\"user_link\">Brightori<\/a><\/noindex> )<\/p>\n<p>\n<b class=\"spoiler_title\">explica\u00e7\u00f5es<\/b><\/p>\n<p>No entanto, \u00e0s vezes \u00e9 muito dif\u00edcil encontrar uma defini\u00e7\u00e3o simples <\/p>\n<p><\/p>\n<p>2) A corre\u00e7\u00e3o de um certo bug ou a adi\u00e7\u00e3o de uma nova funcionalidade deve afetar o m\u00ednimo de arquivos\/classes. Idealmente \u2014 um. <\/p>\n<p>\n<b class=\"spoiler_title\">explica\u00e7\u00f5es<\/b><\/p>\n<p>Como a responsabilidade (por uma funcionalidade ou bug) est\u00e1 encapsulada em um \u00fanico arquivo\/classe, voc\u00ea sabe exatamente onde procurar e o que corrigir. Por exemplo: a funcionalidade de mudar a sa\u00edda do registro de opera\u00e7\u00f5es exigir\u00e1 a mudan\u00e7a apenas do registrador. N\u00e3o \u00e9 necess\u00e1rio percorrer todo o restante do c\u00f3digo. <\/p>\n<p><\/p>\n<p>Outro exemplo \u2014 adicionar um novo controle de UI, similar aos anteriores. Se isso faz voc\u00ea adicionar 10 entidades diferentes e 15 conversores diferentes \u2014 parece que voc\u00ea \u201covercomplicou\u201d.<\/p>\n<p><\/p>\n<p>3) Se v\u00e1rios desenvolvedores est\u00e3o trabalhando em funcionalidades diferentes do seu projeto, a probabilidade de um conflito de merge, ou seja, a probabilidade de que um mesmo arquivo\/classe seja alterado por v\u00e1rios desenvolvedores ao mesmo tempo \u2014 \u00e9 m\u00ednima.<\/p>\n<p>\n<b class=\"spoiler_title\">explica\u00e7\u00f5es<\/b><\/p>\n<p>Se ao adicionar uma nova opera\u00e7\u00e3o \"Despejar vodka embaixo da mesa\" voc\u00ea precisa envolver o registrador, a opera\u00e7\u00e3o de beber e despejar \u2014 ent\u00e3o parece que as responsabilidades est\u00e3o divididas de maneira inadequada. Certamente, isso nem sempre \u00e9 poss\u00edvel, mas deve-se tentar reduzir esse indicador. <\/p>\n<p><\/p>\n<p>4) Ao fazer uma pergunta esclarecedora sobre a l\u00f3gica de neg\u00f3cios (de um desenvolvedor ou gerente), voc\u00ea vai diretamente a uma \u00fanica classe\/arquivo e obt\u00e9m informa\u00e7\u00f5es apenas dali.<\/p>\n<p>\n<b class=\"spoiler_title\">explica\u00e7\u00f5es<\/b><\/p>\n<p>Funcionalidades, regras ou algoritmos est\u00e3o compactamente escritos, cada um em um \u00fanico lugar, e n\u00e3o espalhados como flags por todo o c\u00f3digo.<\/p>\n<p><\/p>\n<p>5) A nomea\u00e7\u00e3o \u00e9 clara.<\/p>\n<p>\n<b class=\"spoiler_title\">explica\u00e7\u00f5es<\/b><\/p>\n<p>Nossa classe ou m\u00e9todo \u00e9 respons\u00e1vel por algo \u00fanico, e essa responsabilidade \u00e9 refletida em seu nome.<\/p>\n<p><\/p>\n<p>AllManagersManagerService \u2014 provavelmente, uma classe Deus.<br \/>\nLocalPayment \u2014 provavelmente, n\u00e3o. <\/p>\n<p><\/p>\n<h4 id=\"formalizm-3-metodika-razrabotki-okkama-first\">Formalismo 3. Metodologia de desenvolvimento \"O m\u00e9todo de Ockham primeiro\".<\/h4>\n<p><\/p>\n<p>No in\u00edcio do projeto, o homem-macaco n\u00e3o conhece nem sente todas as sutilezas da tarefa em quest\u00e3o e pode cometer um erro. Existem v\u00e1rias maneiras de errar:<\/p>\n<p><\/p>\n<ul>\n<li>Criar objetos excessivamente grandes, unindo diferentes responsabilidades<\/li>\n<li>Fracionar, dividindo uma \u00fanica responsabilidade em muitos tipos diferentes<\/li>\n<li>Definir incorretamente os limites de responsabilidades<\/li>\n<\/ul>\n<p><\/p>\n<p>\u00c9 importante lembrar a regra: \"errar \u00e9 melhor em maior grau\", ou \"se n\u00e3o tem certeza \u2014 n\u00e3o divida\". Por exemplo, se sua classe acumula duas responsabilidades \u2014 ela ainda \u00e9 compreens\u00edvel e pode ser dividida em duas com a m\u00ednima altera\u00e7\u00e3o no c\u00f3digo do cliente. Reunir um copo de fragmentos de vidro, geralmente \u00e9 mais dif\u00edcil devido ao contexto espalhado por v\u00e1rios arquivos e \u00e0 falta de depend\u00eancias necess\u00e1rias no c\u00f3digo do cliente. <\/p>\n<p><\/p>\n<h2 id=\"pora-zakruglyatsya\">Hora de concluir<\/h2>\n<p><\/p>\n<p>O escopo de aplica\u00e7\u00e3o do SRP n\u00e3o se limita \u00e0 OOP e SOLID. Ele se aplica a m\u00e9todos, fun\u00e7\u00f5es, classes, m\u00f3dulos, microsservi\u00e7os e servi\u00e7os. Ele \u00e9 aplic\u00e1vel tanto em desenvolvimento \"simples e direto\" quanto em \"ci\u00eancia de foguetes\", tornando o mundo um pouquinho melhor em todos os lugares. Ao refletir, isso \u00e9 quase um princ\u00edpio fundamental de toda a engenharia. Engenharia mec\u00e2nica, sistemas de controle, e de fato, todos os sistemas complexos \u2014 s\u00e3o constru\u00eddos a partir de componentes, e a \u2018n\u00e3o fracionamento\u2019 priva os engenheiros de flexibilidade, a \u2018fracionamento\u2019 \u2014 de efici\u00eancia, e limites incorretos \u2014 de l\u00f3gica e paz de esp\u00edrito. <\/p>\n<p>\n<img decoding=\"async\" alt=\"Princ\u00edpio da Responsabilidade \u00danica. N\u00e3o \u00e9 t\u00e3o simples quanto parece.\" src=\"\/wp-content\/uploads\/2019\/06\/b70fb2b0b87cf90d41462263e839902b.JPG\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<p>O SRP n\u00e3o foi inventado pela natureza e n\u00e3o \u00e9 parte de uma ci\u00eancia exata. Ele emerge das nossas limita\u00e7\u00f5es biol\u00f3gicas e psicol\u00f3gicas. \u00c9 apenas uma forma de controlar e desenvolver sistemas complexos usando a mente humana-macaco. Ele nos ensina como decompor um sistema. A formula\u00e7\u00e3o original exigia consider\u00e1vel habilidade de telepatia, mas espero que este artigo tenha ajudado a dissipar um pouco da n\u00e9voa.<\/p>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/454290\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>Single responsibility principle, \u043e\u043d \u0436\u0435 \u043f\u0440\u0438\u043d\u0446\u0438\u043f \u0435\u0434\u0438\u043d\u043e\u0439 \u043e\u0442\u0432\u0435\u0442\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0441\u0442\u0438, \u043e\u043d \u0436\u0435 \u043f\u0440\u0438\u043d\u0446\u0438\u043f \u0435\u0434\u0438\u043d\u043e\u0439 \u0438\u0437\u043c\u0435\u043d\u0447\u0438\u0432\u043e\u0441\u0442\u0438 \u2014 \u043a\u0440\u0430\u0439\u043d\u0435 \u0441\u043a\u043e\u043b\u044c\u0437\u043a\u0438\u0439 \u0434\u043b\u044f \u043f\u043e\u043d\u0438\u043c\u0430\u043d\u0438\u044f \u043f\u0430\u0440\u0435\u043d\u044c \u0438 \u0441\u0442\u043e\u043b\u044c \u043d\u0435\u0440\u0432\u043e\u0437\u043d\u044b\u0439 \u0432\u043e\u043f\u0440\u043e\u0441 \u043d\u0430 \u0441\u043e\u0431\u0435\u0441\u0435\u0434\u043e\u0432\u0430\u043d\u0438\u0438 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u0438\u0441\u0442\u0430. \u041f\u0435\u0440\u0432\u043e\u0435 \u0441\u0435\u0440\u044c\u0435\u0437\u043d\u043e\u0435 \u0437\u043d\u0430\u043a\u043e\u043c\u0441\u0442\u0432\u043e \u0441 \u044d\u0442\u0438\u043c \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u043e\u043c \u0441\u043e\u0441\u0442\u043e\u044f\u043b\u043e\u0441\u044c \u0434\u043b\u044f \u043c\u0435\u043d\u044f \u0432 \u043d\u0430\u0447\u0430\u043b\u0435 \u043f\u0435\u0440\u0432\u043e\u0433\u043e \u043a\u0443\u0440\u0441\u0430, \u043a\u043e\u0433\u0434\u0430 \u043c\u043e\u043b\u043e\u0434\u044b\u0445 \u0438 \u0437\u0435\u043b\u0435\u043d\u044b\u0445 \u043d\u0430\u0441 \u0432\u044b\u0432\u0435\u0437\u043b\u0438 \u0432 \u043b\u0435\u0441, \u0447\u0442\u043e\u0431\u044b \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u0438\u0437 \u043b\u0438\u0447\u0438\u043d\u043e\u043a \u0441\u0442\u0443\u0434\u0435\u043d\u0442\u043e\u0432 \u2014 \u0441\u0442\u0443\u0434\u0435\u043d\u0442\u043e\u0432 \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0438\u0445. [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26229,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[702],"tags":[],"class_list":["post-34828","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-news"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/pt\/blog\/news\/single-responsibility-principle-ne-takoj-prostoj-kak-kazhetsya\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"pt_PT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Single Responsibility Principle. \u041d\u0435 \u0442\u0430\u043a\u043e\u0439 \u043f\u0440\u043e\u0441\u0442\u043e\u0439, \u043a\u0430\u043a \u043a\u0430\u0436\u0435\u0442\u0441\u044f | ProHoster\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/pt\/blog\/news\/single-responsibility-principle-ne-takoj-prostoj-kak-kazhetsya\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T19:00:38+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T19:00:38+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Single Responsibility Principle. N\u00e3o t\u00e3o simples quanto parece | ProHoster","description":"","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/news\/single-responsibility-principle-ne-takoj-prostoj-kak-kazhetsya","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Single Responsibility Principle. \u041d\u0435 \u0442\u0430\u043a\u043e\u0439 \u043f\u0440\u043e\u0441\u0442\u043e\u0439, \u043a\u0430\u043a \u043a\u0430\u0436\u0435\u0442\u0441\u044f | ProHoster","og:url":"https:\/\/prohoster.info\/pt\/blog\/news\/single-responsibility-principle-ne-takoj-prostoj-kak-kazhetsya","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:00:38+00:00","article:modified_time":"2019-10-31T19:00:38+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"34828","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-09 21:46:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:14:06","updated":"2026-02-09 21:46:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/34828","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=34828"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/34828\/revisions"}],"predecessor-version":[{"id":159767,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/34828\/revisions\/159767"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/26229"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=34828"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=34828"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=34828"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}