Conditions | 3 |
Paths | 3 |
Total Lines | 58 |
Lines | 0 |
Ratio | 0 % |
Changes | 0 |
Small methods make your code easier to understand, in particular if combined with a good name. Besides, if your method is small, finding a good name is usually much easier.
For example, if you find yourself adding comments to a method's body, this is usually a good sign to extract the commented part to a new method, and use the comment as a starting point when coming up with a good name for this new method.
Commonly applied refactorings include:
If many parameters/temporary variables are present:
1 | <?php |
||
182 | public function getHTMLFragments($gridField) |
||
183 | { |
||
184 | Requirements::javascript('silverstripe/blog:client/dist/js/main.bundle.js'); |
||
185 | |||
186 | /** |
||
187 | * @var DataList $dataList |
||
188 | */ |
||
189 | $dataList = $gridField->getList(); |
||
190 | |||
191 | $dataClass = $dataList->dataClass(); |
||
192 | |||
193 | $obj = singleton($dataClass); |
||
194 | |||
195 | if (!$obj->canCreate()) { |
||
196 | return []; |
||
197 | } |
||
198 | |||
199 | $dbField = $this->getDataObjectField(); |
||
200 | |||
201 | $textField = TextField::create( |
||
202 | sprintf( |
||
203 | "gridfieldaddbydbfield[%s][%s]", |
||
204 | $obj->ClassName, |
||
205 | Convert::raw2htmlatt($dbField) |
||
206 | ) |
||
207 | ) |
||
208 | ->setAttribute('placeholder', $obj->fieldLabel($dbField)) |
||
209 | ->addExtraClass('no-change-track'); |
||
210 | |||
211 | if (!$this->buttonName) { |
||
212 | // provide a default button name, can be changed by calling {@link setButtonName()} on this component |
||
213 | $objectName = $obj->i18n_singular_name(); |
||
214 | $this->buttonName = _t(__CLASS__ . '.ButtonName', '{name}', ['name' => $objectName]); |
||
215 | } |
||
216 | |||
217 | $addAction = GridField_FormAction::create( |
||
218 | $gridField, |
||
219 | 'add', |
||
220 | _t( |
||
221 | __CLASS__ . '.Add', |
||
222 | 'Add {name}', |
||
223 | 'Add button text', |
||
224 | ['name' => $this->buttonName] |
||
225 | ), |
||
226 | 'add', |
||
227 | 'add' |
||
228 | ); |
||
229 | $addAction->setAttribute('data-icon', 'add'); |
||
230 | $addAction->addExtraClass('btn btn-primary'); |
||
231 | |||
232 | $forTemplate = ArrayData::create([]); |
||
233 | |||
234 | $forTemplate->Fields = ArrayList::create(); |
||
235 | $forTemplate->Fields->push($textField); |
||
236 | $forTemplate->Fields->push($addAction); |
||
237 | |||
238 | return [$this->targetFragment => $forTemplate->renderWith(self::class)]; |
||
|
|||
239 | } |
||
240 | } |
||
241 |
If you return a value from a function or method, it should be a sub-type of the type that is given by the parent type f.e. an interface, or abstract method. This is more formally defined by the Lizkov substitution principle, and guarantees that classes that depend on the parent type can use any instance of a child type interchangably. This principle also belongs to the SOLID principles for object oriented design.
Let’s take a look at an example:
Our function
my_function
expects aPost
object, and outputs the author of the post. The base classPost
returns a simple string and outputting a simple string will work just fine. However, the child classBlogPost
which is a sub-type ofPost
instead decided to return anobject
, and is therefore violating the SOLID principles. If aBlogPost
were passed tomy_function
, PHP would not complain, but ultimately fail when executing thestrtoupper
call in its body.