[wp-trac] [WordPress Trac] #32470: Abstracting the Widget Classes

[WordPress Trac]

#32470: Abstracting the Widget Classes
------------------------------------+------------------------------
 Reporter:  welcher                 |       Owner:
     Type:  enhancement             |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  Widgets                 |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  dev-feedback has-patch  |     Focuses:
------------------------------------+------------------------------

Comment (by jacobsantos):

 Replying to [comment:18 jdgrimes]:
 > Replying to [comment:17 jacobsantos]:
 >
 > I have to admit that I'm not familiar with using interfaces, so I'm not
 sure what the benefits are here. Maybe you could explain? To me it just
 looks like added layers of complexity without actually reducing the
 bootstrap code plugin devs have to write.

 Right. So I think it will become more clear in a later patch when I
 actually use the interfaces as opposed to just abstracting out some of the
 existing code.

 I'm not sure what layers of complexity would be added. Can you explain a
 little bit more what you don't understand? If it is just simply that you
 don't think adding `implements` is useful, then yes, that should be more
 clear in a later patch. I think that I'm going to remove some of the
 changes to `WP_Widget` and just implement the correct interfaces. I am
 going to still move some of the code out of the `WP_Widget`, but it will
 be less of a concern than methods that could be replaced.

 I'm going to create a new object that is going to just proxy or adapter
 the implementation instead. This implementation will have what I wanted to
 do with `WP_Widget` and remove the need to change `WP_Widget` except for a
 few utility functions that will be moved to a separate class.

 As for reducing the amount of code, that is something I will address. I'm
 still attempting to comprehend the scope of the widgets and I'm still
 breaking out the various parts of the `WP_Widget` class into discrete
 parts. For the most part, I think the only change the default widgets will
 have is that they won't extend `WP_Widget`, they will just implement
 `WP_Widget_ControlInterface`, `WP_Widget_SettingInterface`,
 `WP_Widget_Display_EventInterface` and maybe `WP_Widget_AdminInterface`.
 If it seems like every widget has majority of the methods, then I might
 combine some interfaces. I just like to have small interfaces and
 combining them into larger interfaces rather than have large interfaces
 and try to break them out.

 The goal is to see where common code exists and reuse interfaces wherever
 possible, rather than have over broad interfaces.

 The second purpose and far better reason to have interfaces is creating
 unit tests. Interfaces allow for using dummies, fakes, stubs, and mocks.
 By having smaller interfaces, you can create different test objects that
 have specific purposes. So I can create a dummy that implements
 `WP_Widget_AdminInterface` that doesn't do anything. Or create fakes that
 don't write to the database, but store the changes where they can be
 tested later.

 So while there is going to be quite a bit more code, the advantages will
 be better tests. Also, the advantages will become far more apparent later
 when plugin or theme developers start using the new interfaces. I do fear
 that the knowledge base would perhaps add more frustration than benefit to
 those who don't know how to properly use interfaces. I think those who are
 more experienced will have an extremely fun time.

 I think ultimately, the final implementation is going to add a lot more
 code, but will also allow for much better unit and integration testing. I
 also hope to change the system testing for widgets to better take
 advantage of the changes.

 The entire refactoring has to be taken together, I guess, and I hope you
 understand once I have a more complete implementation.

 > I think maybe what you envision and what @welcher was proposing are two
 different things. I think you're leaning towards a complete rewrite of the
 whole widgets API, while (I think) what @welcher was proposing was just a
 little bit more abstraction/bootstrap in the `WP_Widget` class. I think we
 need to be more specific about the scope of this ticket. I'm not saying
 your scope is necessarily too broad, but I'm not sure that's what the
 original intent was, and maybe these are sort of two different things that
 should be separate tickets. ??

 The scopes are definitely different, but both fit into this ticket. I
 think certain parts of my patch could still be applied to this ticket as a
 base for future tickets. My scope is that, improving `WP_Widget` should
 extend beyond simply adding more methods. It should extend to better tests
 and improved functionality. It is something that I wished I had done when
 `WP_Widget` was first introduced. It has always been a flawed
 implementation and my goal is to improve it to where it hopefully should
 have been when it was first introduced.

 Again, not so much a rewrite, because all of the existing code will still
 be part of the implementation. If you do refactoring correctly, then you
 don't rewrite something as move existing parts around to create something
 that is hopefully better.

 If it is the case that the patch scope is too broad, then I will create a
 new ticket. I think it should still be possible to do what I need to do
 without the code in this ticket's patch. I will still include it to show
 the purpose of the changes.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/32470#comment:19>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform