Artigo escrito anteriormente no meu linkedin
Há mais de 10 anos atrás, a operadora Oi entrava no nosso mercado de telefonia celular. Já tínhamos a Vivo e a TIM (e a Nextel com seus aparelhos de beeps irritantes, ao menos pra mim). E a Oi surge nesse cenário como mais uma companhia querendo ganhar dinheiro com nossas ligações. Usavam (e até hoje devem usar) crianças bonitinhas dizendo "oi" no final dos comerciais.
Por falar em comerciais, alguns anos depois de sua inauguração, eles lançaram uma campanha no rádio e na TV que me chamou a atenção. E não, não estava a fim de ser mais um cliente deles. Era uma propaganda engraçada, que fazia referência ao fato de que poucas pessoas no Brasil realizavam ligações, embora os celulares sempre tivessem essa funcionalidade. Não é que a gente não sabia que podia fazer ligações. É que o minuto de ligação de celular na época era muito caro, e não tínhamos What's App ou Telegram. No máximo um bom serviço de SMS (que também era caro). A ideia era diminuir os custos das ligações por meio de compra de créditos de recarga e outras coisas mais.
O que importa no caso era o slogan da propaganda, que era mais ou menos assim:
Utilize um chip Oi e torne-se um LIGADOR!
A propaganda era engraçada, e pra quem viveu essa época, fica mais ainda, até por imaginar o contexto que ela foi criada, e como as coisas estão hoje. Veja o vídeo aqui.
Mas vamos ao que interessa!
Na época, eu já tinha alguns anos de estrada como desenvolvedor, e estava fazendo minha pós graduação em engenharia de software. Então, modelagem de sistemas estava na minha mente o tempo todo. E a mensagem acima acabou por ficar na minha cabeça.
Ao modelar a situação do cliente das operadoras de celular, cheguei no seguinte diagrama:
E, ao aderir aos planos da Oi, a "modelagem" passaria a ser assim:
Embora esse exemplo possa ser engraçado (até hoje o utilizo em algumas aulas como uma piada) foi uma época onde percebi a importância de uma boa modelagem de software. Foi um momento onde estava fazendo uma transição de "programador-que-conhece-todos-os-frameworks-da-moda" para um profissional que passou a se preocupar mais com o código que escrevia. Passei a entender que as linguagens e frameworks são importantes, mas uma boa organização de código é o que mantém o sistema vivo por mais tempo, causando menos gastos para a empresa, e menos dores de cabeça para os desenvolvedores.
Mas o que diabos isso tem a ver com o pix saque e o pix troco?
Recentemente fui pesquisar, do ponto de vista do cliente, como funciona essas modalidades de pix, por pura curiosidade. O pix saque foi o que me chamou mais atenção, e já explico os motivos.
Há diversos links na internet que explicam como o processo funciona, mas basicamente (no pix saque) é possível que você, como pessoa física e com conta em banco, realize saques em dinheiro em qualquer estabelecimento comercial que tenha aderido à modalidade. É como se os estabelecimentos comerciais se transformassem em caixas eletrônicos.
Mas espere! Os links acima até se referem a caixas eletrônicos. Mas eles também se referem a outro termo: o agente de saque. E, pelo que entendi, é como os estabelecimentos comerciais que aderiram ao pix saque estão sendo chamados pelo banco central. Eles, inclusive, serão remunerados por cada saque realizado.
Bem, podemos dizer que, até outro dia, se a gente precisasse sacar dinheiro para comprar algo num estabelecimento comercial, tínhamos que ir até o caixa eletrônico. Então, podemos pensar numa modelagem mais ou menos assim:
(Para quem conhece UML a fundo, desculpe se estou cometendo algum pecado imperdoável :D)
Eu poderia ter mapeado o relacionamento entre Pessoa e as demais classes de forma invertida. Mas, para os nossos propósitos neste artigo, vamos deixar assim.
Com o advento do pix saque, podemos também sacar diretamente no estabelecimento comercial. Então, podemos até escolher onde queremos realizar o saque!
Nesse caso, a modelagem OO nos ensina que há uma abstração comum às abstrações EstabelecimentoComercial e CaixaEletronico: o AgenteDeSaque:
Modelei o AgenteDeSaque como uma interface, mas ele poderia ser também uma classe abstrata. Poderíamos inclusive implementar um template method caso AgenteDeSaque fosse assim.
Há também uma refatoração a ser feita aqui: a Pessoa agora pode sacar dinheiro num AgenteDeSaque, independente de quem ele seja:
Deu até para colocar o EstabelecimentoComercial mais perto da Pessoa. Afinal, quem não vai querer ter um lugar como esse por perto? :D
E com isso terminamos o exemplo utilizando o pix saque. Não sei se o banco central considera os caixas eletrônicos como agentes de saque. Também não faço ideia se os sistemas foram modelados ou refatorados da forma sugerida acima (embora seria interessante que decisões semelhantes a essas tenham sido tomadas). Só quis mostrar o que modelei na minha cabeça quando entendi como funcionava o pix saque. No fim, me ajudou a entender melhor todo os agentes envolvidos no processo e como ele seria implementado.
É possível também realizar uma refatoração na classe Pessoa. Atualmente, ela é capaz de realizar saques e fazer compras. Mas, e se tivermos que considerar outros agentes além de pessoas que possam executar essas funcionalidades? Podemos pensar que, do ponto de vista bancário, o sistema não deveria lidar como pessoas, mas com correntistas, e o estabelecimento, com clientes.
Isso parece com o princípio de segregação de interfaces. Mas aí é papo para outro artigo :)
Até a próxima!
Top comments (0)