Это действительно зависит. Если значения, с которыми работают ваши помощники, являются примитивами, то статические методы - хороший выбор, как отметил Петер.
Если они являются сложными, то 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, где каждый класс просто выполняет крошечную задачу, на самом деле не имеет смысла. Моя интерпретация SRP заключается в том, что он не только диктует, что каждый класс может иметь только одну ответственность, но также и то, что один класс должен нести одну ответственность.
В случае примитивов или объектов, которые вы используете как примитивы (например, объекты, представляющие точки в пространстве, матрицы или что-то еще), статические вспомогательные классы имеют большой смысл. Если у вас есть выбор, и он действительно имеет смысл, тогда вы можете подумать о добавлении метода в класс, представляющий данные, например, целесообразно Pointиметь addметод. Опять же, не переусердствуйте.
Таким образом, в зависимости от вашей проблемы, есть разные способы решения этой проблемы.