Also hätte ich mit
schon eine sortierte Liste?PHP-Code:
StringComparator comp = new StringComparator();
Liste.sort(comp);
return Liste;
Edit: Ja hätte ich
Mal wieder vielen Dank
Hach ja, Zeitstempel sind ein Quell steter Freude
Ich habe hier zwei Zeitstempel. Der eine Wert ist duch Parsen eines Strings erzeugt worden, der andere stand als Integer
schon zur Verfügung. Hatte dann nen Assert( zeit1 == zeit2 ) im Code, und das schlug natürlich aus
Durch was werden sich die zwei printf-Ausgaben in diesem Beispielprogramm unterscheiden?
Code:#define _POSIX_C_SOURCE 200112L // for setenv on gcc #include <stdlib.h> #include <stdio.h> #include <time.h> int main(void) { setenv("TZ", "/usr/share/zoneinfo/Europe/Berlin", 1); // POSIX-specific time_t t; struct tm tm; t = 1445731800; tm = *localtime(&t); printf("Today is %s", asctime(&tm)); t = 1445735400; tm = *localtime(&t); printf("Today is %s", asctime(&tm)); }
Geändert von Ramkhamhaeng (12. Januar 2017 um 22:05 Uhr)
0.6 Sekunden?
zeit1 == zeit2 mit zwei Zeit-Objekten, die mit der gleichen int-Zeit gefüttert wurden dürfte auch fehlschlagen. Sind ja verschiedene Objekte.
Sie unterscheiden sich gar nicht? (sonst wärs ja langweilig)
An manchen Tagen im Jahr ist es 60 Minuten später wieder so spät wie zuvor
Verstand op nul, frituur op 180.
Sind da die Schaltsekunden mit einberechnet?
Zitat von Tata
Inwieweit einberechnet? Bei (Extra-)Schaltsekunden wird der Integerwert der Unix-Zeit einmal dekrementiert. Hat den Vorteil, dass sich die Tagesgrenze, etc bzgl. der Division nicht verschiebt.
Man könnte also sagen, dass das umgekehrte Phänomen zu oben auftritt. Der Int-Wert entspricht uneindeuting zwei 1-Sekunden-Intervallen in der Realzeit.
Wenn ich Tests mithilfe von JUnit schreibe, packe ich die zur Übersicht meistens in ein anderes Package. Allerdings kann ich dann die Methoden aus der zu testenden Klassen nur dann aufrufen, wenn ich diese public mache, gibts da einen Weg das nicht zu machen und trotzdem diese Methoden aufzurufen?
Methoden, die nicht public (oder protected) sind, sollte man eigentlich nicht testen müssen. Du willst mit Unit Tests nämlich sicherstellen, dass sich die Klasse nach außen so verhält, wie du es erwartest. Wie sie dabei intern genau vorgeht, sollte irrelevant sein, solange sie tut, was sie tun soll.
Anders gesagt: Wenn du private oder package-private Methoden testen musst, stimmt vermutlich etwas mit deinem Design nicht. Oder du hast krumme Uni-Vorgaben, dann musst du die wohl auf public setzen.
Das ist imo nicht komplett korrekt. Wenn ich eine Klasse hab mit einem sehr komplexen Algorithmus der nur für die Klasse zur Verfügung stehen soll ist der privat und es ist dennoch nötig ihn zu testen - unabhängig davon was die Klasse sonst so macht. Reflection wie alpha geschrieben hat wäre da die imo beste Lösung, in der Regeln hat Blackheart aber recht - nur in den seltensten Fällen sollte man darauf zurück greifen müssen.
|學而不思則罔,思而不學則殆。 ~ 孔子|
| Lernen ohne zu denken ist sinnlos, denken ohne zu lernen gefährlich. ~ Kong Zi |
| During times of universal deceit, telling the truth becomes a revolutionary act ~ George Orwell |
SdM Dez16 - XCOM2 Make Humanity Great again
Naja, wenn du einen sehr komplexen Algorithmus hast, dann würde ich zumindest mal überprüfen, ob die Klasse für zu viele Sachen selbst verantwortlich ist. Es sollte in der Regel möglich sein, die Komplexität an andere, neue Klassen zu delegieren, bei denen es dann Sinn macht, wenn die entsprechenden Methoden public sind, und die idealerweise auch noch die Komplexität verringern. Wenn du Unit Tests für private Sachen nutzt, verlierst du halt einen der beiden Hauptvorteile von Datenkapselung (nämlich dass du die privaten Sachen ändern kannst, ohne das sonstiger Code - hier die Tests - gebrochen wird).