Duplicate code is one of the most pungent code smells. A rule that is often used is to re-structure code once it is duplicated in three or more places.
Common duplication problems, and corresponding solutions are:
Complex classes like Jetpack_Admin_Page often do a lot of different things. To break such a class down, we need to identify a cohesive component within that class. A common approach to find such a component is to look for fields/methods that share the same prefixes, or suffixes. You can also have a look at the cohesion graph to spot any un-connected, or weakly-connected components.
Once you have determined the fields that belong together, you can apply the Extract Class refactoring. If the component makes sense as a sub-class, Extract Subclass is also a candidate, and is often faster.
While breaking up the class, it is a good idea to analyze how other classes use Jetpack_Admin_Page, and based on these observations, apply Extract Interface, too.
1 | <?php |
||
4 | abstract class Jetpack_Admin_Page { |
||
5 | // Add page specific actions given the page hook |
||
6 | abstract function add_page_actions( $hook ); |
||
7 | |||
8 | // Create a menu item for the page and returns the hook |
||
9 | abstract function get_page_hook(); |
||
10 | |||
11 | // Enqueue and localize page specific scripts |
||
12 | abstract function page_admin_scripts(); |
||
13 | |||
14 | // Render page specific HTML |
||
15 | abstract function page_render(); |
||
16 | |||
17 | /** |
||
18 | * Should we block the page rendering because the site is in IDC? |
||
19 | * @var bool |
||
20 | */ |
||
21 | static $block_page_rendering_for_idc; |
||
22 | |||
23 | /** |
||
24 | * Function called after admin_styles to load any additional needed styles. |
||
25 | * |
||
26 | * @since 4.3.0 |
||
27 | */ |
||
28 | function additional_styles() {} |
||
29 | |||
30 | function __construct() { |
||
36 | |||
37 | function add_actions() { |
||
71 | |||
72 | function admin_head() { |
||
87 | |||
88 | // Render the page with a common top and bottom part, and page specific content |
||
89 | function render() { |
||
97 | |||
98 | function admin_help() { |
||
101 | |||
102 | function admin_page_load() { |
||
106 | |||
107 | function admin_page_top() { |
||
110 | |||
111 | function admin_page_bottom() { |
||
114 | |||
115 | // Add page specific scripts and jetpack stats for all menu pages |
||
116 | function admin_scripts() { |
||
120 | |||
121 | // Enqueue the Jetpack admin stylesheet |
||
122 | function admin_styles() { |
||
129 | |||
130 | /** |
||
131 | * Checks if WordPress version is too old to have REST API. |
||
132 | * |
||
133 | * @since 4.3 |
||
134 | * |
||
135 | * @return bool |
||
136 | */ |
||
137 | function is_wp_version_too_old() { |
||
141 | |||
142 | /** |
||
143 | * Checks if REST API is enabled. |
||
144 | * |
||
145 | * @since 4.4.2 |
||
146 | * |
||
147 | * @return bool |
||
148 | */ |
||
149 | function is_rest_api_enabled() { |
||
158 | |||
159 | /** |
||
160 | * Checks the site plan and deactivates modules that were active but are no longer included in the plan. |
||
161 | * |
||
162 | * @since 4.4.0 |
||
163 | * |
||
164 | * @param $page |
||
165 | * |
||
166 | * @return array |
||
167 | */ |
||
168 | function check_plan_deactivate_modules( $page ) { |
||
222 | } |
||
223 |
In PHP it is possible to write to properties without declaring them. For example, the following is perfectly valid PHP code:
Generally, it is a good practice to explictly declare properties to avoid accidental typos and provide IDE auto-completion: