Frage

getEmployeeNameByBatchId(int batchID)
getEmployeeNameBySSN(Objekt SSN)
getEmployeeNameByEmailId(String emailID)
getEmployeeNameBySalaryAccount(SalaryAccount salaryAccount)

oder

getEmployeeName(int typeOfIdentifier, byte[] id) -> In diesem Verfahren die typeOfIdentifier sagt, wenn Bezeichner ist batchID/SSN/emailID/salaryAccount

Welches der oben genannten ist besser Art und Weise implementieren, die eine get-Methode?

Diese Methoden werden in einem Servlet und Anrufe würden gemacht werden von einer API, die zur Verfügung gestellt würden, um die Kunden.

War es hilfreich?

Lösung

Warum nicht überlast die getEmployeeName(??) Methode?

getEmployeeName(int BatchID)
getEmployeeName(Objekt SSN)(schlechte Idee)
getEmployeeName(String Email)
etc.

Scheint eine gute viele ' Ansatz für mich.

Andere Tipps

Sie könnte so etwas wie, dass:

interface Employee{
    public String getName();
    int getBatchId();
}
interface Filter{
    boolean matches(Employee e);
}
public Filter byName(final String name){
    return new Filter(){
        public boolean matches(Employee e) {
            return e.getName().equals(name);
        }
    };
}
public Filter byBatchId(final int id){
    return new Filter(){
        public boolean matches(Employee e) {
            return e.getBatchId() == id;
        }
    };
}
public Employee findEmployee(Filter sel){
    List<Employee> allEmployees = null;
    for (Employee e:allEmployees)
        if (sel.matches(e))
            return e;
    return null;
}
public void usage(){
    findEmployee(byName("Gustav"));
    findEmployee(byBatchId(5));
}

Wenn Sie die Filterung, indem Sie eine SQL-Abfrage verwenden Sie die Filter Schnittstelle zum verfassen einer WHERE-Klausel.

Das gute an diesem Ansatz ist, dass Sie können kombinieren Sie zwei Filter, die bequem mit:

public Filter and(final Filter f1,final Filter f2){
    return new Filter(){
        public boolean matches(Employee e) {
            return f1.matches(e) && f2.matches(e);
        }
    };
}

und benutze es so:

findEmployee(and(byName("Gustav"),byBatchId(5)));

Was Sie bekommen, ist ähnlich wie die Criteria API, die in Hibernate.

Ich würde gehen mit der "N" - Ansatz.Es scheint, mehr intuitive zu mir und weniger anfällig für Fehler.

Ich weiß nicht, wie getXByY() - das könnte cool sein in PHP, aber ich weiß einfach nicht, wie es in Java (ymmv).

Ich würde gehen mit überlastung, es sei denn, Sie haben die Eigenschaften des gleichen Datentyps.In diesem Fall würde ich etwas ähnliches tun, um Ihre zweite option, aber anstelle von ints, die ich verwenden würde, ein Enum für die Typ-Sicherheit und Klarheit.Und anstelle von byte[], würde ich mit dem Objekt - (da autoboxing, dies funktioniert auch für primitive Typen).

Die Methoden sind das perfekte Beispiel für die Verwendung von überlastung.

getEmployeeName(int batchID)
getEmployeeName(Object SSN)
getEmployeeName(String emailID)
getEmployeeName(SalaryAccount salaryAccount)

Wenn die Methoden haben gemeinsame Verarbeitung innen, schreiben Sie einfach eine weitere getEmplyeeNameImpl (...), und extrahieren Sie es, die gemeinsamen code, um Doppelarbeit zu vermeiden

Erste option, keine Frage.Explizit genannt werden.Es wird stark Beihilfen im Wartbarkeit und es gibt wirklich keinen Nachteil.

@Stephan:es ist schwer zu überlasten einem Fall wie diesem (im Allgemeinen), weil der parameter-Typen möglicherweise nicht diskriminierend, z.B.,

  • getEmployeeNameByBatchId(int batchId)
  • getEmployeeNameByRoomNumber(int roomNumber)

Siehe auch die beiden Methoden getEmployeeNameBySSN, getEmployeeNameByEmailId in dem ursprünglichen Beitrag.

Ich werden verwenden Sie die explizite Methode-Namen.Jeder, der behauptet, dass code und mich später verstehen, was diese Methode tut, ohne zu schreiben, die xml-Kommentare.

Manchmal kann es mehr praktisch zu verwenden Muster-Spezifikation.

ZB:GetEmployee(ISpecification<Employee> Spezifikation)

Und dann starten Sie definieren Ihre Spezifikationen...

NameSpecification :ISpecification<Employee>
{
private string name;
öffentliche NameSpecification(string name) { this.name = name;}
public bool IsSatisFiedBy(Employee employee) { return employee.Name == this.name;}
}

NameSpecification spec = new NameSpecification("Tim");
Mitarbeiter tim = MyService.GetEmployee(spec);

Ich würde die erste option verwenden, oder überlast, die es in diesem Fall, zu sehen, wie Sie haben 4 verschiedene parameter-Signaturen.Jedoch, spezifisch hilft, den code zu verstehen, die 3 Monate ab jetzt.

Die Logik ist, die in jedem von diesen Methoden weitgehend die gleichen?

Wenn ja, ist die einzige Methode, mit der id-parameter kann mehr Sinn machen (einfach und reduzieren die wiederholten code).

Wenn die Logik/Verfahren variieren stark zwischen den Arten, eine Methode pro Typ können bevorzugt werden.

Wie andere vorgeschlagen, die erste option zu sein scheint, die gute.Die zweite könnte Sinn machen, wenn Sie Sie schreiben einen code, aber wenn jemand kommt später, ist es schwieriger, herauszufinden, wie man code.( Ich weiß, haben Sie Kommentare, und Sie können immer tief in den code, aber GetemployeeNameById ist mehr selbsterklärend)

Hinweis:Btw, die Verwendung von Enums vielleicht etwas zu überlegen, in einigen Fällen.

Im trivialen Fall wie diesem, würde ich gehen mit überlastung., Dass ist:

getEmployeeName( int batchID );
getEmployeeName( Object SSN );

etc.

Nur in besonderen Fällen, würde ich das argument geben Sie den Namen der Methode, D. H.wenn Sie die Art von argument ist schwer zu bestimmen, wenn es mehrere Typen von Argumenten tha hat den gleichen Datentyp (batchId und Personal, die beide int), oder wenn die Methoden für das abrufen der Mitarbeiter radikal anders für jedes argument geben.

Ich kann nicht sehen, warum würde ich dies jemals verwendet

getEmployeeName(int typeOfIdentifier, byte[] identifier)

wie es erfordert sowohl angerufene und der Anrufer zu werfen, den Wert basierend auf typeOfIdentifier.Bad design.

Wenn Sie schreiben, die Frage die man sich am Ende Fragen:

"SELECT name FROM ..."
"SELECT SSN FROM ..."
"WÄHLEN Sie E-Mail AUS ..."
vs.
"SELECT * FROM ..."

Und ich denke, die Antwort ist einfach und jeder kennt es.

Was passiert, wenn Sie ändern die Employee-Klasse?E. g.:Sie haben zu entfernen die E-Mail und fügen Sie einen neuen filter wie-Abteilung.Mit der zweiten Lösung, die Sie haben, eine große Gefahr nicht zu bemerken Fehler, wenn Sie ändern Sie einfach die Reihenfolge der int identifier "Konstanten".Mit der ersten Lösung, die Sie immer bemerken, wenn Sie mit der Methode, die in irgendeinem längst vergessenen Klassen, die Sie sonst vergessen zu ändern, um den neuen Bezeichner.

Ich persönlich bevorzuge die explizite Benennung "...ByRoomNumber" denn wenn Sie am Ende mit vielen "überlastung", die Sie letztendlich führen ungewollte Fehler.Wird explizit ist imho der beste Weg.

Ich Stimme mit Stephan:Eine Aufgabe, eine Methode name, selbst wenn Sie das tun können es mehrere Möglichkeiten.Die Methode überladen Funktion versehen war genau für Ihren Fall.

  • getEmployeeName(int BatchID)
  • getEmployeeName(String Email)
  • etc.

Und vermeiden Ihre zweite Lösung, bei der alle Kosten.Es riecht wie "dein olde void * C".Ebenso, vorbei an einem Java - "Objekt" ist fast so, als schlechter Stil, wie ein C "void *".

Wenn Sie ein gutes design sollten Sie in der Lage sein zu bestimmen, wenn Sie können, verwenden Sie die überladung Ansatz oder wenn Sie laufen in ein problem, wo, wenn Sie überladen wirst du am Ende mit zwei Methoden mit dem gleichen parameter-Typ.

Überladen scheint, wie der beste Weg, zunächst, aber wenn Sie am Ende nicht in der Lage, fügen Sie eine Methode in der Zukunft und Unordnung, Dinge zu benennen, es wird ein Streit.

Persönlich würde ich für den Ansatz einer eindeutigen Namen pro-Methode, so dass Sie nicht laufen in Probleme später mit dem Versuch, um eine überlastung der gleichen parameter-Objekt-Methoden.Auch, wenn jemand extended Ihre Klasse in die Zukunft und umgesetzt anderen void getEmployeeName(String name) es wäre nicht überschreiben Ihnen.

Um zusammenzufassen, gehen Sie mit einer einzigartigen Methode, für jede Methode, eine überlastung kann nur zu Problemen führen, in die lange laufen.

Die Entkopplung zwischen der Suche und der Suche nach Kriterien jrudolf schlägt in seinem Beispiel ist hervorragend.Ich Frage mich, warum ist es nicht die meisten Stimmen Lösung.Vermisse ich etwas?

Ich würde gehen mit Abfrage Von Objekten.Sie funktionieren gut für den Zugriff auf Tabellen direkt.Wenn Sie sind auf gespeicherte Prozeduren, verlieren Sie etwas von Ihrer macht, aber Sie können immer noch es funktioniert.

Die erste ist wahrscheinlich die beste in Java, wenn man bedenkt es ist typesafe (im Gegensatz zu den anderen).Zusätzlich zum "normalen" Typen, der zweite Lösung scheint nur umständlich Verwendung für die Benutzer.Aber, da Sie in der Objekt-als Typ für SSN (die eine semantische Bedeutung jenseits Objekt), werden Sie wahrscheinlich kommen die nicht mit dieser Art von API.

All-in-all, in diesem speziellen Fall habe ich verwendet den Ansatz mit vielen Getter.Wenn alle Bezeichner haben Ihre eigene Klasse geben, ich hätte die zweite route, aber die Umschaltung intern auf Klasse, statt eine zur Verfügung gestellt/application-defined type identifier.

kleben Sie alle Ihre Optionen in eine enum, die so etwas wie die folgenden

GetEmployeeName(Enum identifier)
{
    switch (identifier)
    case eBatchID:
    {
        // Do stuff
    }
    case eSSN:
    {
    }
    case eEmailId:
    {
    }
    case eSalary:
    {
    }
    default:
    {
        // No match
        return 0;
    }
}

enum Identifier
{
    eBatchID,
    eSSN,
    eEmailID,
    eSalary
}

Denken Sie C/C++.

Verwenden Sie Objekte statt mit einem Bezeichner byte (oder int).

Meine Schlecht, der überladung Ansatz ist besser, und die Verwendung der SSN als Primärschlüssel ist nicht so gut

public ??? getEmployeeName(Object obj){

if (obj instanceof Integer){

  ...

} else if (obj instanceof String){

...

} else if .... // and so on


} else throw SomeMeaningFullRuntimeException()

return employeeName
}

Ich denke, es ist besser zu verwenden, Ungeprüften Ausnahmen zu signalisieren fehlerhafte Eingabe.

Dokument, damit der Kunde weiß, welche Objekte zu erwarten.Oder erstellen Sie Ihren eigenen Wrapper.Ich bevorzuge die erste option.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top