Це дійсно залежить. Якщо значення, на які діють ваші помічники, - примітиви, то статичний метод - хороший вибір, як зазначив Петер.
Якщо вони є складними, то SOLID застосовується, більш конкретно, S , в I і D .
Приклад:
class CookieJar {
function takeCookies(count:Int):Array<Cookie> { ... }
function countCookies():Int { ... }
function ressuplyCookies(cookies:Array<Cookie>
... // lot of stuff we don't care about now
}
class CookieFan {
function getHunger():Float;
function eatCookies(cookies:Array<Cookie>):Smile { ... }
}
class OurHouse {
var jake:CookieFan;
var jane:CookieFan;
var cookies:CookieJar;
function makeEveryBodyAsHappyAsPossible():Void {
//perform a lot of operations on jake, jane and the cookies
}
public function cookieTime():Void {
makeEveryBodyAsHappyAsPossible();
}
}
Це стосується вашої проблеми. Ви можете зробити makeEveryBodyAsHappyAsPossibleстатичний метод, який прийме необхідні параметри. Ще один варіант:
interface CookieDistributor {
function distributeCookies(to:Array<CookieFan>):Array<Smile>;
}
class HappynessMaximizingDistributor implements CookieDistributor {
var jar:CookieJar;
function distributeCookies(to:Array<CookieFan>):Array<Smile> {
//put the logic of makeEveryBodyAsHappyAsPossible here
}
}
//and make a change here
class OurHouse {
var jake:CookieFan;
var jane:CookieFan;
var cookies:CookieDistributor;
public function cookieTime():Void {
cookies.distributeCookies([jake, jane]);
}
}
Тепер OurHouseне потрібно знати про тонкощі правил розповсюдження файлів cookie. Це повинен бути лише об'єкт, який реалізує правило. Реалізація абстрагується від об'єкта, який несе єдину відповідальність - застосувати правило. Цей об'єкт може бути випробуваний ізольовано. OurHouseможна перевірити за допомогою простого макету CookieDistributor. І ви можете легко вирішити змінити правила розповсюдження файлів cookie.
Однак подбайте про те, щоб ви не перестаралися. Наприклад, наявність складної системи з 30 класів виступає як реалізація CookieDistributor, коли кожен клас просто виконує крихітне завдання, насправді не має сенсу. Моя інтерпретація СРП полягає в тому, що вона не лише диктує, що кожен клас може мати лише одну відповідальність, але також і те, що за один клас повинна відповідати одна відповідальність.
Що стосується примітивів чи об'єктів, які ви використовуєте як примітиви (наприклад, об’єкти, що представляють точки у просторі, матриці чи щось таке), статичні класи помічників мають багато сенсу. Якщо у вас є вибір, і це дійсно має сенс, тоді ви можете насправді розглянути можливість додавання методу до класу, що представляє дані, наприклад, для a Pointмає сенс мати addметод. Знову ж таки, не перестарайтеся.
Тож залежно від вашої проблеми існують різні способи її вирішення.