(Re)pensando a OOP - PHPDay Curitiba 2013

4,066 views
4,033 views

Published on

Nesta palestra temos o objetivo de rever os conceitos e origens da programação orientada a objetos

Published in: Technology
6 Comments
11 Likes
Statistics
Notes
No Downloads
Views
Total views
4,066
On SlideShare
0
From Embeds
0
Number of Embeds
3,345
Actions
Shares
0
Downloads
20
Comments
6
Likes
11
Embeds 0
No embeds

No notes for slide

(Re)pensando a OOP - PHPDay Curitiba 2013

  1. 1. (Re)Pensandoa Orientação a ObjetosLuís Otávio Cobucci Oblonczyk - @lcobucci
  2. 2. Luís Otávio Cobucci Oblonczyk@lcobuccihttp://about.me/lcobucciEvangelista PHPDesenvolvedor desde 2003
  3. 3. Porque repensar?
  4. 4. “Trabalhar com orientação a objetos éfácil, só fazer tudo com classes! “
  5. 5. “Orientação a objetos é a evoluçãoda programação procedural “
  6. 6. Definições
  7. 7. “Orientação a objetos é um paradigmade análise, projeto e programação desistemas de software baseado nacomposição e interação entre diversasunidades de software chamadas deobjetos. “http://pt.wikipedia.org/wiki/Orientação_a_objetos
  8. 8. Um paradigma é um modelo mentalque orienta a forma que seráestruturada uma solução
  9. 9. Um paradigma é um modelo mentalque orienta a forma que seráestruturada uma soluçãoProcedural
  10. 10. Um paradigma é um modelo mentalque orienta a forma que seráestruturada uma soluçãoProceduralFuncional
  11. 11. Um paradigma é um modelo mentalque orienta a forma que seráestruturada uma soluçãoProcedural Orientado a aspectosFuncional
  12. 12. Um paradigma é um modelo mentalque orienta a forma que seráestruturada uma soluçãoProceduralFuncionalOrientado a objetosOrientado a aspectos
  13. 13. A OOP busca tornar o mundo doscomputadores mais próximo darealidade
  14. 14. Bora viajar
  15. 15. Um pouco de história...
  16. 16. Os termos objetos e instânciasforam utilizados por voltadas décadas de 50~60
  17. 17. O conceito formal foi introduzido(nos anos 60) na linguagemde programação Simula 67
  18. 18. Na década de 70 foi lançadaa linguagem Smalltalk,que até hoje é referência
  19. 19. Vantagens e desvantagens
  20. 20. Vantagens
  21. 21. VantagensReutilização
  22. 22. VantagensReutilizaçãoExtensibilidade
  23. 23. VantagensReutilizaçãoExtensibilidadeTestabilidade
  24. 24. VantagensReutilizaçãoExtensibilidadeTestabilidadeProximidade do negócio
  25. 25. Desvantagens
  26. 26. DesvantagensAprendizado
  27. 27. DesvantagensAprendizadoUtilização de recursos
  28. 28. Conceitos básicos
  29. 29. Objeto é a representaçãocomputacional de algo existente
  30. 30. Objeto é a representaçãocomputacional de algo existenteCaracterísticas
  31. 31. Objeto é a representaçãocomputacional de algo existenteCaracterísticas Comportamentos
  32. 32. Objeto é a representaçãocomputacional de algo existenteCaracterísticas ComportamentosEstado
  33. 33. Classe é a descrição do objetoseguindo as regras de sintaxedas linguagens
  34. 34. Classe é a descrição do objetoseguindo as regras de sintaxedas linguagensTipo
  35. 35. namespace LcobucciExamples;class Person{private $name;public function talk($message){echo $message;}}
  36. 36. Instância é a concretizaçãode um objeto (referênciaà memória)
  37. 37. Instância é a concretizaçãode um objeto (referênciaà memória)$luis = new Person();
  38. 38. A visibilidade define a acessibilidadedos atributos e métodos
  39. 39. A visibilidade define a acessibilidadedos atributos e métodosPublic
  40. 40. A visibilidade define a acessibilidadedos atributos e métodosPublic Protected
  41. 41. A visibilidade define a acessibilidadedos atributos e métodosPublic PrivateProtected
  42. 42. A visibilidade define a acessibilidadedos atributos e métodosPublic PrivateProtectedVisibilidade != encapsulamento
  43. 43. Encapsulamento é a técnicade proteger métodos e atributos
  44. 44. Encapsulamento utiliza osmodificadores de visibilidade
  45. 45. Herança é o aproveitamentode métodos e atributos entre tiposdo mesmo contexto
  46. 46. Herança é o aproveitamentode métodos e atributos entre tiposdo mesmo contextoDefinição de sub-tipos
  47. 47. namespace LcobucciExamples;class Person{private $name;public function talk($message){echo $message;}}
  48. 48. namespace LcobucciExamples;class Programmer extends Person{}
  49. 49. A herança permite a alteração decomportamentos
  50. 50. namespace LcobucciExamples;class Programmer extends Person{public function talk($message){parent::talk(md5($message));}}
  51. 51. Abstração é a capacidadede definir comportamentos semsua implementação
  52. 52. Abstração é a capacidadede definir comportamentos semsua implementaçãoClasse abstrata
  53. 53. Abstração é a capacidadede definir comportamentos semsua implementaçãoMétodo abstratoClasse abstrata
  54. 54. Abstração é a capacidadede definir comportamentos semsua implementaçãoMétodo abstratoClasse abstrata Interface
  55. 55. Classes abstratas nunca podemser instanciadas diretamente,é necessário uma classe filha
  56. 56. Métodos abstratos devem serobrigatoriamente implementadospelas classes filhas (a não ser queelas também sejam abstratas)
  57. 57. namespace LcobucciExamples;abstract class Person{private $name;abstract public function talk($message);}
  58. 58. namespace LcobucciExamples;class CommonPerson extends Person{public function talk($message){echo $message;}}
  59. 59. namespace LcobucciExamples;class Programmer extends Person{public function talk($message){echo sha1($message);}}
  60. 60. Interfaces são estruturas quedefinem quais comportamentos osobjetos terão que implementar
  61. 61. Interfaces são estruturas quedefinem quais comportamentos osobjetos terão que implementarSempre públicos
  62. 62. namespace LcobucciExamples;interface PaymentMethod{public function pay($value);}
  63. 63. namespace LcobucciExamples;class CreditCard implements PaymentMethod{public function pay($value){// paga usando cartão de crédito}}
  64. 64. namespace LcobucciExamples;class Money implements PaymentMethod{public function pay($value){// paga usando dinheiro}}
  65. 65. Polimorfismo é a possibilidade deum método ter comportamentosdiferentesPossibilitado através da abstração
  66. 66. namespace LcobucciExamples;class Item{private $price;public function sell($quantity, PaymentMethod $paymentMethod){$paymentMethod->pay($this->price * $quantity);}}
  67. 67. namespace LcobucciExamples;class Item{private $price;public function sell($quantity, PaymentMethod $paymentMethod){$paymentMethod->pay($this->price * $quantity);}}
  68. 68. Construtores são responsáveispor definir as regras de criaçãode um objeto
  69. 69. Destrutores são responsáveispor definir as regras de destruiçãode um objeto
  70. 70. namespace LcobucciExamples;class PersonList{private $list;public function __construct(){$this->list = array();}}$list = new PersonList();
  71. 71. namespace LcobucciExamples;class PersonList{private $list;public function __destruct(){$this->list = null;}}$list = new PersonList();$list = null;
  72. 72. Erros comuns
  73. 73. namespace LcobucciExamples;class Pessoa{private $name;}Mistura de idiomas
  74. 74. namespace LcobucciExamples;class Pessoa{private $nome;}Devs felizes : )
  75. 75. namespace LcobucciExamples;class Passaro{public function voa(){}}class Aviao extends Passaro{}Avião voa, mas não é um pássaro...
  76. 76. O que posso estudar no futuro?
  77. 77. Orientação a objetos
  78. 78. Orientação a objetosGerenciamento de exceptions
  79. 79. Orientação a objetosSingle responsabilityGerenciamento de exceptions
  80. 80. Orientação a objetosGerenciamento de exceptionsSingle responsabilityOpen/closed
  81. 81. Orientação a objetosGerenciamento de exceptionsLiskov substitutionSingle responsabilityOpen/closed
  82. 82. Orientação a objetosGerenciamento de exceptionsLiskov substitutionSingle responsabilityOpen/closedInterface segragation
  83. 83. Orientação a objetosGerenciamento de exceptionsLiskov substitutionSingle responsabilityOpen/closedInterface segragationDependency inversion
  84. 84. Orientação a objetosGerenciamento de exceptionsLiskov substitutionSingle responsabilityOpen/closedInterface segragationDependency inversionDesign Patterns
  85. 85. Orientação a objetosGerenciamento de exceptionsLiskov substitutionSingle responsabilityOpen/closedInterface segragationDependency inversionDesign PatternsDomain driven design
  86. 86. Luís Otávio Cobucci Oblonczyk@lcobuccihttp://about.me/lcobucciObrigado!http://slideshare.net/lcobucci

×