Pytanie Ogólna klasa par


Po prostu próbuję odpowiedzieć na to pytanie, które znalazłem w poprzednim artykule do egzaminu, aby móc przygotować się do zbliżającego się egzaminu Java.

Podaj ogólną parę klas do reprezentowania par rzeczy. Klasa powinna zapewniać konstruktor, metodę uzyskiwania pierwszego elementu pary, metodę uzyskiwania drugiego elementu pary, metodę ustawiania pierwszego elementu pary, sposób ustawiania drugiego elementu pary . Klasa powinna być sparametryzowana na dwa typy jeden dla pierwszego członka i jeden dla drugiego członka pary.

Czy jest to poprawna implementacja tego pytania?

public class Pair<firstThing, secondThing>{
   private firstThing first;//first member of pair
   private secondThing second;//second member of pair

   public Pair(firstThing first, secondThing second){
     this.first = first;
     this.second = second;
   }

   public void setFirst(firstThing first){
    this.first = first;
   }

   public void setSecond(secondThing second) {
     this.second = second;
   }

   public thing getFirst() {
     return this.first;
   }

   public thing getSecond() {
     return this.second;
   }
}

11
2018-05-18 12:50


pochodzenie


Jeśli edytujesz pytanie, zaznacz zmiany. Odpowiedzi stają się mylące, gdy tego nie robisz. - Jan Zyka
Nie być snurkiem, ale po angielsku "para" ogólnie oznacza dwie rzeczy, które są podobne (ten sam typ). Termin CS dla tego, co opisujesz, to "krotka". - CPerkins
@CPerkins: Zawsze tak myślałem para jest po prostu kolejnym słowem 2-krotna. - Paŭlo Ebermann
@ Paŭlo: Wystarczająco fair. - CPerkins
Jak zauważył Boris, poborcy są całkowicie złamani. Obie thing jako zmienną i thing ponieważ typ zwrotu jest nieprawidłowy. public firstThing getFirst() { return this.first; } - Kobor42


Odpowiedzi:


Prawie. Napisałbym to tak:

public class Pair<F, S> {
    private F first; //first member of pair
    private S second; //second member of pair

    public Pair(F first, S second) {
        this.first = first;
        this.second = second;
    }

    public void setFirst(F first) {
        this.first = first;
    }

    public void setSecond(S second) {
        this.second = second;
    }

    public F getFirst() {
        return first;
    }

    public S getSecond() {
        return second;
    }
}

Edytuj: Zgadzam się z komentarzem @ karmakaze. Kod powinien pominąć seterów i zrobić pierwszy i drugi finał, aby zachować go niezmiennym.


17
2018-05-18 13:04



Generalnie stałbym się niezmienny bez "ustawionych" metod. - karmakaze
Czy możesz wyjaśnić różnicę między twoim kodem a kodem OP? - einpoklum
Nie ma wielkiej różnicy, poza tym standardowa konwencja java dla nazwy typu jest pojedynczą wielką literą (F i S w tym przykładzie) i że gettery zwracają typowane wartości tego typu. Ale znowu, jak powiedział @karmakaze, powinienem był dokonać ostatecznych zmiennych i nie mieć ustawników. - Claes Mogren


Potrzeba klasy Pair zwykle pojawia się w większych projektach - mam zamiar (ponownie) zaimplementować jeden dla bieżącego projektu (ponieważ poprzednie implementacje nie są dostępne).

Generalnie sprawiam, że jest to niezmienne POJO, z wygodną funkcją do tworzenia instancji. Na przykład:

public class Pair<T,U>
{
    public final T first;
    public final U second;
    public static <T,U> Pair<T,U> of(T first, U second);
}

Aby użytkownik końcowy mógł napisać:

return Pair.of (a, b);

i

Pair<A,B> p = someThing ();
doSomething (p.first);
doSomethingElse (p.second);

Jak wspomniano powyżej, klasa Pair powinna również zaimplementować funkcję hashCode (), equals (), opcjonalnie-ale-użyteczną toString (), jak prawdopodobnie clone () i compareTo () do użycia, gdy są one obsługiwane przez T i U - choć dodatkowa praca jest wymagany, aby opisać, w jaki sposób umowy te są obsługiwane przez klasę Pair.


10
2017-09-23 12:11





Możesz zajrzeć do implementacji standardowych klas Java AbstractMap.SimpleEntry i AbstractMap.SimpleImmutableEntry. Łatwo jest znaleźć źródła Google:


5
2018-04-18 17:15



Prawdopodobnie możemy ich użyć, ale są one przeznaczone do użycia w Mapach. Nie powinniśmy mieć klucza i wartości w parze. - Akira Yamamoto


Oto implementacja z zestawu SDK systemu Android

/**
 * Container to ease passing around a tuple of two objects. This object provides a sensible
 * implementation of equals(), returning true if equals() is true on each of the contained
 * objects.
 */
public class Pair<F, S> {
    public final F first;
    public final S second;

    /**
     * Constructor for a Pair.
     *
     * @param first the first object in the Pair
     * @param second the second object in the pair
     */
    public Pair(F first, S second) {
        this.first = first;
        this.second = second;
    }

    /**
     * Checks the two objects for equality by delegating to their respective
     * {@link Object#equals(Object)} methods.
     *
     * @param o the {@link Pair} to which this one is to be checked for equality
     * @return true if the underlying objects of the Pair are both considered
     *         equal
     */
    @Override
    public boolean equals(Object o) {
        if (!(o instanceof Pair)) {
            return false;
        }
        Pair<?, ?> p = (Pair<?, ?>) o;
        return Objects.equal(p.first, first) && Objects.equal(p.second, second);
    }

    /**
     * Compute a hash code using the hash codes of the underlying objects
     *
     * @return a hashcode of the Pair
     */
    @Override
    public int hashCode() {
        return (first == null ? 0 : first.hashCode()) ^ (second == null ? 0 : second.hashCode());
    }

    /**
     * Convenience method for creating an appropriately typed pair.
     * @param a the first object in the Pair
     * @param b the second object in the pair
     * @return a Pair that is templatized with the types of a and b
     */
    public static <A, B> Pair <A, B> create(A a, B b) {
        return new Pair<A, B>(a, b);
    }
}

5
2017-09-03 07:43



IMHO w tej implementacji <A, null> .hasCode () == <null, A> .hashCode (), natomiast równe poprawnie sprawdza 1. kontra 1, 2 kontra 2. - Gavriel


Myślę, że nie. Cytat:

"klasa powinna być sparametryzowana   przez dwa typy ... "

Myślę, że oczekują w kategoriach:

public class Pair<ThingA, ThingB>

3
2018-05-18 12:54



Myślę, że naprawiłem to teraz, och, z wyjątkiem wielkiej litery dla nazw typów. Czy teraz jest poprawny? - John Curtsy
zwracaj typy getFirst i getSecond - Jan Zyka
add wskaż jan, metody getFirst / getSecond wciąż zwracają "rzecz" - Suraj Chandran


Zwykle występuje typowy typ Pary dwa parametry rodzajowe, a nie jedno - możesz mieć (powiedzmy) a Pair<String, Integer>. Jest to zazwyczaj bardziej przydatne, IMO.

Sugerowałbym również, abyś myślał o bardziej konwencjonalnej nazwie dla twojego parametru typu niż "rzecz". Na przykład możesz użyć Pair<A, B> lub Pair<T, U>.


2
2018-05-18 12:54





Getters są zepsute

public thing getFirst() {
  return thing.first;
}

public thing getSecond() {
  return thing.second;
}

thing należy zastąpić przez this


2
2018-05-18 12:56