Isso realmente depende. Se os valores em que seus ajudantes operam são primitivos, então os métodos estáticos são uma boa escolha, como Péter apontou.
Se eles são complexos, então SOLID se aplica, mais especificamente, o S , o eu e o < href="http://en.wikipedia.org/wiki/Dependency_inversion_principle"> D .
Exemplo:
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();
}
}
Isso seria sobre o seu problema. Você pode tornar makeEveryBodyAsHappyAsPossible um método estático, que receberá os parâmetros necessários. Outra opção é:
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]);
}
}
Agora, OurHouse não precisa saber sobre as complexidades das regras de distribuição de cookies. Só deve agora um objeto, que implementa uma regra. A implementação é abstraída em um objeto, cuja única responsabilidade é aplicar a regra. Este objeto pode ser testado isoladamente. OurHouse pode ser testado usando apenas uma simulação do CookieDistributor . E você pode facilmente decidir alterar as regras de distribuição de cookies.
No entanto, tome cuidado para não exagerar. Por exemplo, ter um sistema complexo de 30 classes agem como a implementação de CookieDistributor , onde cada classe apenas cumpre uma pequena tarefa, realmente não faz sentido. Minha interpretação do SRP é que ele não apenas dita que cada classe pode ter apenas uma responsabilidade, mas também que uma única responsabilidade deve ser executada por uma única classe.
No caso de primitivos ou objetos que você usa como primitivos (por exemplo, objetos representando pontos no espaço, matrizes ou algo assim), as classes auxiliares estáticas fazem muito sentido. Se você tiver a escolha e realmente fizer sentido, poderá considerar a possibilidade de adicionar um método à classe que representa os dados, por exemplo, É sensato que um Point tenha um método add . Mais uma vez, não exagere.
Então, dependendo do seu problema, existem diferentes maneiras de fazer isso.