The Godclass

Quando falamos sobre design em orientação a objetos, estamos basicamente falando sobre responsabilidade e relacionamento. Com responsabilidade quero dizer algo que alguma coisa faz e com relacionamento quero dizer como alguma coisa utiliza aquilo que outra coisa faz. O Design de Software Orientado a Objetos trata especificamente da forma com que os objetos se relacionam, ou seja, como expor a responsabilidade dos objetos de forma que outros objetos possam se relacionar.

Do ponto de vista do Design de Software Orientado a Objetos, não importa, exatamente, como alguma coisa é feita. Pelo contrário, o objetivo é justamente evitar esse conhecimento sobre a implementação, encapsulando o que é específico para permitir que trabalhemos com a definição conceitual daquilo que precisamos utilizar. Por exemplo, é comum uma aplicação precisar trabalhar com um SGBD. Se nossos objetos tiverem conhecimento específico de que estamos, na verdade, trabalhando com MySQL, então é provável que os comportamentos relacionados a esse SGBD influenciem o comportamento de nossos objetos - Isso, do ponto de vista de design, é ruim.

Grande parte do design orientado a objetos envolve API, ou seja, a forma com que expomos as responsabilidades. API significa interface que, por sua vez, significa aquilo que vemos e podemos trabalhar com. O grande porém, é podemos ter APIs públicas e APIs privadas do ponto de vista do objeto referencial. Voltando ao exemplo do SGBD, as questões específicas referentes à conexão, são irrelevantes para objetos de alto nível, que vão apenas consumir a base. Porém, questões como essas podem ser altamente relevantes para objetos de baixo nível, se estivermos desenvolvendo algo como a PDO, do PHP, que abstrai a comunicação com vários SGBDs relacionais.

Tipos de APIs

Algumas tecnologias permitem a elaboração dessas APIs de forma diferente, como friend class em C++, protected class em Java, etc. Mas independentemente da forma como é construída, existem três tipos de APIs:

API pública

Objetos de alto nível não devem ter conhecimentos sobre as responsabilidades dos objetos de baixo nível. Quanto mais conhecimento os objetos de alto nível tiverem sobre os de baixo nível, mais complexo será manutenção desse código. A API pública deve ser a mais refinada e abstrata possível. Ao definir essa API, devemos pensar no conceito que o objeto representa.

Como exemplo de refinamento conceitual, a PDO do PHP é um excelente exemplo, pois permite que utilizemos os mesmos métodos de interface, independentemente do SGBD que estamos trabalhando.

API protegida

A API protegida é, ao mesmo tempo, pública e privada, dependendo do referencial. Internamente, para os objetos que fazem parte da hierarquia, essa API é pública. Assim, métodos com responsabilidade de baixo nível são acessíveis, permitindo que reutilizemos código comum para aquela responsabilidade. Por exemplo, se mais do que um SGBD possuir uma forma comum para estabelecer conexão, então o método de conexão pode ser protegido.

API privada

A API privada é visível apenas para o objeto que a define. Isso significa que a responsabilidade dos métodos que compõem essa API são tão específicos para aquela implementação, que não devem ser expostos. Isso chama-se encapsulamento e é extremamente para garantir a abstração.

Violação do encapsulamento

A exposição de uma API privada para um participante que não deveria ter conhecimento sobre ela, viola o encapsulamento, que viola a abstração ao permitir conhecimento específico sobre a implementação. É claro que você, como um desenvolvedor responsável, dirá que tomará cuidado com esse conhecimento. Mas o fato é que muito provavelmente o conhecimento específico afetará seu código e, se isso ocorrer, você terá problemas se precisar variar o participante que detém determinada responsabilidade.

Conclusão

Não, você não está ficando maluco e sim, estou começando o texto pelo fim. Por um lado, começar pelo fim é bom, pois evita desentendimentos sobre aquilo que quero dizer. Por outro lado é mau, pois como posso concluir um texto, se nem comecei a escrevê-lo?

Pode parecer estranho, concordo, mas é assim que tenho visto muita gente fazer em relação ao desenvolvimento de software. Começam a estudar um framework, antes de compreender o funcionamento de determinada linguagem. Utilizar framerowks é bom? É óbvio que é, mas apenas quando se conhece antes, a linguagem que vai ser utilizada.

Que tipo de desenvolvedor é você?

Você é um desenvolvedor Rails, ou um desenvolvedor Ruby que também conhece um framework? Você é um desenvolvedor jQuery, ou um desenvolvedor Javascript que também conhece um framework? Um desenvolvedor Laravel, ou um desenvolvedor PHP que também conhece um framework?

A diferença é bastante simples: O desenvolvedor que conhece a linguagem, antes de conhecer um framework, saberá como trabalhar com o framework X, Y ou Z, mas também saberá quando o framework não resolve seu problema. Saberá escolher um framework adequado para seu caso de uso e, principalmente, saberá identificar as limitações do framework e lidar com essas limitações. Seja estendendo-o, através da adição de novos recursos, ou utilizando compartimentos, que encapsulam o problema que precisa ser resolvido, utilizando essa abstração com a interface do framework.

Quando o desenvolvedor conhece apenas o framework, ele não é capaz de fazer isso. Pelo contrário, ele vai tentar adaptar a ferramenta ao problema. Seria como se tivéssemos um parafuso e o profissional soubesse apenas como utilizar um martelo. Em vez de procurar a ferramenta adequada, ele vai martelar o parafuso até descobrir que não vai dar certo, ou causar um problema maior que o inicial.

É indiscutível que os frameworks facilitam as coisas. Não há argumentos que possam comprovar o contrário. Porém, essas mesmas facilidades trazidas pelos frameworks, estão limitando os desenvolvedores mais jovens.

Tenho visto pessoas perguntando como fazer operações aritméticas simples, como uma soma, utilizando jQuery. Ainda, tenho visto pessoas perguntando sobre como fazer X ou Y em Java, deixando claro que estão utilizando jQuery – Sim, a pessoa não compreendeu sequer que Java e Javascript são duas coisas distintas, pois, segundo seu ponto de vista, está programando em jQuery.

Os casos desse tipo tem se tornado cada vez mais comuns e, na grande maioria das vezes, o desenvolvedor domina tanto um framework, que as limitações do framework se tornaram as limitações do próprio desenvolvedor.

Muitas vezes as pessoas alegam que o mercado é o responsável por isso. Dizem que, por causa do sistema de competição, da necessidade de inovação rápida, não há tempo hábil para se começar a estudar a linguagem antes do framework.

Muitas empresas, ditas “startups”, têm incentivado aos desenvolvedores mais novos para que comecem logo a estudar um framework, para que possam produzir rapidamente e, assim, entregar os produtos na velocidade que a startup precisa para sobreviver no mercado. Esse movimento de incentivo ao uso de frameworks de forma precipitada, tem formado máquinas reutilizáveis, mas incapazes de pensar em soluções. Esse movimento está estragando os desenvolvedores mais novos.

Sinceramente, acredito que o tema framework deveria ser matéria proibida para os desenvolvedores mais novos. De fato, acredito que, se o desenvolvedor for incapaz de desenvolver alguma coisa sem utilizar um framework, então ele não deve utilizar um framework. Obviamente, esse desenvolvedor não deveria sequer ser responsável pelo projeto, mas ai já é outra história.

Enfim, vou deixar uma citação que gosto muito. É de Albert Einstein:

Não basta ensinar ao homem uma especialidade, Porque ele se tornará assim uma máquina utilizável, mas não uma personalidade. É necessário que ele adquira um sentimento, um senso prático daquilo que vale a pena ser empreendido, daquilo que é belo, do que é moralmente correto. A não ser assim, ele se assemelhará, com seus conhecimentos profissionais, mais a um cão ensinado do que a uma criatura harmoniosamente desenvolvida. Deve aprender a compreender as motivações dos homens, suas quimeras e suas angústias para determinar com exatidão seu lugar exato em relação a seus próximos e à comunidade.

Essas reflexões essenciais, comunicadas à jovem geração graças aos contatos vivos com os professores, de forma alguma se encontram escritas nos manuais. É assim que se expressa e se forma de início toda a cultura. Quando aconselho com ardor ‘as humanidades’, quero recomendar esta cultura viva, e não um saber fossilizado, sobretudo em história e filosofia.

Entidades substituíveis - Checkout e método de pagamento

Se todos Fleeps são Sloops e todos Sloops são Loopies, então todos Fleeps são definitivamente Loopies.

No artigo sobre O.C.P., foi dito que as entidades de software devem ser abertas para extensão, mas fechadas para edição. Foram mostrados alguns problemas causados pelo acoplamento, como a dificuldade em se manter o código, e como refatorar o código inicial para que pudéssemos evitar edições durante seu ciclo de vida. Naquele artigo, você viu um código todo coberto por testes e resolveu seguir aquelas dicas na construção de um sistema de pagamentos. Seguindo a linha T.D.D., você começa a escrever seus testes e fica feliz com o resultado. Seu código ficou elegante, tem uma boa cobertura por testes, o acoplamento é baixo e a manutenção não terá tantos problemas, pelo menos não aparentemente.

Então um novo requisito surge e, aquilo que parecia adequado, se mostra problemático. Após alguma depuração, você percebe que, apesar de todos os testes estarem passando, a aplicação falha. Isso ocorre porque os testes unitários trabalham com unidades isoladas, encapsuladas ou "mockadas". Com isso, os testes unitários passam quando a aplicação, que é um conjunto de unidades que trabalham juntas, está falhando. O comportamento esperado de uma unidade pode parecer correto, quando ela está sendo testada isoladamente. Mas quando confrontada com seu tipo base, o comportamento continua como esperado? Nossos Fleeps estão se comportando como os Loopies que são?

Por volta 1994, Barbara Liskov e Jeannette Wing formularam um princípio de design que ficou conhecido como L.S.P., ou Princípio da Substituição de Liskov, e afirma o seguinte:

Let q(x) be a property provable about objects x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.

Ou seja:

Se a variável x é do tipo T, então q(x) será verdadeiro.

Se a variável y é do tipo S e todo S é T, então q(y) deve ser verdadeiro.

O caso de uso - Um sistema de pagamentos online

Vamos imaginar que tenhamos um E-Commerce e que, após escolher alguns itens na loja, o cliente vá fazer o checkout. Além disso, nossa loja vai aceitar, nesse instante, pagamentos via Cartão de Crédito, comunicando diretamente com o serviço da Cielo. Como se trata de um checkout, começamos a implementação por ele:

O teste

<?php namespace Neto\Commerce; use Neto\Commerce\Shipping\ShippingMethod; use Neto\Commerce\Payment\PaymentMethod; class CheckoutTest extends \PHPUnit_Framework_TestCase { private function createConfiguredCheckout(ShoppingCart $shoppingCart, ShippingMethod $shippingMethod, PaymentMethod $paymentMethod) { $shippingFrom = '14400000'; $shippingTo = '01000000'; $checkout = new Checkout(); $checkout->configure($shoppingCart, $paymentMethod, $shippingMethod, $shippingFrom, $shippingTo); return $checkout; } private function createShippingMethod($shippingAmount = 0) { $shippingMethod = $this->getMock('\Neto\Commerce\Shipping\ShippingMethod', array('getShippingAmount')); if ($shippingAmount > 0) { $shippingMethod->expects($this->once()) ->method('getShippingAmount') ->will($this->returnValue($shippingAmount)); } return $shippingMethod; } private function createShoppingCart() { $shoppingCart = new ShoppingCart(); $shoppingCart->addItem(new Product(123, 'item 1', 100, 1, 2, 15, 30)); $shoppingCart->addItem(new Product(456, 'item 2', 100, 1, 2, 15, 30)); return $shoppingCart; } /** * @testdox Checkout::configure() will throw an Exception if the cart is empty. * @expectedException \LogicException * @expectedExceptionMessage Cart is empty */ public function testConfigureWillThrowAnExceptionIfCartIsEmpty() { $shippingMethod = $this->createShippingMethod(); $paymentMethod = $this->getMock('\Neto\Commerce\Payment\PaymentMethod'); $shoppingCart = new ShoppingCart(); $this->createConfiguredCheckout($shoppingCart, $shippingMethod, $paymentMethod); } /** * @testdox Checkout::configure() will configure the PaymentMethod with item total and shipping amount. */ public function testConfigureWillConfigureThePaymentTotalsWithCartTotals() { $shippingAmount = 10; $shippingMethod = $this->createShippingMethod($shippingAmount); $shoppingCart = $this->createShoppingCart(); $itemTotal = $shoppingCart->getItemTotal(); $paymentMethod = $this->getMock('\Neto\Commerce\Payment\PaymentMethod', array('configure')); $paymentMethod->expects($this->at(0)) ->method('configure') ->with($itemTotal + $shippingAmount, $itemTotal, $shippingAmount); $this->createConfiguredCheckout($shoppingCart, $shippingMethod, $paymentMethod); } /** * @testdox Checkout::pay() will throw an Exception if called before Checkout::configure() * @expectedException \BadMethodCallException * @expectedExceptionMessage Checkout must be configured first */ public function testPayWillThrowAnExceptionIfNotConfiguredFirst() { $checkout = new Checkout(); $checkout->pay(); } /** * @testdox Checkout::pay() will calls PaymentMethod::pay() */ public function testPayWillCallsPaymentMethodPay() { $shippingMethod = $this->createShippingMethod(); $shoppingCart = $this->createShoppingCart(); $paymentMethod = $this->getMock('\Neto\Commerce\Payment\PaymentMethod', array('pay', 'configure')); $paymentMethod->expects($this->once()) ->method('pay'); $checkout = $this->createConfiguredCheckout($shoppingCart, $shippingMethod, $paymentMethod); $checkout->pay(); } public function testCheckoutPayWillReturnTheValueReturnedByPaymentMethodPay() { $shippingMethod = $this->createShippingMethod(); $shoppingCart = $this->createShoppingCart(); $paymentMethod = $this->getMock('\Neto\Commerce\Payment\PaymentMethod', array('pay', 'configure')); $paymentMethod->expects($this->any()) ->method('pay') ->will($this->onConsecutiveCalls(true, false)); $checkout = $this->createConfiguredCheckout($shoppingCart, $shippingMethod, $paymentMethod); $this->assertTrue($checkout->pay()); $this->assertFalse($checkout->pay()); } }

O código

<?php namespace Neto\Commerce; use Neto\Commerce\Shipping\ShippingMethod; use Neto\Commerce\Payment\PaymentMethod; class Checkout { /** * @var \Neto\Commerce\Payment\PaymentMethod */ private $paymentMethod; public function configure(ShoppingCart $shoppingCart, PaymentMethod $paymentMethod, ShippingMethod $shippingMethod, $shippingFrom, $shippingTo) { if (count($shoppingCart) == 0) { throw new \LogicException('Cart is empty'); } $itemTotal = $shoppingCart->getItemTotal(); $shippingAmount = $shoppingCart->getShippingAmount($shippingMethod, $shippingFrom, $shippingTo); $paymentMethod->configure($itemTotal + $shippingAmount, $itemTotal, $shippingAmount); $this->paymentMethod = $paymentMethod; } public function pay() { if ($this->paymentMethod === null) { throw new \BadMethodCallException('Checkout must be configured first'); } return $this->paymentMethod->pay(); } }

O problema

Como estamos recebendo os dados do cartão do cliente diretamente na loja e utilizando o serviço da Cielo para autorizar o pagamento, esperamos que o método PaymentMethod::pay() retorne TRUE se a transação tiver autorizada, ou FALSE, caso a transação não tenha sido autorizada. De fato, a solução é simples e funciona perfeitamente para esse caso de uso.

Passado algum tempo, devido a uma questão de mercado, a loja resolve utilizar PayPal como solução de pagamento. Com o novo requisito, pegamos a interface PaymentMethod e fazemos a implementação do PayPal Express Checkout. Essa implementação é feita utilizando o método PaymentMethod::configure() para executar a operação SetExpressCheckout que configurará a transação, e o método PaymentMethod::pay() para executar executar a operação DoExpressCheckoutPayment, que finalizará a transação. Executando os testes unitários, veremos que a abordagem com PayPal funciona, todos os testes unitários passam e ficamos felizes, afinal, temos a possibilidade de pagamentos com Cielo e PayPal.

Mas realmente funciona?

O problema vai aparecer, quando fizermos um teste comportamental. Apesar dos testes unitários passarem, um pagamento via PayPal não se comporta como um pagamento via Cielo. Quando utilizamos a implementação PayPal segundo a interface PaymentMethod, percebemos que, para executar o método PaymentMethod::pay(), o método PaymentMethod::configure() precisará ser chamado antes. Como o método PaymentMethod::configure() cria um novo TOKEN, então passamos a ter uma nova transação criada na PayPal.

Isso acontece pois, isoladamente, os códigos estão corretos. Mas quando confrontamos a nova implementação com a abordagem inicial, um participante comporta-se de forma diferente do outro. Segundo a abordagem inicial, o novo participante é mais forte, ou seja, faz mais coisas do que deveria fazer. Quando estávamos trabalhando com Cielo, havia uma única chamada ao serviço, que criava a transação e verificava a autorização. Com a nova implementação, duas chamadas são feitas, uma para configurar a transação, que cria um novo TOKEN e consequentemente uma nova transação, e uma para finalizar a transação.

A implementação original abstraiu o método de pagamento e, de fato, Checkout não tem conhecimento sobre como a implementação é feita. Qualquer implementação síncrona, teoricamente, deve funcionar, mas como Checkout faz suposições sobre o fluxo de pagamento, a implementação falha quando é assíncrona.

Refatoração

O primeiro passo na refatoração desse código, é remover as suposições que o participante Checkout faz sobre o participante PaymentMethod. Isso é importante, pois somente assim conseguiremos trabalhar na refatoração do participante PaymentMethod. Se analisarmos o processo de checkout, veremos alguns passos comuns, independentemente do método de pagamento, por exemplo:

Cliente informa seus dados cadastrais.

Cliente escolhe o método de pagamento.

Cliente paga.

Apesar de não aparecer na lista acima, existe a criação do pedido. A criação desse pedido, naquele momento, tem um status que indica que ainda não foi pago. Após o cliente efetuar o pagamento, também existe um novo passo, que muda o status de pagamento para “pago”, “não autorizado”, etc.

<?php namespace Neto\Commerce; use \PDO; use Neto\Commerce\Shipping\ShippingMethod; use Neto\Commerce\Payment\PaymentMethod; class Checkout { /** * @var integer */ private $orderId; /** * @var \Neto\Commerce\PaymentSystem */ private $paymentSystem; public function configure(ShoppingCart $shoppingCart, PaymentSystem $paymentSystem, ShippingMethod $shippingMethod, $shippingFrom, $shippingTo { //... $this->paymentSystem = $paymentSystem; $this->paymentSystem->attach($this); } //... public function update(PaymentSystem $paymentSystem) { //update order with payment status } }

Se observarmos o novo Checkout, invertemos a responsabilidade pelo fluxo do checkout. O método configure fica responsável por configurar o checkout e dizer para o PaymentSystem: "Quando o status de um pagamento mudar, me atualize". Dessa forma, qualquer mudança de status de pagamento, o método Checkout::update será chamado com as informações sobre o pagamento.

Com isso, nossa interface PaymentSystem fica:

<?php namespace Neto\Commerce\Payment; use Neto\Commerce\Checkout; interface PaymentSystem { public function attach(Checkout $checkout); public function notify(); }

Conclusão

Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.

Muitos já devem ter ouvido falar sobre Open/Closed Principle. O que muitos não entendem, é o que, de fato, significa ter entidades de software abertas para extensão, mas fechadas para edição. Acredito que, talvez, o motivo para grande a maioria das confusões em relação a esse princípio, se dê por conta de uma falha na exemplificação de um caso de uso real ou da ausência das consequências causadas pela violação.

O.C.P. se trata, na verdade, de evolução. Assim como pessoas evoluem e mudam conforme o tempo, o software também muda. Além disso, da mesma forma como acontece com as pessoas, que evoluem para a vida adulta, sem apagar sua infância, um software também deve evoluir, sem que suas entidades sejam modificadas para isso.

Se há algo que não vai mudar durante o ciclo de vida de um software, é o fato de que todo software muda durante seu ciclo de vida. Isso significa que, quanto mais velho é um software, mais entidades dependem umas das outras, consequentemente, mais entidades serão afetadas pela mudança.

Modificar uma entidade de software significa que uma série de reações em cadeia acontecerão. Se você tem uma boa cobertura de testes em seu software, já deve ter se deparado com esse tipo de situação, onde a simples edição de uma entidade, ocasiona a falha de vários testes, de entidades muitas vezes não diretamente relacionadas, mas que dependem de uma dependência direta da entidade modificada.

Se é fato que o software muda, e O.C.P. estabelece que as entidades de software devem ser fechadas para modificação, como é, então, um software conforme O.C.P.?

O caso de uso - Calculando preço do frete e prazo de entrega

Vamos imaginar que tenhamos um E-Commerce que utiliza um serviço, inicialmente o da E.C.T. (Correios), para calcular o custo do frete para entregar uma encomenda em um endereço especificado pelo cliente.

O código original

<?php namespace Neto\Commerce; class ShoppingCart implements \Countable, \IteratorAggregate { private $items = array(); private $quantities = array(); public function addItem(Product $product, $quantity = 1) { $productId = $product->getProductId(); if (isset($this->items[$productId])) { $quantity += $this->quantities[$productId]; } $this->items[$productId] = $product; $this->quantities[$productId] = $quantity; } /** * @see \Countable::count() */ public function count() { return count($this->items); } public function getItemAmount($productId) { if (!isset($this->items[$productId])) { throw new \UnexpectedValueException('Item not found'); } $quantity = $this->quantities[$productId]; return $quantity * $this->getItemPrice($productId); } public function getItemPrice($productId) { if (!isset($this->items[$productId])) { throw new \UnexpectedValueException('Item not found'); } return $this->items[$productId]->getProductPrice(); } public function getItemQuantity($productId) { if (!isset($this->quantities[$productId])) { return 0; } return $this->quantities[$productId]; } public function getItemTotal() { $total = 0; foreach ($this->items as $productId => $item) { $total += $this->getItemAmount($productId); } return $total; } /** * @see \IteratorAggregate::getIterator() */ public function getIterator() { return new \ArrayIterator($this->items); } public function getShippingAmount($shippingFrom, $shippingTo) { if ($this->count() == 0) { return 0; } $weight = 0; $height = 0; $width = 0; $length = 0; foreach ($this->items as $productId => $item) { $weight += $this->quantities[$productId] * $item->getProductWeight(); $height += $this->quantities[$productId] * $item->getProductHeight(); $currentWidth = $item->getProductWidth(); $currentLength = $item->getProductLength(); if ($currentWidth > $width) { $width = $currentWidth; } if ($currentLength > $length) { $length = $currentLength; } } $ect = new \Neto\Commerce\Shipping\ECT(); return $ect->getShippingAmount($shippingFrom, $shippingTo, $weight, $height, $width, $length); } }

O problema

Observando o método ShoppingCart::getShippingAmount(), veremos facilmente alguns problemas:

Existe um acoplamento muito alto com o participante new \Neto\Commerce\Shipping\ECT.

A estratégia para o cálculo das dimensões da embalagem é muito frágil.

De fato, se observarmos atentamente, o acoplamento com o participante ECT é tão alto, que dificulta até os testes. Com o conhecimento específico sobre como mensurar o tamanho da embalagem e o participante ECT, o participante ShoppingCart toma decisões que tornarão a manutenção desse código extremamente difícil. De fato, se a empresa passar a fazer entregar com outro prestador de serviços, teremos que editar esse código.

O problema vai ficando maior, conforme novos prestadores de serviço de entrega vão sendo agregados à carteira de prestadores de serviço da empresa. Por exemplo, imaginem que, por uma questão de mercado, a loja passe a enviar os produtos com, além da ECT, também com a TRANSFOLHA ou outros serviços de logística. Se esse código não for refatorado rapidamente, sua rigidez pode causar edições semelhantes a:

public function getShippingAmount($shippingWith, $shippingFrom, $shippingTo) { if ($this->count() == 0) { return 0; } switch ($shippingWith) { case 'ECT': $weight = 0; $height = 0; $width = 0; $length = 0; foreach ($this->items as $productId => $item) { $weight += $this->quantities[$productId] * $item->getProductWeight(); $height += $this->quantities[$productId] * $item->getProductHeight(); $currentWidth = $item->getProductWidth(); $currentLength = $item->getProductLength(); if ($currentWidth > $width) { $width = $currentWidth; } if ($currentLength > $length) { $length = $currentLength; } } $ect = new \Neto\Commerce\Shipping\ECT(); return $ect->getShippingAmount($shippingFrom, $shippingTo, $weight, $height, $width, $length); case 'TransFolha': //código para calcular frete com a TransFolha case 'FreteFácil': //código para calcular frete com PayPal Frete Fácil case 'UPS': //código para calcular frete com UPS } }

Isso é péssimo, primeiro pois a cada edição, um bug em potencial é adicionado ao código. Segundo, pois a dificuldade em testar o código nos deixa no escuro sobre os possíveis bugs. Além disso, a cada nova adição de um prestador de serviço, o método ShoppingCart::getShippingAmount() assume a responsabilidade sobre a lógica do cálculo das dimensões da embalagem e frete.

Como o princípio de design O.C.P. nos diz que ninguém deve ter autorização para editar o código, precisamos garantir que esse código não precise ser editado. Isso é até muito simples de se fazer. De fato, a simples refatoração para permitir que o código seja testável, já vai eliminar a necessidade de se editar esse código no futuro. Quando digo sobre permitir que o código seja testável, estou dizendo que precisamos, de alguma forma, poder ter um Mock para o participante responsável pelo cálculo do frete.

O teste:

<?php namespace Neto\Commerce; class ShoppingCartTest extends \PHPUnit_Framework_TestCase { /** * @testdox Initial value for ShoppingCart::count() will be zero */ public function testInitialItemCountInTheCartIsZero() { $cart = new ShoppingCart(); $this->assertCount(0, $cart); } /** * @testdox Adding an item to shopping cart with ShoppingCart::addItem(Product $product, $quantity = 1) will increase the item count. */ public function testAddingAnItemToShoppingCartWillIncreaseTheItemCount() { $cart = new ShoppingCart(); $this->assertCount(0, $cart); $cart->addItem(new Product(123, 'item 0', 100, 1, 2, 15, 30)); $this->assertCount(1, $cart); $cart->addItem(new Product(234, 'item 1', 100, 1, 2, 15, 30)); $this->assertCount(2, $cart); } /** * @testdox Adding the same item twice to shopping cart will not change the item count. */ public function testAddingTheSameItemTwiceToShoppingCartWillNotChangeTheItemCount() { $cart = new ShoppingCart(); $this->assertCount(0, $cart); $cart->addItem(new Product(123, 'item 0', 100, 1, 2, 15, 30)); $this->assertCount(1, $cart); $cart->addItem(new Product(123, 'item 0', 100, 1, 2, 15, 30)); $this->assertCount(1, $cart); } /** * @testdox ShoppingCart::getItemQuantity($productId) will return zero if the product was not added to the shopping cart. */ public function testGetProductQuantityWillReturnZeroIfTheProductWasNotAddedToTheShoppingCart() { $cart = new ShoppingCart(); $this->assertEquals(0, $cart->getItemQuantity(123)); } /** * @testdox Adding the same item twice to shopping cart will increase its quantity */ public function testAddingTheSameItemTwiceToShoppingCartWillIncreaseItsQuantity() { $product = new Product(123, 'item 0', 100, 1, 2, 15, 30); $productId = $product->getProductId(); $cart = new ShoppingCart(); $this->assertEquals(0, $cart->getItemQuantity($productId)); $cart->addItem($product); $this->assertEquals(1, $cart->getItemQuantity($productId)); $cart->addItem($product); $this->assertEquals(2, $cart->getItemQuantity($productId)); } /** * @expectedException \UnexpectedValueException * @testdox ShoppingCart::getItemPrice($productId) will throw an exception if product was not found in the cart. */ public function testGetItemPriceWillThrowAnExceptionIfProductWasNotFoundInTheCart() { $cart = new ShoppingCart(); $cart->getItemPrice(123); } /** * @testdox ShoppingCart::getItemPrice($productId) will return the product price. */ public function testGetItemPriceWillReturnTheProductPrice() { $productPrice = 100; $product = new Product(123, 'item 0', $productPrice, 1, 2, 15, 30); $productId = $product->getProductId(); $cart = new ShoppingCart(); $cart->addItem($product); $this->assertEquals($productPrice, $cart->getItemPrice($productId)); } /** * @expectedException \UnexpectedValueException * @testdox ShoppingCart::getItemAmount($productId) will throw an exception if product was not found in the cart. */ public function testGetItemAmountWillThrowAnExceptionIfProductWasNotFoundInTheCart() { $cart = new ShoppingCart(); $cart->getItemAmount(123); } /** * @testdox ShoppingCart::getItemAmount($productId) will return the product price multiplied by its quantity. */ public function testGetItemAmountWillReturnTheProductPriceMultipliedByItsQuantity() { $productPrice = 100; $quantity = 5; $product = new Product(123, 'item 0', $productPrice, 1, 2, 15, 30); $productId = $product->getProductId(); $cart = new ShoppingCart(); $cart->addItem($product, $quantity); $this->assertEquals($productPrice * $quantity, $cart->getItemAmount($productId)); } /** * @testdox ShoppingCart::getItemTotal() will return the sum of all product price multiplied by its quantity in the cart. */ public function testGetItemTotalWillReturnTheSumOfAllItemsInTheCart() { $cart = new ShoppingCart(); $this->assertEquals(0, $cart->getItemTotal()); $cart->addItem(new Product(123, 'item 0', 100, 1, 2, 15, 30), 2); $cart->addItem(new Product(234, 'item 1', 100, 1, 2, 15, 30), 2); $this->assertEquals(400, $cart->getItemTotal()); } /** * @testdox ShoppingCart::getIterator() will return an \Iterator with all products in the cart. */ public function testGetIteratorWillReturnAnIteratorWithAllProductsInTheCart() { $products = array( new Product(123, 'item 1', 100, 1, 2, 15, 30), new Product(456, 'item 2', 100, 1, 2, 15, 30), new Product(789, 'item 3', 100, 1, 2, 15, 30) ); $cart = new ShoppingCart(); foreach ($products as $product) { $cart->addItem($product); } $iterator = $cart->getIterator(); $iterator->rewind(); $this->assertInstanceOf('\Iterator', $iterator); for ($i = 0, $t = count($products); $i < $t; ++$i, $iterator->next()) { $this->assertSame($products[$i], $iterator->current()); } $this->assertFalse($iterator->valid()); } }

Como podemos ver, não existe um teste para o cálculo do frete. Mesmo porque, daquela forma, não há como testá-lo. Vamos começar a refatoração, garantindo que ele seja testável. Isso será feito através da injeção da dependência:

<?php namespace Neto\Commerce; class ShoppingCartTest extends \PHPUnit_Framework_TestCase { //... /** * @testdox ShoppingCart::getShippingAmount() will return zero if cart is empty. */ public function testGetShippingAmountWillReturnZeroIfCartIfEmpty() { $shippingMethod = $this->getMock('\Neto\Commerce\Shipping\ShippingMethod', array('getShippingAmount')); $cart = new ShoppingCart(); $this->assertEquals(0, $cart->getShippingAmount($shippingMethod, '14400000', '01000000')); } }

A partir de agora, já começamos a ter o código testável. Com a inversão da dependência, nosso ShoppingCart não será mais responsável nem pelo cálculo das dimensões da embalagem, nem pela criação da instância da ECT. O interessante dessa primeira refatoração, é que o teste vai passar, mesmo não tendo refatorado ainda o código do ShoppingCart. Para finalizar o carrinho, tudo o que precisamos é verificar se o carrinho está fazendo a chamada corretamente:

<?php namespace Neto\Commerce; class ShoppingCartTest extends \PHPUnit_Framework_TestCase { //... /** * @testdox ShoppingCart::getShippingAmount() will return zero if cart is empty. */ public function testGetShippingAmountWillReturnZeroIfCartIfEmpty() { $shippingMethod = $this->getMock('\Neto\Commerce\Shipping\ShippingMethod', array('getShippingAmount')); $cart = new ShoppingCart(); $this->assertEquals(0, $cart->getShippingAmount($shippingMethod, '14400000', '01000000')); } /** * @testdox ShoppingCart::getShippingAmount() will call ShippingMethod::getShippingAmount() to calculates the shipping amount. */ public function testGetShippingAmountWillCallShippingMethodToCalculatesTheShippingAmount() { $cart = new ShoppingCart(); $cart->addItem(new Product(123, 'item 0', 100, 1, 2, 15, 30), 2); $shippingFrom = '14400000'; $shippingTo = '01000000'; $shippingMethod = $this->getMock('\Neto\Commerce\Shipping\ShippingMethod', array('getShippingAmount')); $shippingMethod->expects($this->at(0)) ->method('getShippingAmount') ->with($cart, $shippingFrom, $shippingTo); $cart->getShippingAmount($shippingMethod, $shippingFrom, $shippingTo); } }

Vamos refatorar o carrinho agora:

<?php namespace Neto\Commerce; use Neto\Commerce\Shipping\ShippingMethod; class ShoppingCart implements \Countable, \IteratorAggregate { //... public function getShippingAmount(ShippingMethod $shippingMethod, $shippingFrom, $shippingTo) { if ($this->count() == 0) { return 0; } return $shippingMethod->getShippingAmount($this, $shippingFrom, $shippingTo); } }

Como podemos ver, o código ficou muito mais elegante agora. Não existe conhecimento específico nenhum. Tudo o que o método ShoppingCart::getShippingAmount() faz, é delegar o cálculo para um outro participante. Ainda, para evitar qualquer tipo de acoplamento, o carrinho passa a si mesmo, para o participante ShippingMethod, para que as decisões sobre como calcular o frete sejam feitas exclusivamente pelo novo participante. Com o teste passando, podemos criar a interface ShippingMethod:

<?php namespace Neto\Commerce\Shipping; use Neto\Commerce\ShoppingCart; interface ShippingMethod { public function getShippingAmount(ShoppingCart $shoppingCart, $shippingFrom, $shippingTo); }

Agora, podemos implementar o participante ECT, ou qualquer um outro:

<?php namespace Neto\Commerce\Shipping; use Neto\Commerce\ShoppingCart; class ECT implements ShippingMethod { const ENDPOINT = 'http://ws.correios.com.br/calculador/CalcPrecoPrazo.asmx'; const SEDEX = 40010; private $weight = 0; private $height = 0; private $width = 0; private $length = 0; private function calcPackageDimensions(ShoppingCart $shoppingCart) { foreach ($shoppingCart as $productId => $item) { $quantity = $shoppingCart->getItemQuantity($productId); $this->weight += $quantity * $item->getProductWeight(); $this->height += $quantity * $item->getProductHeight(); $currentWidth = $item->getProductWidth(); $currentLength = $item->getProductLength(); if ($currentWidth > $this->width) { $this->width = $currentWidth; } if ($currentLength > $this->length) { $this->length = $currentLength; } } } public function createSoapClient() { return new \SoapClient(static::ENDPOINT. '?wsdl', array('trace' => true, 'exceptions' => true, 'style' => SOAP_DOCUMENT, 'use' => SOAP_LITERAL, 'soap_version' => SOAP_1_1, 'encoding' => 'UTF-8')); } public function getShippingAmount(ShoppingCart $shoppingCart, $shippingFrom, $shippingTo) { $this->calcPackageDimensions($shoppingCart); $request = new \stdClass(); $request->nCdEmpresa = ''; $request->sDsSenha = ''; $request->sCepOrigem = $shippingFrom; $request->sCepDestino = $shippingTo; $request->nVlPeso = $this->weight; $request->nCdFormato = 1; $request->nVlComprimento = $this->length; $request->nVlAltura = $this->height; $request->nVlLargura = $this->width; $request->sCdMaoPropria = 'n'; $request->nVlValorDeclarado = 0; $request->sCdAvisoRecebimento = 'n'; $request->nCdServico = ECT::SEDEX; $request->nVlDiametro = 0; $response = $this->createSoapClient()->CalcPrecoPrazo($request); $cServico = $response->CalcPrecoPrazoResult->Servicos->cServico; if (isset($cServico->Erro) && $cServico->Erro != 0) { throw new \RuntimeException($cServico->MsgErro, $cServico->Erro); } return $cServico->Valor; } }

Tudo se resume em abstração

É claro que haverão casos que não serão tão simples como esse do exemplo, mas de forma geral, Abstração é a chave para solucionar muitos dos problemas de design que possamos ter. Excesso de conhecimento causa um acoplamento alto. Quanto maior o acoplamento, maior é a dificuldade em se testar o código. Quanto maior a dificuldade em se testar o código, maior a probabilidade de não se testar o código e, consequentemente, maior a probabilidade de bugs.

Outro ponto importante, é que apesar do artigo se tratar de O.C.P., acabamos abordando S.R.P. ao remover a responsabilidade da estratégia de cálculo da embalagem, do participante ShoppingCart. Abordamos também um outro princípio importante, D.I.P., que além de garantir que o código fosse testável, ainda eliminou, pelo menos para esse caso, a necessidade de edição do ShoppingCart.

Entre todas as dicas dadas aqui, existe uma que deve sempre ser colocada no topo de qualquer lista de prioridades: Garanta que seu código seja testável, isso facilitará muito qualquer refatoração que seja necessária.

Olá pessoal, antes de começar, gostaria de deixar claro que o texto abaixo trata-se, na verdade, de um ponto de vista pessoal sobre segurança. Obviamente, o texto dará foco à segurança da informação, mas acredito que determinados pontos sejam adequados também para segurança de forma geral.

Segurança

Se alguém me perguntar: “O que é segurança?”

Eu provavelmente responderei, de bate pronto, com outra pergunta: “O que você quer segurar?”

A resposta com uma outra pergunta, apesar de parecer evasiva, tem um objetivo bastante direto: Mensurar o valor da informação que precisa ser segurada.

Vou tentar me explicar:

Em um cenário hipotético, temos uma garotinha, Carolzinha é seu nome. Carolzinha, apesar de ter apenas 8 anos, adora tecnologia, assim como adora os bichinhos de pelúcia que ganhou de seu pai. Juntando o útil ao agradável, ela decidiu publicar, em um site próprio, fotos de seus bichinhos de pelúcia em diversas ocasiões, para poder mostrar para as amiguinhas. Ela possui um banco de dados com centenas de fotos, dos mais variados bichinhos, nas mais variadas situações. Esse banco de dados utiliza um hash MD5 para armazenar sua senha.

Em outro cenário hipotético, temos uma instituição financeira, de âmbito global, com uma carteira de clientes relativamente grande, que fazem muitas transações, de alto valor monetário. Essa instituição financeira utiliza um sistema extremamente complexo, que além de controlar todas essas transações, ainda mantém um histórico detalhado de cada transação, com data, local, valor, etc. Assim como o site da Carolzinha, o sistema dessa instituição financeira também utiliza um hash MD5 para armazenar as senhas de seus clientes.

O MD5, que foi desenvolvido em 1991, é um algorítimo de hash (unidirecional) de 128 bits, que faz apenas uma passagem sobre os dados e, por isso, é um hash com uma probabilidade relativamente alta de se conseguir uma colisão, ou seja, duas mensagens diferentes, produzindo o mesmo hash. Como é sabido que MD5 vulnerável, então podemos afirmar que ele não é seguro, correto?

A questão é: Qual o custo para se encontrar uma colisão em um hash MD5 e qual o benefício daquilo que pode ser obtido?

Será que esse custo não é muito superior ao benefício que será obtido com a senha de uma garotinha de 8 anos, cujo único conteúdo é uma base de dados com centenas de fotos de bichinhos de pelúcia?

Então, vejo segurança como uma medida de custo. Quanto maior o benefício daquilo que pode ser obtido, menor será sua segurança, independentemente da técnica aplicada na segurança. Quando o custo para se obter determinada informação for muito maior que a própria informação, então podemos dizer, de certa forma, que a informação está segura.

Sensação de segurança

Mesmo sabendo que seria necessário 1.7 x 10¹³ TB para armazenar todas as possibilidades de um hash MD5, Fulano, que é desenvolvedor de um gateway de pagamentos online, optou por utilizar um hash de 512 bits, da família SHA-2, já que não há colisão nesse tipo de hash.

Ao ser questionado se os dados dos clientes do gateway estavam seguros, Fulano respondeu com um grande SIM! Obviamente, a sensação de segurança proporcionada pelo hash de 512 bits, foi o fator motivante para o sim. Mas os dados estão mesmo seguros?

Vamos pensar em mais um cenário hipotético, de um site de uma rede de cinemas, que possui um programa de fidelidade, onde os clientes cadastrados ganham descontos progressivos, conforme utilizam os serviços da empresa. Esse site, por negligência, ou por acreditar que seus dados não tem tanto valor, armazena as senhas de seus clientes de forma plana no banco de dados.

Beltrano, um grande fã de cinema, além de ter um cadastro no site da rede de cinemas, também tem um cadastro na empresa de gateway de pagamentos. Beltrano, por desinformação, ou mera comodidade, assim como muitos outros usuários, utiliza a mesma senha no site do cinema e no gateway de pagamentos online.

Apesar do gateway de pagamentos online utilizar uma técnica avançada, que garante um alto custo para se obter uma informação, a segurança dos dados desse gateway pode ser comprometida pela ausência de segurança no armazenamento dos dados do site da rede de cinemas.

Transformar sensação de segurança em segurança, ao meu ver, não depende apenas das técnicas empregadas para segurar a informação, mas de políticas adotadas ao manter a informação. Fulano foi precipitado ao afirmar que os dados estavam seguros, pois o gateway de pagamentos não possui nenhuma política definida para renovação das credenciais de seus clientes.

Como em um sistema de informação, qualquer pessoa pode se passar por qualquer outra pessoa, a ausência de uma política de renovação de credenciais, fez com que algo teoricamente seguro, passasse a ser apenas sensação de segurança, mas que na prática, pode comprometer todo um conjunto de técnicas empregadas na armazenagem da informação.

Conclusão

A segurança em sistemas de informação não está apenas relacionada com identificação, autenticação e autorização. Assim como a segurança na armazenagem dos dados não está apenas na técnica de criptografia empregada, acesso físico ao servidor, etc.

Penso que segurança está bastante relacionada com políticas empregadas no processo de identificação e autenticação, armazenagem, mas também na renovação de credenciais. Quanto mais antiga for uma mesma credencial, mais vulnerável ela pode ser.

A class should have one, and only one, reason to change

Talvez as duas primeiras palavras que um instrutor diria em uma turma de redação seriam: Coesão e Coerência.

Coesão significa ligação. Uma coisa coesa é uma coisa focada em um determinado contexto e era justamente sobre isso que Tom DeMarco e Meilir Page-Jones estavam falando quando descreveram o Princípio da responsabilidade única.

Quanto mais coesa for uma classe, menor será seu acoplamento. Por outro lado, uma classe com mais do que uma responsabilidade terá maiores chances de sofrer com alguma modificação.

Mas para compreender realmente S.R.P. precisamos compreender o que é responsabilidade e, para isso, vamos dar uma olhada na Wikipédia:

Os motivos das ações de um indivíduo responsável devem fazer sentido e este deve fazer conhecer suas opiniões sem causar transtorno, ao resto da comunidade.

Com um pequeno ajuste, esse fragmento define praticamente tudo o que precisamos para compreender SRP:

Os motivos dos métodos de uma classe devem fazer sentido e esta deve fazer conhecer seus comportamentos sem causar transtorno ao resto da aplicação.

Ao contrário do que muitos pensam, uma classe coesa não significa que ela deva ter apenas um método público, mas que todos seus métodos públicos, independentemente da quantidade, tenham uma forte ligação com o seu propósito.

O código original:

<?php class ContactsDisplay { /** * @var array */ private $contacts = array(); public function __construct( $filename ) { $fh = fopen( $filename , 'r' ); while ( !feof( $fh ) ) { $data = fgetcsv( $fh , 1024 , ',' ); $this->contacts[] = array( 'email' => $data[ 0 ], 'name' => $data[ 1 ] ); } fclose( $fh ); } public function show() { foreach ( $this->contacts as $contact ) { echo '<dl>'; echo '<dt>' , $contact[ 'email' ] , '</dt>'; echo '<dd>' , $contact[ 'name' ] , '</dd>'; echo '</dl>'; } } }

O problema:

Como o nome sugere, ContactsDisplay tem como objetivo mostrar contatos, então, qual o problema dela ?

O problema, é que podemos identificar claramente 2 razões para ela possa ser modificada:

 A origem dos dados mudou.

A forma de exibição mudou.

Basicamente ContactsDisplay recebe dados de uma origem e exibe esses dados, tudo estaria bem se a classe não assumisse para si a responsabilidade de manipular o arquivo.

Se tivermos que modificar a entrada, seja para um banco de dados, webservice ou qualquer que seja a nova origem, teremos que modificar a classe ContactsDisplay e, com isso, refazer testes mesmo em classes relacionadas com exibição, que não deveriam ser afetadas pela mudança na origem de dados.

O Teste:

<?php require_once 'ContactsDisplay.php'; require_once 'PHPUnit/Framework/TestCase.php'; /** * ContactsDisplay test case. */ class ContactsDisplayTest extends PHPUnit_Framework_TestCase { /** * @var ContactsDisplay */ private $ContactsDisplay; /** * Prepares the environment before running a test. */ protected function setUp() { parent::setUp(); /** * The file filecsv.csv should contain the following lines: * * [email protected],Fulano de tal * [email protected],Beltrano * [email protected],Exemplo */ $data = array(); $data[] = '[email protected],Fulano de tal'; $data[] = '[email protected],Beltrano'; $data[] = '[email protected],Exemplo'; file_put_contents( 'filecsv.csv' , implode( "\n" , $data ) ); $this->ContactsDisplay = new ContactsDisplay( 'filecsv.csv' ); } /** * Cleans up the environment after running a test. */ protected function tearDown() { $this->ContactsDisplay = null; parent::tearDown(); } /** * Tests ContactsDisplay->show() */ public function testShow() { ob_start(); $this->ContactsDisplay->show(); $expected = '<dl><dt>[email protected]</dt><dd>Fulano de tal</dd></dl>'; $expected .= '<dl><dt>[email protected]</dt><dd>Beltrano</dd></dl>'; $expected .= '<dl><dt>[email protected]</dt><dd>Exemplo</dd></dl>'; $actual = ob_get_contents(); ob_clean(); $this->assertEquals( $expected , $actual ); } }

Refatoração:

O primeiro passo na refatoração é a definição de uma entidade Contact:

<?php class Contact { private $email; private $name; public function __construct( $email , $name ) { $this->email = $email; $this->name = $name; } public function getEmail() { return $this->email; } public function getName() { return $this->name; } }

A criação da entidade Contact permitirá que a classe ContactsDisplay saiba trabalhar com os contatos independentemente da origem. Isso é importante porque a forma que os dados virão precisam ser conhecidos. Bancos de dados, arquivos CSV, webservices, cada fonte de dados pode entregar os contatos de uma forma diferente, porém a classe Contact permitirá que esses dados cheguem sempre da mesma forma para a ContactsDisplay.

Com isso, a ContactsDisplay ficará assim:

<?php require_once 'Contact.php'; class ContactsDisplay { /** * @var array */ private $contacts = array(); public function __construct( $filename ) { $fh = fopen( $filename, 'r' ); while ( !feof( $fh ) ) { $data = fgetcsv( $fh, 1024, ',' ); $this->contacts[] = new Contact( $data[ 0 ], $data[ 1 ] ); } fclose( $fh ); } public function show() { foreach ( $this->contacts as $contact ) { echo '<dl>'; echo '<dt>', $contact->getEmail(), '</dt>'; echo '<dd>', $contact->getName(), '</dd>'; echo '</dl>'; } } }

Executando novamente o teste, teremos sinal verde. Isso significa que nossa classe continua com o mesmo funcionamento de antes. Passamos para a próxima etapa, a separação da recuperação dos dados.

A separação dos dados se dará em duas partes:

Definição da ContactsReader.

Ajuste na ContactsDisplay para usar a ContactsReader.

<?php require_once 'Contact.php'; class ContactsReader { /** * @var string */ private $filename; public function __construct( $filename ) { $this->filename = $filename; } public function getContacts() { $fh = fopen( $this->filename, 'r' ); $contacts = array(); while ( !feof( $fh ) ) { $data = fgetcsv( $fh, 1024, ',' ); $contacts[] = new Contact( $data[ 0 ], $data[ 1 ] ); } fclose( $fh ); return $contacts; } }

<?php require_once 'ContactsReader.php'; class ContactsDisplay { /** * @var ContactsReader */ private $contactsReader; public function __construct( $filename ) { $this->contactsReader = new ContactsReader( $filename ); } public function show() { foreach ( $this->contactsReader->getContacts() as $contact ) { echo '<dl>'; echo '<dt>', $contact->getEmail(), '</dt>'; echo '<dd>', $contact->getName(), '</dd>'; echo '</dl>'; } } }

Novamente executamos o teste e novamente temos sinal verde, as modificações feitas não interferiram nem no funcionamento da classe, como também não precisamos fazer nenhum ajuste no uso dela.

Porém, criamos um novo problema: A classe ContactsDisplay tem a responsabilidade de criar a instância de ContactsReader, o que é muito ruim já que toda a refatoração iniciou-se justamente para que pudéssemos variar a origem.

Vamos remover o acoplamento passando a ContactsReader como parâmetro na construção da ContactsDisplay:

<?php require_once 'ContactsReader.php'; class ContactsDisplay { /** * @var ContactsReader */ private $contactsReader; public function __construct( ContactsReader $contactsReader ) { $this->contactsReader = $contactsReader; } public function show() { foreach ( $this->contactsReader->getContacts() as $contact ) { echo '<dl>'; echo '<dt>', $contact->getEmail(), '</dt>'; echo '<dd>', $contact->getName(), '</dd>'; echo '</dl>'; } } }

Vamos também ajustar o nosso teste para a nova realidade: (passar ContactsReader como parâmetro)

<?php require_once 'ContactsDisplay.php'; require_once 'PHPUnit/Framework/TestCase.php'; /** * ContactsDisplay test case. */ class ContactsDisplayTest extends PHPUnit_Framework_TestCase { /** * @var ContactsDisplay */ private $ContactsDisplay; /** * Prepares the environment before running a test. */ protected function setUp() { parent::setUp(); /** * The file filecsv.csv should contain the following lines: * * [email protected],Fulano de tal * [email protected],Beltrano * [email protected],Exemplo */ $data = array(); $data[] = '[email protected],Fulano de tal'; $data[] = '[email protected],Beltrano'; $data[] = '[email protected],Exemplo'; file_put_contents( 'filecsv.csv' , implode( "\n" , $data ) ); $this->ContactsDisplay = new ContactsDisplay( new ContactsReader( 'filecsv.csv' ) ); } /** * Cleans up the environment after running a test. */ protected function tearDown() { $this->ContactsDisplay = null; parent::tearDown(); } /** * Tests ContactsDisplay->show() */ public function testShow() { ob_start(); $this->ContactsDisplay->show(); $expected = '<dl><dt>[email protected]</dt><dd>Fulano de tal</dd></dl>'; $expected .= '<dl><dt>[email protected]</dt><dd>Beltrano</dd></dl>'; $expected .= '<dl><dt>[email protected]</dt><dd>Exemplo</dd></dl>'; $actual = ob_get_contents(); ob_clean(); $this->assertEquals( $expected , $actual ); } }

Executando o teste, teremos sinal verde novamente. Isso significa que o funcionamento da classe ContactsDisplay permanece como antes. Para finalizar a refatoração precisamos remover a dependência da classe concreta ContactsReader da ContactsDisplay.

Podemos fazer isso de uma forma bem simples criando uma interface chamada ContactsReader que possui o método de interface getContacts(). Após a criação dessa interface, modificamos o nome da classe que faz leitura de contatos atualmente para alguma coisa que indique o que ela faz, por exemplo: CSVContactsReader.

<?php interface ContactsReader { public function getContacts(); }

<?php require_once 'Contact.php'; require_once 'ContactsReader.php'; class CSVContactsReader implements ContactsReader { /** * @var string */ private $filename; public function __construct( $filename ) { $this->filename = $filename; } public function getContacts() { $fh = fopen( $this->filename, 'r' ); $contacts = array(); while ( !feof( $fh ) ) { $data = fgetcsv( $fh, 1024, ',' ); $contacts[] = new Contact( $data[ 0 ], $data[ 1 ] ); } fclose( $fh ); return $contacts; } }

Ajustando o teste para a nova realidade:

<?php require_once 'ContactsDisplay.php'; require_once 'CSVContactsReader.php'; require_once 'PHPUnit/Framework/TestCase.php'; /** * ContactsDisplay test case. */ class ContactsDisplayTest extends PHPUnit_Framework_TestCase { /** * @var ContactsDisplay */ private $ContactsDisplay; /** * Prepares the environment before running a test. */ protected function setUp() { parent::setUp(); /** * The file filecsv.csv should contain the following lines: * * [email protected],Fulano de tal * [email protected],Beltrano * [email protected],Exemplo */ $data = array(); $data[] = '[email protected],Fulano de tal'; $data[] = '[email protected],Beltrano'; $data[] = '[email protected],Exemplo'; file_put_contents( 'filecsv.csv' , implode( "\n" , $data ) ); $this->ContactsDisplay = new ContactsDisplay( new CSVContactsReader( 'filecsv.csv' ) ); } /** * Cleans up the environment after running a test. */ protected function tearDown() { $this->ContactsDisplay = null; parent::tearDown(); } /** * Tests ContactsDisplay->show() */ public function testShow() { ob_start(); $this->ContactsDisplay->show(); $expected = '<dl><dt>[email protected]</dt><dd>Fulano de tal</dd></dl>'; $expected .= '<dl><dt>[email protected]</dt><dd>Beltrano</dd></dl>'; $expected .= '<dl><dt>[email protected]</dt><dd>Exemplo</dd></dl>'; $actual = ob_get_contents(); ob_clean(); $this->assertEquals( $expected , $actual ); } }

Com o sinal verde na execução do teste, temos a classe ContactsDisplay refatorada, mantendo a funcionalidade anterior, mas agora sem excesso de responsabilidade: Finalizamos a refatoração da ContactsDisplay.

O código final:

<?php /** * Representação de um contato. */ class Contact { /** * @var string */ private $email; /** * @var string */ private $name; /** * Constroi uma nova instância da entidade Contact * @param string $email Email do contato * @param string $name Nome do contato */ public function __construct( $email, $name ) { $this->email = $email; $this->name = $name; } /** * Recupera o email do contato. * @return string */ public function getEmail() { return $this->email; } /** * Recupera o nome do contato. * @return string */ public function getName() { return $this->name; } }

<?php /** * Interface para definição de um leitor de contatos. */ interface ContactsReader { /** * Recupera uma lista de contatos de uma origem qualquer. * @return array Um array contendo instâncias de Contact */ public function getContacts(); }

<?php require_once 'Contact.php'; require_once 'ContactsReader.php'; /** * Implementação da interface ContactsReader para leitura de * contatos armazenados em arquivos CSV. */ class CSVContactsReader implements ContactsReader { /** * @var string */ private $filename; /** * Constroi o leitor de contatos de arquivos CSV passando o * nome do arquivo que contém esses contatos. * @param string $filename Nome do arquivo CSV que contém * os contatos que serão lidos. */ public function __construct( $filename ) { $this->filename = $filename; } /** * Recupera a lista de contatos. * @return array Lista de contatos que estão armazenadas no * arquivo CSV. * @see ContactsReader::getContacts() */ public function getContacts() { $fh = fopen( $this->filename, 'r' ); $contacts = array(); while ( !feof( $fh ) ) { $data = fgetcsv( $fh, 1024, ',' ); $contacts[] = new Contact( $data[ 0 ], $data[ 1 ] ); } fclose( $fh ); return $contacts; } }

<?php require_once 'ContactsReader.php'; /** * Classe responsável pela exibição de contatos */ class ContactsDisplay { /** * @var ContactsReader */ private $contactsReader; /** * Constroi a instância de ContactsDisplay para a exibição de * uma lista de contatos. * @param ContactsReader $contactsReader Instância de ContactsReader * responsável por recuperar os contatos de uma origem qualquer. */ public function __construct( ContactsReader $contactsReader ) { $this->contactsReader = $contactsReader; } /** * Exibe os contatos. */ public function show() { foreach ( $this->contactsReader->getContacts() as $contact ) { echo '<dl>'; echo '<dt>', $contact->getEmail(), '</dt>'; echo '<dd>', $contact->getName(), '</dd>'; echo '</dl>'; } } }

Consequências:

Do ponto de vista do princípio da responsabilidade única, responsabilidade é a razão pela qual uma classe deve ser modificada. Se tivermos mais do que uma razão para modificar uma classe então temos uma classe com mais do que uma responsabilidade.

Como podemos ver no código final, a responsabilidade pela recuperação dos dados foi removida da classe ContactsDisplay. Com essa remoção, passamos a poder variar a origem dos dados sem afetar a exibição deles.

Talvez ocultação de informações seja a primeira coisa que nos vem à cabeça quando falamos sobre encapsulação. Porém, ocultar informações e encapsulamento são duas coisas distintas e devem ser tratadas de formas distintas.

Um experimento mental que gosto muito foi proposto pelo físico austríaco Erwin Schrödinger: Schrödinger propôs que um gato fosse colocado em uma caixa totalmente lacrada de forma que fosse impossível qualquer interferência externa. Na mesma caixa, um dispositivo que poderia matar o gato, mas com a mesma probabilidade de não matá-lo, foi colocado de forma que também não sofresse qualquer interferência pelo gato.

Após um período, sabendo que o dispositivo poderia ter matado ou não o gato, a incerteza sobre seu estado poderia ser utilizada para afirmar que, em determinado momento, o gato estaria vivo e morto com exatamente a mesma probabilidade -- Verschränkung.

Em orientação a objetos, quando definimos claramente as características essenciais de um objeto, estamos definindo um conjunto de operações que manipulam determinado conjunto de dados segundo os limites que nos permitem identificar esse objeto em meio aos outros objetos.

No experimento de Schrödinger podemos identificar:

Informação - Estado do gato.

Operação - Dispositivo que poderia matar ou não o gato.

15 anos antes desse experimento, Albert Einstein havia sugerido à Schrödinger o uso de uma carga de pólvora que poderia explodir o gato. Contudo, Schrödinger utilizou um contador Geiger e um frasco de cianeto que poderia envenenar e matar o gato.

O fato, é que qualquer dispositivo que pudesse matar ou não o gato poderia ser utilizado e é justamente a possibilidade de implementações diferentes dentro do limite estabelecido, que chamamos, do ponto de vista da orientação a objetos, de encapsulamento.

An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of object and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer.

Me lembro bem, quando ainda na escola primária, da primeira vez que ouvi a professora falando sobre substantivos concretos e abstratos. Lembro-me dela utilizando, especificamente, amor como ilustração de um substantivo abstrato.

Quando falamos sobre abstração em orientação a objetos, utilizamos exatamente o mesmo conceito: Não importa o que, como ou quem alguém ama (sim amar é um verbo transitivo direto, Mário de Andrade estava de sacanagem), as características essenciais do amor são claras e seus limites podem ser utilizados para identificar esse sentimento em meio aos outros sentimentos.

Ao dizer que a abstração denota as características essenciais de um objeto, tornando possível distingui-lo de outros tipos de objetos e que fornece uma definição conceitual sobre os limites desse objeto do ponto de vista do observador, estamos dizendo que um indivíduo, que está sendo espancado, sabe que seu agressor não o ama porquê as características essenciais do amor não contemplam espancamento (pelo menos deveria ser assim).

Porém, várias pessoas implementam o amor de forma diferente, obedecendo os limites, mas ainda assim diferentes umas das outras, por exemplo:

... Se você preferir morrer, antes de ver a outra partindo... É o amor que chegou na sua vida. É uma dádiva. ... (Mário de Andrade, 1927)

... É um não querer mais que bem querer; É solitário andar por entre a gente; É nunca contentar-se de contente; É cuidar que se ganha em se perder; ... (Luís de Camões, 1595)

Mesmo diferentes, conseguimos facilmente distinguir os dois fragmentos acima do seguinte:

Ai, dona fea, foste-vos queixar que vos nunca louve'en em meu trobar; mas ora quero fazer um cantar em que vos loarei toda via; e vedes como vos quero loar: dona fea, velha e sandia!...

Cada dia mais temos visto a linguagem PHP se tornando uma ferramenta poderosa no que se refere à orientação a objetos. Em mesma intensidade, temos visto códigos escritos com o objetivo de serem orientados a objetos, mas que estão mais para códigos estruturados, organizados em uma estrutura de linguagem class.

A orientação a objetos trata-se do relacionamento entre objetos. Enquanto na programação estruturada lidamos com gerenciamento e execução de tarefas e procedimentos, na programação orientada a objetos lidamos com hierarquias, composições, agregações e a forma com que um objeto representa um aspecto de um problema maior.

Essas diferenças de pensamentos entre os dois paradigmas costumam levar muita confusão e incertezas aos programadores, em especial aos programadores da linguagem PHP que apenas na versão 4 começou a ter um suporte à orientação a objetos e, somente agora, na versão 5+, começou a amadurecê-lo.

Apesar de não ter a pretensão de dizer se algum paradigma é melhor do que outro, The Godclass utilizará preferencialmente a orientação a objetos em suas postagens. Essas discussões sobre orientação a objetos utilizarão códigos reais, de programadores reais, ilustrando conceitos de orientação a objetos já discutidos por grandes autores em outras linguagens e que podem ser aplicados na refatoração desses códigos PHP.

Sim, The Godclass trata-se de design, tanto de princípios quanto de padrões. Termos como: responsabilidade, usa, é-um, possui-um, possui-muitos, composição, agregação, abstração, herança, encapsulamento, polimorfismo, design pattern, S.O.L.I.D., UML, e autores como Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Robert "UncleBob" Martin, Martin Fowler, Joshua Kerievsky e vários outros serão uma constante em The Godclass.

O nome The Godclass é um trocadilho e baseado em um anti-pattern chamado god object ou god class, que descreve um objeto que possui muitas responsabilidades. Normalmente aplicações que possuem esses tipos de objetos possuem um forte acoplamento e uma dependência tão grande desses objetos que qualquer modificação, por menor que seja, pode comprometer toda a estrutura da aplicação, afetando áreas que não deveriam estar diretamente ligadas à essa modificação.

Basear em um anti-pattern para discutir padrões e princípios em códigos orientados a objetos foi uma escolha bastante simples: É mais comum ver códigos que "violam" algum princípio de design do que ver códigos que seguem algum tipo de princípio ou padrão.

As análises dos códigos reais serão feitas seguindo o seguinte padrão:

Texto livre, com o ponto de vista do autor, sobre um tema cabível ao contexto.

Código real, sem modificações, exceto aquelas que possam conter qualquer informação privativa ou identificativa e que poderiam comprometer de qualquer forma o autor do código original.

Descrição do(s) problema(s) identificado(s).

Escrita de testes.

Execução dos testes.

Refatoração do código.

Execução dos testes.

Os passos 6 e 7 serão executados ciclicamente até que se alcance um nível de refatoração do código esperado pelo o tema abordado.

O novo código, refatorado, é postado na íntegra.

Texto livre, com o ponto de vista do autor, descrevendo as consequências da refatoração feita no código.

Todo o conteúdo de The Godclass baseia-se em grandes autores, mas é importante que o leitor saiba que as conclusões tiradas em cada uma das postagens são de origem pessoal. O leitor deverá fazer uma leitura crítica e decidir quando determinado conteúdo é válido para seu caso e se ele vale a pena ser empreendido.

Se você gosta de orientação a objetos, seja bem vindo. Sinta-se livre para questionar, esse é um espaço para discussões sobre orientação a objetos e crescimento mútuo.