W ubiegłym tygodniu przybliżyłem Ci już czym są algorytmy genetyczne oraz dlaczego i po co mam zamiar wykorzystać je w tworzonej bibliotece. Czas wziąć się już do pisania kodu! Jak wyglądają więc początki easyGALib?
Nie wymyślaj koła na nowo
W myśl starej zasady, którą najlepsi programiści stosują w codziennej pracy, postanowiłem najpierw wrócić do czegoś z czym miałem już styczność, czyli biblioteki Java GALib. Poznałem ją przy okazji realizacji pracy magisterskiej i wręcz wzdłuż i wszerz sprawdziłem jej możliwości i mankamenty. A to nie dało się działać na liczbach całkowitych, a to brakowało możliwości zwrócenia wyniku – jednym słowem idealna nie jest, ale sama jej struktura i implementacja algorytmów genetycznych może być wzorcem, na którym oprę swój projekt. W końcu najlepiej jest uczyć się na cudzych błędach 🙂
Dlaczego nie lubię Javy?
Mając już coś na czym mogłem się oprzeć, postanowiłem odpalić projekt. Z tego co pamiętam NetBeans nie chciał zaimportować kiedyś Java GALib, więc od razu zainstalowałem Eclipse i przy pierwszej próbie jego załączenia zastałem taki oto komunikat:
Milion linijek tekstu, a w zasadzie ciężko tu się doszukać co tak naprawdę jest nie tak z moim środowiskiem. Powód natomiast banalny – nie miałem zainstalowanej Javy dla architektury 64-bitowej. Czy nie można tego napisać już przy instalacji? Czy ciężko byłoby dać znać normalnym komunikatem o błędzie? No tak, bo to Java. Tutaj nie ma środowiska, które pomaga Ci nie tracić czasu na głupoty. Dlatego właśnie nie lubię Javy – zrobiłem kilka projektów w różnych technologiach i zawsze napotykałem się na tego typu „heheszki” z jej strony.
Struktura projektu
Na razie ciężko tutaj mówić o strukturze jako takiej, gdyż na bieżąco będę budował odpowiednie zależności w odpowiedzi na zastane w kodzie potrzeby. Na pewno będzie na początek potrzebna abstrakcyjna klasa reprezentująca chromosom, ponieważ będziemy je budować np. z intów, doubli, stringów i w takim wypadku każdy będzie nieco inaczej zachowywał się chociażby przy krzyżowaniu. Podobna sytuacja jest z samą implementacją algorytmu – w zależności od wybranego wcześniej chromosomu, będziemy musieli podawać inne parametry działania. Tutaj więc też pewnie przyda się klasa bazowa skupiająca wspólne metody i klasy pochodne działające na konkretnych rodzajach genów. Tak więc póki co projekt wygląda bardzo ubogo:
Jedyny kod, który powstał póki co, to klasa Constants, z której będziemy dostawać się do wszystkich stałych w kodzie. Być może nie miałeś okazji wykorzystać takiego rozwiązania:
namespace easyGALib { internal partial class Constants { internal static class Settings { internal static string LibraryName = "easyGALib"; } } }
Dzięki temu możemy podzielić sobie na kilka plików wszystkie stałe według kategorii (u mnie np. Exceptions i Settings), a jednocześnie w bardzo wygodny sposób się do nich odwoływać. Robimy to na przykład tak:
public GABase() { var name = Constants.Settings.LibraryName; }
Jak widać na razie projekt bardzo wolno nabiera kształtu, jak to już bywa z początkami każdego przedsięwzięcia IT. Zawsze na początku szukamy najlepszego, gotowego już rozwiązania czy wzorca, aby później z nawiązką odebrać sobie ten czas, dzięki ominięciu szeregu błędów.
10 marca 2016 at 10:03
W jakim celu używasz partial? Prawdę mówiąc uważam to za rozwiązanie, którego powinno się za wszelką cenę unikać, zostało bodajże wprowadzone głównie ze względu na definiowanie „proxy” używanych np. w WCF.
Rozumiem, że chcesz podzielić stałe na kategorie, ale wydaje mi się, że prościej byłoby wszystko trzymać w jednym pliku :).
10 marca 2016 at 16:56
Partiala używam, aby mieć jedną klasę z poziomu której mam dostęp do wszystkich stałych rozrzuconych na kilka plików. Jestem za tym, żeby nie trzymać wszystkiego w jednym, bo wraz z rozbudową projektu zaczyna się robić bałagan 🙂
11 marca 2016 at 09:51
Używanie partiala to nie jest dobry pomysł, zwłaszcza że masz jedną stałą.
http://martinfowler.com/bliki/Yagni.html
I nie nazywaj solucji/projektu z małej litery, to nie Java 😉