Czesc, czy jest ktos w stanie podeslac kilka projektow na githubie, gdzie mozna byloby sie podszkolic?
Pozdrawiam
0
2
Preferuję techniki - zły kod kontra dobry kod. Poczytaj książki typu: Effective Java, Modern Java Recipes, Refactoring to Patterns (Kerievsky), Refactoring (Fowler), Robert C. Martin. Czytanie tylko dobrego kodu nie uchroni Cię od pisania złego.
0
Napisz i jak będzie dobry to będziesz wiedział intuicyjnie.
Zwykle się czuje jak kod dziwnie wygląda.
0
Chodzi mi rowniez o dobra kulture jaka panuje wsrod javowcow. Czyli jak nazywac foldery/klasy/interfejsy itp. itd.
0
Napisałem malutkie ADT - Evicting Queue , wydaje mi się, że to jest dobry kod:). Masz zadanie: Spróbuj sam ocenić:).
Możesz, dokładając dodatkową implementację (może AtomicReference??), zrobić z tego interfejs
Kod: Github
0
@lion137: Duplikujesz dwie linie bez sensu w dwóch metodach ;p.
typu tu:
public synchronized boolean push(T item) {
if (this.data.size() <= maxSize) {
if (this.data.size() == maxSize) {
this.popFirst();
this.data.add(0, item); // <--- O TE
return true; // <--- O TE
}
this.data.add(0, item);
return true;
}
throw new IndexOutOfBoundsException();
}
0
Schadoow napisał(a):
@lion137: Duplikujesz dwie linie bez sensu w dwóch metodach ;p.
typu tu:
public synchronized boolean push(T item) { if (this.data.size() <= maxSize) { if (this.data.size() == maxSize) { this.popFirst(); this.data.add(0, item); // <--- O TE return true; // <--- O TE } this.data.add(0, item); return true; } throw new IndexOutOfBoundsException(); }
Cóż... +1 za krytyczne czytanie, praktycznie, ze zrozumieniem;p Odpowiem Ci pytaniem: Które, w takim razie, zduplikowane linie usunąć?
0
yy, usunąć te w ifie kod wyjdzie za ifa i użyje 2 linii po nim.
0
Świetny Terrorysta napisał(a):
yy, usunąć te w ifie kod wyjdzie za ifa i użyje 2 linii po nim.
He, he, rzeczywiście:-D
0
ta metoda jest zła z zupełnie innego powodu @lion137
nigdy nie zwraca false a rzuca wyjątkiem, co to za sens ?
0
wojciechmaciejewski napisał(a):
ta metoda jest zła z zupełnie innego powodu @lion137
nigdy nie zwraca false a rzuca wyjątkiem, co to za sens ?
Taki jest design, ma rzucić wyjatek gdyby coś poszło źle i ilość elementów przekroczyłaby maksimum (wtedy program się wysypie w runtime - concurrency jest testowane), a true upewnia, że wszystko poszło OK. Metoda, również, mogłaby być typu void, ale tak może być bardziej uzyteczna.
0
@wojciechmaciejewski: "to jest zły design ;-)" być może, ale zupełnie niezależnie w google Guavie też zaimplementowali add podobnie:). To ma sens, gdyż nie ma sensu, żeby ta metoda zwracała false i program dalej sobie działał - nie może sie nie udać dodać elementu (chyba, że dodamy więcej niż max - wtedy bum, Exception). A true potwierdza, że wszystko jest OK i lecimy (wielowątkowo) dalej.
0
brawo dla twórców guavy że piszą bezsensowny kod.
po co zwracać wartość boolean z funkcji kiedy może być tylko true. Jakbyś pisał dokumentacje do swojej metody to co byś napisał
"metoda zwraca boolean. True w przypadku gdy uda się dołożyć element, false nigdy" .....
0
wojciechmaciejewski napisał(a):
brawo dla twórców guavy że piszą bezsensowny kod.
po co zwracać wartość boolean z funkcji kiedy może być tylko true. Jakbyś pisał dokumentacje do swojej metody to co byś napisał
"metoda zwraca boolean. True w przypadku gdy uda się dołożyć element, false nigdy" .....
Tak jak napisałem, można to łatwo zrefaktorować na typ void, ale dodanie return true zwiększa efektywność.
0
https://docs.oracle.com/javase/8/docs/api/java/util/Collection.html#add-E-
true if this collection changed as a result of the call
Jak widać - metoda add zwracająca boolean ma jak najbardziej sens.
0
@wojciechmaciejewski: "a po co tak? jeżeli się nie uda to i tak rzuci wyjątkiem, po co robić warunek ?"
Po prostu mamy zgodność z innymi elementami języka, Myślisz, że w Google nie mieli takich rozkmin pisząc ten bufer? Osobiście nie widzę innej konstrukcji - przy zadanych warunkach tej struktury - zaimplementowania jej Double Linked Listą. Można zrobić to też na tablicy o stałej długości, ale kod sie komplikuje.
1
Tak jak napisałem wyżej, wg. mnie robić coś żeby było zgodne z czymś innym, nie zachowując sensowności całej operacji jest błędem. Możecie uważać inaczej , nikt Wam nie broni :)
0
lion137 napisał(a):
wojciechmaciejewski napisał(a):
brawo dla twórców guavy że piszą bezsensowny kod.
po co zwracać wartość boolean z funkcji kiedy może być tylko true. Jakbyś pisał dokumentacje do swojej metody to co byś napisał
"metoda zwraca boolean. True w przypadku gdy uda się dołożyć element, false nigdy" .....
Tak jak napisałem, można to łatwo zrefaktorować na typ
void, ale dodaniereturn truezwiększa efektywność.
Zamiana boolean'a na void to jeszcze większy strzał w stopę. Cały problem polega na tym, że widząc metodę z zwracanym typem boolean nie spodziewałbym się po niej (ok, w Javie spodziewałbym się), że w przypadku niepowodzenia rzuci wyjątek. W tym przypadku założyłbym, że false oznacza niepowodzenie, true powodzenie. W przypadku void'a jest jeszcze gorzej bo nie masz pojęcia co się dzieje, musisz zajrzeć do implementacji żeby wiedzieć. Rozwiązaniem byłoby zasygnalizowanie poprzez zwracany typ, że dana operacja może zakończyć się niepowodzeniem, ot jakimś np. Either.
0
Dlatego każde API, które zwraca wyjątki powinno być udokumentowane odpowiednio, by była jasność czego się spodziewać po metodach.
0
DisQ napisał(a):
lion137 napisał(a):
wojciechmaciejewski napisał(a):
brawo dla twórców guavy że piszą bezsensowny kod.
po co zwracać wartość boolean z funkcji kiedy może być tylko true. Jakbyś pisał dokumentacje do swojej metody to co byś napisał
"metoda zwraca boolean. True w przypadku gdy uda się dołożyć element, false nigdy" .....
Tak jak napisałem, można to łatwo zrefaktorować na typ
void, ale dodaniereturn truezwiększa efektywność.Zamiana boolean'a na void to jeszcze większy strzał w stopę. Cały problem polega na tym, że widząc metodę z zwracanym typem boolean nie spodziewałbym się po niej (ok, w Javie spodziewałbym się), że w przypadku niepowodzenia rzuci wyjątek. W tym przypadku założyłbym, że false oznacza niepowodzenie, true powodzenie. W przypadku void'a jest jeszcze gorzej bo nie masz pojęcia co się dzieje, musisz zajrzeć do implementacji żeby wiedzieć. Rozwiązaniem byłoby zasygnalizowanie poprzez zwracany typ, że dana operacja może zakończyć się niepowodzeniem, ot jakimś np.
Either.
Przy dodawaniu do kolekcji, która może się przepełnić, lub z jakiegoś innego powodu dodanie elementu może się nie udać, Masz rację, ale ten bufer ma być threadsafe i ```add`` zawsze musi sakończyć się sukcesem; wyjatek jest zabezpieczeniem w przypadku gdy wielowątkowość coś "nabroi":)
1
Ten boolean to jakiś korpo-wymysł.
OK, trzymamy się konwencji, ale gdy ona jest zła to jaki to ma sens?
Wersja:
boolean add(cos-tam);
Sygnalizuje że jak coś się nie uda to dostaniemy false i ew. możemy sobie poszukać metody getLastErrorCode() której pewnie w żadnej klasie Javy nie znajdziemy. To jest design rodem z lat 80 z C++. Gdy wiadomo już było że zwracanie inta = 0 dla sukcesu jest trochę krzywe (patrz if(!generateReport(row)) cout << "Success\n"), a wyjątków jeszcze każdy się bał. No i nikt nie myślał o wielowątkowości. Albo nie brał pod uwagę że wzorcowy pattern (Win32 GetLastError) jest wielowątkowy...
Z kolei wersja boolean bez kodu błędu ma krótkie nóżki. Najpierw każdy zakłada że będzie od razu wiadomo jaka jest przyczyna błędu, a potem wychodzi że trzeba generować błąd z 5 zupełnie różnych powodów. Taka była pewnie historia Collection.add().
Wersja
void add(cos-tam) throws jakis-exception;
Jest czytelniejsza, bo wiadomo jak wydłubać szczegóły ew. niepowodzenia.
Pojawia się jednak potrzeba obsługi wyjątku.
Można zamiast checked exceptions użyć runtime i opisać w dokumentacji. Ważne żeby były opisane.
Ale to kwestia oczywiście wyboru. Można też zwracać enuma lub po prostu kod błędu (int).