Upgrade to Pro — share decks privately, control downloads, hide ads and more …

WordPress: To OOP or not to OOP

WordPress: To OOP or not to OOP

Thoughts on incremental structure in larger software projects, the WordPress community, and few OOP examples

75fb365927cb3f5f7b677682d6249406?s=128

Nikolay Bachiyski

October 06, 2013
Tweet

Transcript

  1. To OOP or not to OOP Nikolay Bachiyski, WordCamp Europe

    2013
  2. Nikolay

  3. Automattic

  4. http://extrapolate.me/ @nikolayb github://nb

  5. Next 25 minutes:

  6. 0.Why should we care?

  7. 1. How WordPress developers see OOP

  8. 2. Better OOP

  9. 0. Why should we care?

  10. WordPress is BIG

  11. None
  12. 120K Lines of PHP

  13. Needs some structure Lines of PHP

  14. Structure

  15. No Structure

  16. Not many rules

  17. Each small piece is easy to understand

  18. Hard to change & improve

  19. Impossible to understand deeply

  20. None
  21. None
  22. Structure = Modules + Communication

  23. None
  24. None
  25. None
  26. None
  27. None
  28. Structure → Code

  29. Choices in PHP: Procedural and OOP

  30. Procedural

  31. ↑ Perceived simplicity

  32. ↓ Hard to hide implementation

  33. ↓ Prefix all the things (<5.3)

  34. ↓ Data sharing using globals only

  35. ↓ Hard to test

  36. OOP

  37. ↓ Perceived complicatedness

  38. 1. How WordPress developers see OOP

  39. A big reason WP is so popular is because it

    is not infatuated with the latest, greatest developer lust objects… “
  40. One of the biggest problems I've found with OOP is

    that it forces the developer to bake in structure long before the developer actually understands what that structure should be… “
  41. Classes==Good

  42. OOP == Bad

  43. ?

  44. One of the biggest problems I've found with OOP is

    that it forces the developer to bake in structure long before the developer actually understands what that structure should be… “
  45. One of the biggest problems I've found with OOP is

    that it forces the developer to bake in structure long before the developer actually understands what that structure should be… “
  46. Forces = always happens?

  47. Building Useful Abstractions is HARD

  48. Very Hard

  49. Either refuse responsibility

  50. Or try

  51. Fail

  52. Learn

  53. None
  54. Try again

  55. Fail better

  56. None
  57. Succeed

  58. None
  59. OOP can be good

  60. Do one thing, do it well

  61. None
  62. None
  63. class WP_Screen { function get( $hook_name = '' ); function

    set_current_screen(); function in_admin( $admin = null ); function add_old_compat_help( $screen, $help ); function set_parentage( $parent_file ); function add_option( $option, $args = array() ); function get_option( $option, $key = false ); function get_help_tabs(); function get_help_tab( $id ); function add_help_tab( $args ); function remove_help_tab( $id ); function remove_help_tabs(); function get_help_sidebar(); function set_help_sidebar( $content ); function get_columns(); function render_screen_meta(); function show_screen_options(); function render_screen_options(); function render_screen_layout(); function render_per_page_options(); }
  64. class WP_Screen { function get( $hook_name = '' ); function

    set_current_screen(); function in_admin( $admin = null ); function add_old_compat_help( $screen, $help ); function set_parentage( $parent_file ); function add_option( $option, $args = array() ); function get_option( $option, $key = false ); function get_help_tabs(); function get_help_tab( $id ); function add_help_tab( $args ); function remove_help_tab( $id ); function remove_help_tabs(); function get_help_sidebar(); function set_help_sidebar( $content ); function get_columns(); function render_screen_meta(); function show_screen_options(); function render_screen_options(); function render_screen_layout(); function render_per_page_options(); }
  65. Responsible for <action> or Represents a <thing>

  66. No And’s, Or’s, or But’s

  67. Short!

  68. The big idea is “messaging” [...] The key in making

    great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. “
  69. Innocuous inheritance

  70. WP_Image_Editor

  71. WP_Image_Editor_Imagick extends WP_Image_Editor

  72. WP_Image_Editor_GD extends WP_Image_Editor

  73. Common logic in all subclasses

  74. if ( ! $this->make_image( $filename, 'imagejpeg', array( $image, $filename, apply_filters(

    'jpeg_quality', $this- >quality, 'image_resize' ) ) ) ) $this->image->setImageCompressionQuality ( apply_filters( 'jpeg_quality', $quality, 'image_resize' ) ); GD: ImageMagick:
  75. GD: ImageMagick: protected function update_size( $width = null, $height =

    null ) { … return parent::update_size( $width, $height ); } protected function update_size( $width = null, $height = null ) { … return parent::update_size( $width, $height ); }
  76. Change in interface = change in every subclass

  77. How to spot?

  78. IS-A vs. HAS-A/USES

  79. Inheritance for reuse

  80. Gravatar widget is a WP Widget ✅✓

  81. ImagickMagick is an Image Editor

  82. WP Image Editor uses ImagickMagick

  83. WP Image Editor uses GD

  84. WP Image Editor has an image

  85. Composition

  86. $this->engine = new WP_Image_Engine_GD(); $this->engine = new WP_Image_Engine_ImageMagick(); $this->image =

    $this->engine->load( $filename ); $new_size = $this->image->update_size();
  87. function save( $filename = null, $mime_type = null ) {

    … $jpeg_quality = apply_filters( 'jpeg_quality', … ); $this->image->save( $filename, $mime_type, array( 'jpeg_quality' => $jpeg_quality ) ); … }
  88. What to remember?

  89. Communication between modules is everything

  90. Structure is hard

  91. We can’t get better without trying and failing first

  92. None
  93. Growing Object-Oriented Software, Guided by Tests http://www.growing-object-oriented-software.com/

  94. ?