[Vorstellung] Comparatoren für Arrays

Bitte aktiviere JavaScript!
Falls mal jemand so etwas braucht:

https://github.com/HeinerKuecker/Array-Comparator-Java

Es gibt Comparatoren für

-ein- und mehrdimensionale Arrays

-primitive und Objekt-Arrays

-Comparable-Objekte oder mit dediziertem Comparator.

Null ist entweder verboten, wird am Anfang oder am Ende einsortiert.

Ich vervollständige es noch bis zu 9-dimensionalen Arrays,

alles mit Unit-Test und Javadoc.

Verbesserungsvorschläge sind willkommen.
 
A

Anzeige




Vielleicht hilft dir unser Java-Tutorial hier weiter —> (hier klicken)
Java 11 implementiert diese Möglichkeit schon für 1D-Arrays (Arrays::compare). Du brauchst es nur um die Mehrdimensionalität erweitern. Dazu braucht man aber auch keine x-Klassen sondern nur ein wenig Reflection und Rekursion (siehe Arrays::deepEquals).

Auch solltest du eine Definition von kleiner, größer oder gleich auf deiner Startseite liefern, die Features die deine Lib hat und warum sie genutzt werden sollte.
Use-Cases sollten auch beigesteuert werden.
 
Java 11 implementiert diese Möglichkeit schon für 1D-Arrays (Arrays::compare).
Wusste ich nicht, ich bin noch bei Java8.


Du brauchst es nur um die Mehrdimensionalität erweitern. Dazu braucht man aber auch keine x-Klassen sondern nur ein wenig Reflection und Rekursion (siehe Arrays::deepEquals).
Nun ja, nicht jeder will Reflection in seinem Programm haben.

Von den x Klassen werden für den konkreten Fall wenige/eine benötigt.


Auch solltest du eine Definition von kleiner, größer oder gleich auf deiner Startseite liefern, die Features die deine Lib hat
Das werde ich machen.


und warum sie genutzt werden sollte.
Dient zum Sortieren mehrdimensionaler Arrays (natürlich auch Vergleichen ohne Sortieren).
Ich weiß nicht, wie ich dies weiter vertiefen soll.


Use-Cases sollten auch beigesteuert werden.
Es handelt sich um eine technische Lib, keine fachliche.

Entstanden ist die Idee bei mir, als ich mal Pfade hatte, die Arrays waren, also nicht in einem String mit einem bestimmten Zeichen getrennt.

Die sollten sortiert werden.

Es gab auch mal was mit verbundenen Firmen und deren Niederlassungen, also drei Stufen.

Das ist aber nichts zum Veröffentlichen, ich darf das sicher nicht.

Ansonsten vielen Dank für die Rückmeldung.
 
Zuletzt bearbeitet von einem Moderator:
und warum sie genutzt werden sollte.
Dient zum Sortieren mehrdimensionaler Arrays (natürlich auch Vergleichen ohne Sortieren).
Ich weiß nicht, wie ich dies weiter vertiefen soll.
Man könnte z.B. Beispiele beifügen.
So rein von diesem Thread konnte ich mir nicht vorstellen, worum es eigentlich geht.


Es handelt sich um eine technische Lib, keine fachliche.
Use-Cases gibt es doch hoffentlich trotzdem - du zählst ja sogar selbst welche auf ;)


Verbesserungsvorschläge sind willkommen.
Ohne mir den Code wirklich angeguckt zu haben:

* Warum machst du kein Maven/Gradle-Projekt draus? Fall jemand anders das nutzen soll, ist das deutlich angehöre, als ein Eclipse-Project. ;)

* Ich finde deine Formatierung echt merkwürdig. z.T. sind die Zeilen nach 25 Zeichen umgebrochen, zT nach 100 Zeichen
Java:
   public static <T extends Comparable<T>> ComparableArrayComparator<T> newComparableArrayComparator(
vs.
Java:
        this.elementNulls =
                Objects.requireNonNull(
                        elementNulls ,
                        "elementNulls" );
oder
Java:
/**
* {@link Comparator} for
* one-dimensional arrays
* whose elements are
* {@link Comparable}.

* Da sind Unmengen toter Code, stört (mich zumindest) beim Lesen. Das meiste kann man doch einfach bedenkenlos löschen
Java:
/*
        return
                isFirst ||
                currentElementIndex < allElements.size();
         */
        //throw new RuntimeException( "not implemented" );
        return this.innerIterator.hasNext();

* nicht sicher, ob das öfter vorkommt, aber in mindestens einer Klasse gibts nen öffentlicher Konstruktor und eine öffentliche Fabrikmethode (z.b: newComparableArrayComparator vs ComparableArrayComparator), gibts da 'nen Grund für?

* Builder wären an einigen Stellen sicher ganz nett. So eine Parameterliste ist doch echt hässlich:
(Nulls, Nulls, Nulls, Nulls, Nulls, Comparator<? super T> ), und ließe sich wunderbar mit 'nem Builder ersetzen (bzw ergänzen)

* die beiden compare-Methoden in dim1 sehen für mich ziemlich ähnlich und deutlich zu lang aus - da kann man doch sicher was mit 'nem kleinen Refactoring gewinnen
 
Eigentlich wollte ich nur mal Github ausprobieren, so ein Comparator ist nicht wirklich weltbewegend, aber ich dachte, wenn ich dabei bin, dann doch mit Tests und Javadoc.

Warum machst du kein Maven/Gradle-Projekt draus? Fall jemand anders das nutzen soll, ist das deutlich angehöre, als ein Eclipse-Project.
Eigentlich mag ich weder Maven noch Gradle, ich war immer froh, wenn sich im Projekt jemand anders darum gekümmert hat.

Ich sollte die Gelegenheit nutzen, auf diesem Gebiet besser zu werden.

Ich finde deine Formatierung echt merkwürdig. z.T. sind die Zeilen nach 25 Zeichen umgebrochen, zT nach 100 Zeichen
Meine Formatierung entspricht dem, was mir am besten gefällt.


Da sind Unmengen toter Code, stört (mich zumindest) beim Lesen. Das meiste kann man doch einfach bedenkenlos löschen
Den Combinator mache ich noch mal neu, ist sowieso nur ein Test-Util.

* nicht sicher, ob das öfter vorkommt, aber in mindestens einer Klasse gibts nen öffentlicher Konstruktor und eine öffentliche Fabrikmethode (z.b: newComparableArrayComparator vs ComparableArrayComparator), gibts da 'nen Grund für?
Der Java-Compiler meldet bei dem Aufruf eines Konstruktors (ja, ich weiß, eigentlich class instance creation Expression) Konstruktor nicht vorhanden, aber beim Aufruf einer Methode liefert er eine Liste der erwarteten Parameter.
Beim Schreiben hatte ich dort eine schwierige Stelle (Generics), deswegen die Methode.
Habe ich einfach nicht weggeräumt.


Builder wären an einigen Stellen sicher ganz nett. So eine Parameterliste ist doch echt hässlich:
Da wird das Mini-Projekt noch umfangreicher, ich überlege, ob ich das mache.


die beiden compare-Methoden in dim1 sehen für mich ziemlich ähnlich und deutlich zu lang aus - da kann man doch sicher was mit 'nem kleinen Refactoring gewinnen
Java:
o1.compareTo( o2 );

vs.

comparator.compare( o1 , o2 );
Meist wird nur die eine oder die andere Variante benötigt und der JIT macht eventuell redundanzarmen Code über method inline wieder redundant.
Ich habe mich hier bewusst für copy paste entschieden.
Aber der JIT ist in der Optimierung von Vererbung ziemlich gut, Performance sollte also nach dem Refactoring kein Problem sein, aber warum soll der JIT mehr arbeiten als nötig, dachte ich.
 
Zuletzt bearbeitet von einem Moderator:
Du kannst den Text anderer Leute auch richtig zitieren, am einfachsten mit markieren und dann "Zitieren" klicken.


Meine Formatierung entspricht dem, was mir am besten gefällt.
Und ich dachte schon, du nimmst das, was du am hässlichsten findest ;)
Ich wollte auch nur drauf hinweisen, dass es jeder Konvention widerspricht und manchmal echt doof zu lesen ist...

Da wird das Mini-Projekt noch umfangreicher, ich überlege, ob ich das mache.
Dafür kann man das bei einem kleinem Projekt viel leichter umsetzen - anbieten würde sich das an solchen Stellen in jedem Fall ;)

Java:
o1.compareTo( o2 );

vs.

comparator.compare( o1 , o2 );
Java:
Comparator.naturalOrder(o1, o2)
//vs.
comparator.compare( o1 , o2 );
[/icode]
Also dieser eine Methodenaufruf ist doch wirklich kein C&P wert ;)

[QUOTE="Barista, post: 1167651, member: 44849"]Meist wird nur die eine oder die andere Variante benötigt und der JIT macht eventuell redundanzarmen Code über method inline wieder redundant.
[...]Aber der JIT ist in der Optimierung von Vererbung ziemlich gut, Performance sollte also nach dem Refactoring kein Problem sein, aber warum soll der JIT mehr arbeiten als nötig, dachte ich.[/QUOTE]
Der JIT sollte aber wirklich das allerletzte sein, worüber man nachdenkt. 
Der beste Weg, dem zu helfen, ist oft, nicht zu versuchen dem zu helfen: [QUOTE="Brian Goetz]Often, the way to write fast code in Java applications is to write dumb code — code that is straightforward, clean, and follows the most obvious object-oriented principles.[/QUOTE]
 
Nun ja, nicht jeder will Reflection in seinem Programm haben.
Kleiner Auszug - was ich an Reflection meinte:
Java:
Class<?> eClass = element.getClass();

if (eClass.isArray()) {
  if (eClass == byte[].class)
    buf.append(toString((byte[]) element));
  else if (eClass == short[].class)
    buf.append(toString((short[]) element));
  else if (eClass == int[].class)
    buf.append(toString((int[]) element));
  else if (eClass == long[].class)
    buf.append(toString((long[]) element));
  else if (eClass == char[].class)
    buf.append(toString((char[]) element));
  else if (eClass == float[].class)
    buf.append(toString((float[]) element));
  else if (eClass == double[].class)
    buf.append(toString((double[]) element));
  else if (eClass == boolean[].class)
    buf.append(toString((boolean[]) element));
  else { // element is an array of object references
    if (dejaVu.contains(element))
      buf.append("[...]");
    else
      deepToString((Object[])element, buf, dejaVu);
  }
Ich weiß nicht, wie ich dies weiter vertiefen soll.
Normalerweise braucht man maximal 2 Dimensionen, wenn überhaupt, sonst verwendet man ordentliche Klassen und Datenstrukturen.
 
A

Anzeige




Hier lernst du alle wichtigen Java-Grundlagen.
Passende Stellenanzeigen aus deiner Region:

Neue Themen

Oben