Java: Wird Refactoring/Decoupling verwendet, wenn nur eine Klasse die neue Klasse verwendet?

Question

Code:

public class Name { 

private String[] name; 
private String first; 
private String middle; 
private String last; 
private String suffix; 


public Name (String fullName) { 
    //Name is parsed in constructor 
    parse1(); 
    parse2(); 
    parse3(); 
    //invoking more parse methods... 
} 

private void parse1() {} 
private void parse2() {} 
private void parse3() {} 
//more parse methods... 

Diese Methoden unter dem Konstruktor helfen, die fullName zu analysieren. Ich möchte diese parse#() Methoden in eine andere Klasse verschieben, sagen NameHelper.class und alles dort public static machen, aber etwas in mir sagt, dass es sinnlos ist Refactor so, da nicht andere Klasse aber Name wird es verwenden.

Ich möchte umgestalten, denn später wäre dies wirklich schwierig zu Unit-Test. Aber ich möchte das Testen nicht mit Leichtigkeit und schlechtem Code-Refactoring opfern, weil ich immer PowerMockito verwenden könnte, um Privatdetektive zu testen.

Answer 1

Eine Sache, die immer hilft, ist in Verantwortlichkeiten. Ein Name ist vor allem ... ein Name.

Parsen Strings, um einen Namen für mich zu erstellen sieht aus wie eine Verantwortung, die nicht unbedingt in diesem Namen gehören. Es ist eher eine assoziierte "Helfer" oder vielleicht "Service" -Funktionalität.

In diesem Sinne, erstellen Sie einfach das Paket geschützte zusätzliche Klasse und verschieben Sie den Parsing-Code dort.

Aber für das Protokoll: Ich würde nicht Dinge privat machen dann an den Powermock Hammer, um es getestet zu bekommen. Vor allem Code, der wirklich auf Input/Output basiert; Warum solltest du überhaupt spotten?

Was ich meine: das klingt wie Sie ingo Strings haben, und als Ergebnis erhalten Sie einige Name-Objekt. Also: Ihre Komponententests haben einige Test-Eingabedaten, instanziieren diesen NameParserService; und dann auf korrekte Ausgabe prüfen. Keine Notwendigkeit für irgendeine Art von Spott dabei!

Answer 2

Wenn Sie glauben, dass Ihr Code besser ist, Refaktor. Ich kann keinen Grund sehen, sie nicht in eine andere Klasse zu legen. Es kann es auch lesbarer machen. Wenn Sie nicht versuchen, zu den Instanzvariablen zu gelangen, müssen Sie diese Methoden nicht dort einfügen. Sie möchten sie möglicherweise schützen und in das gleiche Paket oder den standardmäßigen (packet-private) Zugriff einfügen.