Evite singletons e estruturas estáticas em suas aplicações

Transcript

1. Evite singletons e estruturas estáticas em suas aplicações
2. Alguns benefícios da orientação a objetos Tópicos
3. Exemplo de falha na orientação a objetos Tópicos
4. Porque o padrão Singleton não é uma boa decisão de design Tópicos
5. Porque estruturas estáticas não são úteis Tópicos
6. Tópicos E, por fim, algumas soluções
7. De uma forma simplista, orientação a objetos é uma forma de pensar sobre a construção de uma aplicação.
8. O paradigma da orientação a objetos oferece uma série de princípios e conceitos que nos ajudam a pensar de acordo.
9. Reusabilidade de código Maior nível de abstração Facilidade para modelar o domínio do problema Estado e comportamento resultam em objetos Encapsulamento Melhor organização do código Separação de responsabilidades Mantenabilidade Facilidade para evoluir o código em iterações
10. Reusabilidade de código Maior nível de abstração Facilidade para modelar o domínio do problema Estado e comportamento resultam em objetos Encapsulamento Melhor organização do código Facilidade para evoluir o código em iterações Separação de responsabilidades Mantenabilidade
11. Além de “esconder” os atributos e métodos em nossa classe, garantimos a integridade da identidade do objeto. Encapsulamento
12. Getters e setters não tem relação alguma com encapsulamento! Ao contrário, eles o ajudam a violá-lo. Encapsulamento
13. struct Date { int day; int month; int year; }; int main (void) { struct Date today; today.day = 31; today.month = 07; today.year = 2014; }; C
14. class Date { public $day; public $month; public $year; } $today = new Date(); $today->day = 31; $today->month = 07; $today->year = 2014; PHP
15. Todo objeto que permite a alteração do estado através de atribuição de propriedades, chamamos de modelo anêmico. Encapsulamento
16. Os comportamentos que possuíam a responsabilidade de trabalhar com seus atributos não mais a tem. métodos Encapsulamento
17. Desta forma, as regas de negócios se espalham por toda a aplicação e manutenção disso tudo lhe manda um abraço :) Encapsulamento
18. Pois, se tudo o que você precisa são dos dados para realizar algo dentro da sua aplicação, o modelo anêmico te ajuda com isso. Encapsulamento
19. Encapsulamento Por outro lado, quando não permitimos a alteração do estado através de atribuição de propriedades, oferecendo um conjunto de comportamentos, chamamos de modelo rico.
20. Responsabilidades Manter classes coesas, ou seja, que possuam apenas uma responsabilidade.
21. class Board { String board() { StringBuffer buf = new StringBuffer(); for (int i = 0; i < 10; i++) { for (int j = 0; j < 10; j++) { buf.append(data[i][j]); buf.append("\n"); } } return buf.toString(); } }
22. class Board { String board() { collectRows(); } void collectRow() { for (int i = 0; i < 10; i++) collectRows(i); } void collectRows(int row) { for (int i = 0; i < 10; i++) this.buf.append(data[row][i]); this.buf.append("\n"); } }
23. Responsabilidades Desta forma, conseguimos criar classes mais reutilizáveis, menos complexas e que propagam menos mudanças para sua aplicação.
24. Mas, existem, pelo menos, dois erros comuns na implementação do paradigma da orientação a objetos.
25. 1 Entender o funcionamento de um princípio º
26. 2 Entender a ideia de um princípio º
27. class Pessoal extends Animal { ... } Conseguimos obter os atributos e comportamentos Herança
28. class Pessoal extends Animal { ... } Mas, uma pessoa nunca será um animal Herança
29. Substitution Principle Liskov
30. Um dos cinco princípios SOLID. Esse princípio diz que precisamos ter cuidado ao usar herança.
31. Evite os casos de gato-estende- cachorro, apenas por possuírem algo em comum.
32. E, constantemente, mudanças trarão outras complexidades à sua aplicação.
33. E a pior decisão que podemos tomar é adaptar um erro.
35. Static
36. Métodos estáticos de uma classe não podem ser usados por uma instância e nunca são virtuais. Static
37. Não podem ser sobrescritos, pois qualquer referência é resolvida através de early binding e não por late binding. Static
38. class AllSeeingEye { public static function promotingFear() { ... } } Não virtual Static
39. Early binding se dá quando um método a ser invocado é definido durante a compilação da aplicação. Static
40. Late binding se dá quando um método a ser invocado é definido em tempo de execução da aplicação. Static
41. Atributos e métodos estáticos podem ser usados quando não existe dependência com o estado do objeto. Static
42. class Resentful { public static function storeEverything($message) { error_log($message, 3, "memories.log"); } } Static
43. Métodos de classe, ou métodos estáticos, são executados no contexto de seus parâmetros. Static
44. Métodos de instância, além dos parâmetros, são executados no contexto do estado do objeto. Static
45. Então, surge uma pergunta… Static
46. Se na orientação a objetos trabalhamos com estado e comportamento – que resultando em objetos – como estruturas estáticas podem ser úteis?
47. Na verdade, não podem. Precisamos reavaliar a maneira como pensamos à respeito da aplicação. Static
48. "Estou cada vez mais contra o uso de métodos de classe. Eles levam, muitas vezes, a programação procedural.” (Nick Sutterer) Static
49. Métodos estáticos são, na verdade, métodos globais. Static
50. Singleton
51. Em linhas gerais, este padrão oferece uma forma de garantir que existirá uma única instância de uma classe para sua aplicação. Singleton
52. Alguns dizem que o padrão deveria se chamar globalton, anti- pattern. Singleton Kent Beck, Nat Pryce
54. “How do you provide global variables in languages without global variables? Don't. Your programs will thank you for taking the time to think about design instead.” Singleton
55. Exemplo de implementação Singleton
56. class Dumb { public static $instance; private function __construct() { // Não se esqueça que sou privado! :) } public static function getInstance() { if (is_null($instance)) { self::$instance = new Dumb(); } return self::$instance; } }
57. class Dumb { public static $instance; private function __construct() { // Não se esqueça que sou privado! :) } public static function getInstance() { if (is_null($instance)) { self::$instance = new Dumb(); } return self::$instance; } }
58. class Dumb { public static $instance; private function __construct() { // Não se esqueça que sou privado! :) } public static function getInstance() { if (is_null($instance)) { self::$instance = new Dumb(); } return self::$instance; } }
59. class Dumb { public static $instance; private function __construct() { // Não se esqueça que sou privado! :) } public static function getInstance() { if (is_null($instance)) { self::$instance = new Dumb(); } return self::$instance; } }
60. Problemas ao usar este padrão de projeto em sua aplicação. Singleton
61. 1 Estado único º
62. class Dumb { public static $instance; ... } Estado único Singleton
63. Uma classe, dentro de uma aplicação, é única e não pode ser sobrescrita em tempo de execução. Singleton
64. Atributos estáticos pertencem a classe e não são compartilhados com instâncias desta classe. Singleton
65. Sendo assim, estes atributos são capazes de armazenar apenas um único estado, ou seja, uma única atribuição. Singleton
66. Desta forma, há propagação de estado por toda sua aplicação através do uso deste padrão de projeto. Singleton
67. E a única instância que será utilizada em sua aplicação possui estado único. Ou seja, é uma @#% $ completa! Singleton
68. Testabilidade 2º
69. Com estado único, seus testes começarão a chorar. Singleton
70. Manter uma suite de testes de unidade de um classe que implementa Singleton é terrível. Singleton
71. Será necessário adaptações por todo lado, pois dependemos de como será devolvido no teste anterior. Singleton
72. Gerenciamento 3º
73. Se for necessário retornar novas instância de acordo com um exceção, por exemplo, este gerenciamento deve ser implementado por sua própria conta. Singleton
74. Uma única instância para servir minha aplicação?
75. Singleton e estruturas estáticas são semelhantes a variáveis globais.
76. $osC_Database
78. Mas, como podemos substituir essas @#%$?
79. Injeção de dependência
80. class Client { public function procces($data) { $server = Server::getInstance(); $response = $server->sendData($data); } }
81. class Client { private $_server; public Client($server) { $this->_server = $server; } public function procces($data) { $response = $this->_server->sendData($data); } }
82. public function testProcces() { $server = $this->getMock("Server"); $client = new Client($server); $this->assertEquals(5, $client->process($params)); }
83. A classe Server também poderá ser testada à nível de unidade sem as complicações “estáticas”.
84. Resumindo
85. Estude, leia muito e busque sempre as melhores soluções para aplicar no seu contexto. OO?
86. Questione sempre e ofereça outras alternativas. Orientação a objetos é um campo muito rico! OO?
87. The shit has been planted! Injeção de dependência é uma excelente alternativa. Static e singleton?
88. Elimina a propagação de estado e garante maior flexibilidade aos seus testes. Static e singleton?
89. Perguntas?
90. Obrigado!