Od jakiegos czasu zaprzyjaźniam sie z Java. Nie wiem czy mnie polubila.
0
3
User dziedziczący z Userfactory, podobnie z komputerami. Obiekt nie dziedziczy ze swojej factory.
Próbowałem sobie wytłumaczyć, dlaczego XxxxFactory w ogóle musi istnieć, i nie znalazłem. Są powody, że nie można produkować przez new ?
i nie do końca ta Factory mi się widzi, jako Factory .. trochę z Buildera, ale to tez nie czysty Builder.
Wzorzec Factory użyty, aby był użyty?
Klas wyjątków dość dużo, jak na niewielki program. Czy za dużo? Jedną nogą będąc w C# przyjąłem zarzut "wy javowcy za dużo deklarujecie klas wyjątków"
Ale za to dziedziczą zbyt płasko, z Runtime albo Exception, a wg mnie powinny dziedziczyć z jakiegoś najbardziej podobnego wyjątku JDK niosącego informację (Illegal ArgumentException, IoException - w tym sensie ... a może fabryczne z tej grupy by wystarczyły)
interface CsvConvertible mi pachnie jak stracona szansa. Była jakaś idea (której nie do końca potrafię odgadnąć, ale wierzę, ze dobra), ale odleciała zanim doszło do rozwinięcia.
Kilka może nie zgrzytów, ale szorstkości, jak Printer(reader), a myślę powinien być Printer(collection)
tyle czytając z githuba. Moze z IDE bym szybciej się przemieszczał i dostrzegł coś innego.
lepiej, niż podobny Twój post sprzed czasu, ale nadal da się poprawiać.
3
@Override
public String toCsv() {
return getFirstName() + ";" + getLastName() + ";" + getPesel();
}
Generalnie w większej aplikacji takie coś jest słabe bo model teoretycznie nie powinien wiedzieć o sposobie jego przechowywania.
PS z jakiego IDE korzystasz?
2
AnyKtokolwiek napisał(a):
Próbowałem sobie wytłumaczyć, dlaczego XxxxFactory w ogóle musi istnieć, i nie znalazłem.
Spójrz na rozszerzenie plików z kodem źródłowym, Java bez Factory się pewnie nawet nie skompiluje. :P
Klas wyjątków dość dużo, jak na niewielki program. Czy za dużo? Jedną nogą będąc w C# przyjąłem zarzut "wy javowcy za dużo deklarujecie klas wyjątków"
Ale za to dziedziczą zbyt płasko, z Runtime albo Exception, a wg mnie powinny dziedziczyć z jakiegoś najbardziej podobnego wyjątku JDK niosącego informację (Illegal ArgumentException, IoException - w tym sensie ... a może fabryczne z tej grupy by wystarczyły)
Ciężko mi sobie wyobrazić potrzebę dziedziczenia z wbudowanych wyjątków. Jakie dodatkowe informacje, których nie dają standardowe wyjątki mogą nieść własne wyjątki dziedziczące z IoException czy IllegalArgument?
Aleksander32 napisał(a):
Generalnie w większej aplikacji takie coś jest słabe bo model teoretycznie nie powinien wiedzieć o sposobie jego przechowywania.
No, a do tego separator używany w plikach powinno się dać zmienić w jednym miejscu.
4
Przyznam się, ze Factory ratowalem kompilacje ;) — p_agon dziś, 07:41
Czytam ten kod jeszcze raz.
Wydaje się, że wymyśliłeś klasę AbstractComputer / BaseComputer etc, tylko nazwałeś ją Factory
Idąc w OOP będziesz spotykał klasy nazwane wg wzorców.
Moje zdanie o wzorcach (ogólnie) jest takie, że wielu adeptów tej religii już wchodzi w sektę, choć nie mam nic przeciwko wzorcom samym, dobrze użytym.
Moja rada dla Ciebie: używaj wzorów I ICH NAZW gdy będziesz miał przekonanie, ze rozumiesz. Ten AbstractComputer jest całkiem, całkiem, tylko źle nazwany.
4
Notoryczne sterowanie przepływem programu za pomocą rzucania wyjątków to antywzorzec.
Wyjątki, jak sama nazwa każe się domyślać, służą do obsługi sytuacji wyjątkowych, leżących poza naszą kontrolą.
Nie jest zaś sytuacją wyjątkową, ani leżącą poza naszą kontrolą, że np. użytkownik o danym numerze PESEL już jest zarejestrowany.
Taki scenariusz można obsłużyć zwyczajnie zwracaną wartością, warunkiem.
Wyjątki to takie "goto".
Mam też wątpliwości co do nazewnictwa i wzorców projektowych, ale takim najpoważniejszym zarzutem - i rzeczą, od której moim zdaniem powinno się w ogóle zaczynać ocenę kodu - jest kompletny brak jakichkolwiek testów jednostkowych.
Testy jednostkowe nie służą tylko jako dowód, że bugów nie ma. (Nie są takim dowodem). Z twojej perspektywy grałyby ważniejszą rolę: wymuszają od programisty jasność w kwestii tego, jak i co chce zaimplementować. Wymuszają spisanie czegoś w rodzaju "żywej specyfikacji". Wymuszają, aby kod był rozsądnie zaprojektowany - w przeciwnym wypadku napisanie testów będzie trudne lub nawet niemożliwe.
Na twoim miejscu napisanie testów do tego kodu postawiłbym sobie jako następne zadanie. Trudności, które napotkasz, będą bardzo pouczające.