Potrzebna opinia o kodzie

Question

Witam,

Potrzebna mi opinia o kodzie kod przedstawia bazę danych Studentów 

https://github.com/rty2567/obiekt/blob/master/Daniel

 

Answer 1

1) dbaj o lepsze formatowanie kodu, nie jest źle, ale mógłbyś np. wstawiać spacje po przecinkach w deklaracji funkcji, albo pomiędzy znakami ')' i '{'.

2) W wielu miejscach są niepotrzebne puste linie (linie 48, 56, 76, 842-847)

3) WTF?! linie 70-841 zrób sobie tablicę w której będą te dane (dane najlepiej z pliku JSON) i iteruj po niej. Poczytaj o zasadzie DRY

4) koniecznie nazywaj metody, zmienne i wszystko w kodzie po angielsku. Nie po polsku!

Comments

 (dane najlepiej z pliku JSON) 

Czemu?

---

@mbabane Jest ich dużo, mogą często się zmieniać, to nie są dane bezpośrednio o aplikacji

---

W sensie dlaczego JSON, a nie np. CSV.

---

Złożone dane łatwiej parsuje się w formacie JSON, CSV ma ten minus, że znak separatora nie może pojawić się w danych. Łatwiejsza interpretacja przez człowieka na plus na JSON'a. Oczywiście, jeżeli dane są naprawdę olbrzymie CSV wygrywa dzięki swojej sekwencyjności czytania. JSON niestety nie daje takiej możliwości. Moim zdaniem nie można na tym etapie stwierdzić co było by lepsze. Na pewno oba formaty pasują.

---

@mbabane, Jest masa formatów yaml, toml json, csv i setki innych ,częściej lub rzadziej używanych. JSON jest bardzo popularny, i tyle

---

Chodzi o to, że patrząc na poziom umiejętności autora kodu, dokładasz mu dodatkowe brzemię w postaci parsowania pliku JSON co nie jest takie trywialne i proste. Napisanie bardzo prostego parsera CSV to w zasadzie jedna linia (pomijając wczytanie linii z pliku) - użycie split'a na stringu.

Tak są biblioteki do JSON itd. ale autor nie radzi sobie jeszcze dobrze z JDK więc uczenie się i tak naprawdę trochę marnowanie sił na jakieś biblioteki na tym etapie jest mu zbędne. Sama obsługa plików może być dla niego skomplikowana i nietrywialna.

Nie zwracasz w ogóle uwagi, że na samym początku maina użyte jest 8 list, co można zredukować do jednej. A próbujesz dokładać kolejną rzecz do projektu.

---

@mbabane, Przyznaję ci rację :D Nie zwróciłem na to uwagi

Answer 2

Cześć.

Uważam, że wszystko co kolega Milesq napisał jest jak najbardziej do uwzględnienia.

Od siebie napisze, że zamiast Arraylist w metodach możesz przyjmować List. Wtedy będziesz mógł przesłać każdy rodzaj listy, nie tylko Arraylist.

Utarło się też, że w Javie stosuje się notacje tzw. Camel case. Czyli każdy wyraz w nazwie zmiennych, klas i metod zaczynamy od wielkiej litery. Np. thisIsCamelCase.

I jeszcze pytanie czy modyfikator dostępu klasy Solution napewno chciałeś ustawić jako pakietowy?

Comments

I jeszcze pytanie czy modyfikator dostępu klasy Solution napewno chciałeś ustawić jako pakietowy?

Pytanie czemu miało by być public? Klasy public w Javie są bardzo często nadużywane i pakietowy dostęp zwykle jest wystarczający. Zerknij na to, pewna filozofia na temat klas pakietowych vs public:

https://youtu.be/wbAtJlbRhbQ?t=1905

---

Tak, wiem o tym. Dlatego zadałem pytanie, a nie stwierdziłem że jest to złe. Nic o public nie pisałem.

Answer 3

Dużo prościej będzie jeśli to:

ArrayList<String> imie = new ArrayList<>();
ArrayList<String> oceny = new ArrayList<>();
ArrayList<String> adres = new ArrayList<>();
ArrayList<String> data = new ArrayList<>();
ArrayList<String> nr_tel = new ArrayList<>();
ArrayList<String> e_mail = new ArrayList<>();
ArrayList<String> rok = new ArrayList<>();
ArrayList<String> kierunek = new ArrayList<>();

Zamienisz na klasę Student:

class Student {
      String imie;
      ArrayList<String> oceny = new ArrayList<>();
      String adres;
      String data;
      String nr_tel;
      String e_mail;
      String rok;
      String kierunek;
}

Wtedy w main będziesz miał tylko jedną listę:

List<Student> students = new ArrayList<>();

 

Comments

następnie utworzyłbym klasę Student

Coś takiego zasugerowałem i powiedziałeś, że to brzydko pachnie. 

---

Sam pomysł na osobną klasę pochwalam, nie podoba mi się klasa, która tylko trzyma dane. Gdybyś dodał logikę do tej klasy, nic bym nie napisał.

---

A jaką logikę powinien dodać?

---

 logikę do tej klasy, nic bym nie napisał.

Są co najmniej dwa powodu, że tego nie zrobiłem. Jeden to powiedzmy polityka forum, która mówi żeby nie dawać czystych gotowców.

A drugi jest taki, że to co sugerujesz jest tylko pewną konwencją, propozycją rozwiązania, która można ale nie trzeba stosować. Jeśli się nie mylę jest to podejście DDD. Bo można też to podciągnąć pod nie spełnienie S z SOLID, bo jak Student będzie miał logikę to być może, że klasa  ma co najmniej dwa powody do zmiany. Zmiana logiki np. nrTel będzie polem wymaganym (bo mogło być opcjonalne) więc trzeba wprowadzić zabezpieczenie żeby nowo dodani studenci musieli mieć telefon.

Inny rodzaj zmiany to dodanie dodatkowego pola np. osiągnięcia.

Chodzi mi o to, że to że istnieją jakieś konwencje to nie znaczy że MUSImy je stosować - bo czasem mogą tylko wprowadzić dodatkowy zamęt i skomplikowanie przez swoją teorię. Innym prostym przykładem jest zrobienie RESTful'a - chyba nie istnieje idealne API. 

Dzięki za ciekawą dyskusję. Powodzonka!

---

Pewnie, nie mogę nikogo zmusić do pisania kodu tak jak ja uważam. Jeżeli według Ciebie jest to dobre rozwiązanie, to nic mi do tego. Napisałem swoją opinie, że nie jest to dobre pod względem paradygmatu obiektowego.

Raczej DDD niema nic z tym wspólnego, bo dyskusja toczyła by się na temat modelu, a nie kodu. Co do złamania zasady, która zwiera się akronimie SOLID spierałbym się, kwestia implementacji. Oczywiście, stosować według potrzeby, nie na siłę. Bez końcowego kodu możemy gdybać. Na pewno nie porwę się i nie napiszę co by był najlepsze.

Trudno mi stwierdzić jaką logikę dokładnie, bo to zależy od twórcy. Może być prosta walidacja danych(chociaż to też by wyodrębnił, kompozycja spełniłaby moje założenia), może być zwracanie jako tablicy(danych), może być liczenie średniej. Wszystko zależy od wymagań jakie zostały narzucone.