Ocena - Klasy tworzenia planety. |
Ocena - Klasy tworzenia planety. |
10.04.2013, 21:51:29
Post
#1
|
|
Grupa: Zarejestrowani Postów: 83 Pomógł: 1 Dołączył: 26.02.2013 Ostrzeżenie: (0%) |
Cześć.
Na początku zaznaczam, że to moje początki OOP, żeby nie było .
Ten post edytował q3trm 10.04.2013, 21:52:39 |
|
|
11.04.2013, 13:31:18
Post
#2
|
|
Grupa: Zarejestrowani Postów: 365 Pomógł: 70 Dołączył: 5.04.2009 Ostrzeżenie: (0%) |
Od początku - nazewnictwo jak dla mnie jest trochę "nie tego".
creatPlanet - można już było dać PlanetCreator albo coś innego, bo teraz to wygląda trochę jak createPlanet (a czasownikowa nazwa dla klasy - średnio). Dalej funcPlanet (może BasePlanet)? Poza tym w Twoim przypadku wystarczyłoby wszystko wrzucić do klasy Planet. |
|
|
11.04.2013, 15:51:10
Post
#3
|
|
Grupa: Zarejestrowani Postów: 83 Pomógł: 1 Dołączył: 26.02.2013 Ostrzeżenie: (0%) |
Nie myślałem nad nazewnictwem podczas pisania klas, głównie skupiłem się na koncepcji stworzenia skryptu umożliwiającego łatwe rozwijanie w przyszłości.
Rozumiem, że aktualna struktura = "przerost formy nad treścią". Co w przypadku indywidualnego rozszerzania funkcjonalności planet. Nie lepiej by było je mieć w osobnych klasach, tak jak to jest teraz?. Wydaje mi się to bardziej czytelne. Cały czas w OOP mówi się o zasadzie "pojedynczej odpowiedzialności", czyli klasa pobiera parametry, ale nie ingeruje w nie, tak rozumiem zasadę pojedynczej odpowiedzialności. Mylę się?. |
|
|
17.04.2013, 01:31:07
Post
#4
|
|
Grupa: Zarejestrowani Postów: 273 Pomógł: 52 Dołączył: 3.02.2013 Skąd: Przemyśl Ostrzeżenie: (0%) |
Moim zdaniem masz rację i nie powinieneś zamykać wszystkiego w jednej klasie.
No chyba, że ta klasa nazywała by się w twoim przypadku SolarSystem Nie wystarczy pisać obiektowo, trzeba także myśleć i projektować obiektowo, bo sama deklaracja klasy, oraz modyfikatory dostępu to nie OOP. Jako, że każda planeta w układzie słonecznym jest pewnym realnym obiektem, który może charakteryzować się różnymi cechami. Ale może posiadać także cechy wspólne słusznie rozdzieliłeś planety jako osobne klasy, które dziedziczą po klasie abstrakcyjnej Planet Ten post edytował mstraczkowski 17.04.2013, 01:34:35 -------------------- Jeżeli moja wypowiedź Ci pomogła użyj przycisku
|
|
|
18.04.2013, 12:31:18
Post
#5
|
|
Grupa: Zarejestrowani Postów: 4 655 Pomógł: 556 Dołączył: 17.03.2009 Skąd: Katowice Ostrzeżenie: (0%) |
Wszystko zależy od tego przez jakie parametry chcesz opisywać Planety, jeżeli te parametry powtarzają się przy każdej z planet to nie widzę sensu tworzenia klas dla poszczególnych planet. W ogóle raczej planeta to planeta i wszystkie według mnie można opisać podobnie ew. dodać jakieś specjalne parametry (jakaś odpowiednia metoda, bo nawet jak stworzysz dodatkowe klasy to i tak będziesz musiał to pamiętać)
-------------------- Zainteresowania: C#, PHP, JS, SQL, AJAX, XML, C dla AVR
Chętnie pomogę, lecz zanim napiszesz: Wujek Google , Manual PHP |
|
|
18.04.2013, 13:23:10
Post
#6
|
|
Grupa: Zarejestrowani Postów: 6 476 Pomógł: 1306 Dołączył: 6.08.2006 Skąd: Kraków Ostrzeżenie: (0%) |
1. Uranium to nazwa pierwiastka, Uranus to nazwa planety.
2. Zastanów się, które zdanie ma sens: "Uran to Uran" czy może "Uran to planeta"? Już ten prosty test pokazuje Ci, że raczej powinieneś mieć jedną klasę Planeta i dowolną ilość jej instancji (Merkury, Wenus, Ziemia, Mars, ..., Neptun, ..., Ozyrys, COROT-12 b czy Kepler-7 . Wszystkie one mają cechy/właściwości wspólne: nazwa, średnica, masa. 3. Pamiętaj, że nazwą klasy powinien być rzeczownik (np. PlanetCreator), zaś nazwą metod czasownik (np. create czy getName()). 4. Jest bardzo niewiele przypadków, gdzie użycie $this ->nameplanet = get_class($this); byłoby uzasadnione. Nazwa planety to jedna z jej podstawowych właścwiości i powinna zostać przekazana jako argument konstruktora. 5. Widzę, że każdej z planet przypisujesz jakieś właściwości nie związane bezpośrednio z samą planetą, tj. jej potencjał ekonomiczny czy militarny. Takie coś powinno być ujęte albo w kompletnie innym obiekcie, który na podstawie przekazanej mu planety zwracałby jej potencjał militarny/ekonomiczny, bądź w osobnym obiekcie będącym właściwością samego obiektu Planeta. 6. Zastanawiasz się czy utworzenie osobnej klasy (dziedziczącej po Planet czy też implementującej jakiś tam interfejs) celem implementacji specyficznych właściwości nie będzie lepsze. Powinieneś mieć na uwadze to, że obiekt typu Planeta to przykład tzw. obiekt domeny, a te raczej nie powinny wykonywać zbyt wielu operacji. Ich przeznaczenie to reprezentacja danych oraz najbardziej podstawowe operacje na nich, czyli taki obiekt Planeta mógłby mieć metody typu: isHeavierThan(Planet $other) czy getGravitationalAcceleration(). Jakieś bardziej zaawansowane operacje powinny już być wykonywane spoza obiektu typu Planet. |
|
|
19.04.2013, 11:27:34
Post
#7
|
|
Grupa: Zarejestrowani Postów: 83 Pomógł: 1 Dołączył: 26.02.2013 Ostrzeżenie: (0%) |
Dzięki za rady . Jaki wzorzec by najlepiej pasował do mojego problemu?.
|
|
|
19.04.2013, 11:29:47
Post
#8
|
|
Grupa: Zarejestrowani Postów: 6 476 Pomógł: 1306 Dołączył: 6.08.2006 Skąd: Kraków Ostrzeżenie: (0%) |
1. Jeszcze jedna uwaga: nie korzystaj z tablic do przechowywania właściwości obiektu, które nie są kolekcją (patrz: potencjał militarny/ekonomiczny).
2. Przede wszystkim opisz nam tutaj co tworzysz, czym mają być te planety (z punktu widzenia programu/użytkownika, nie kodu) i co będzie miało się z nimi robić. Wtedy będziemy mogli napisać Ci jak się za to zabrać. |
|
|
19.04.2013, 12:36:37
Post
#9
|
|
Grupa: Zarejestrowani Postów: 83 Pomógł: 1 Dołączył: 26.02.2013 Ostrzeżenie: (0%) |
1. Chodzi ci o to, że dane nie są ze sobą powiązane?. 2. Tworzę grę na przeglądarkę. W tej grze użytkownik ma możliwość wyboru planety, oraz późniejszego jej rozwijania. Każda planeta ma jakąś metodykę rozwoju np: militarną, ekonomiczną, odkrywczą, którym użytkownik przydziela punkty(tylko podczas tworzenie planety). Wszystkie planety cechuję szybkość ogólnego rozwoju($increase), która różni się w zależności od wybranej planety(obliczanie na podstawie nazwy planety w skrypcie, jest tylko prowizorycznym zastosowaniem). Krótko mówiąc, czysty model tworzenia planety za pomocą formularza. Nie chcę gotowca, prosiłbym o nazwę wzorca odpowiadającym do ww. logiki skryptu. Zastanawiam się nad wzorcem Decorator, Strategy. |
|
|
19.04.2013, 13:05:06
Post
#10
|
|
Grupa: Zarejestrowani Postów: 6 476 Pomógł: 1306 Dołączył: 6.08.2006 Skąd: Kraków Ostrzeżenie: (0%) |
1. Chodzi o to, że takie rzeczy powinny być właściowścią obiektu (każda z osobna), a nie umieszczone w tablicy. Dlaczego? Bo łatwiej wtedy przydzielić im indywidualne cechy, łatwiej udokumentować kod czy ogólnie utrzymywać go.
2. Rozumiem, że te planety nie ograniczają się do naszego Układu Słonecznego? W takim wypadku obiekt typu Planeta powinien mieć jakieś podstawowe właściwości opisujące samą planetę (np. nazwa czy wspomniana szybkość ogólnego rozwoju). Punkty przydzielone przez użytkownika mogą być albo bezpośrednimi właściwościami tego obiektu, mogą też być osobnym obiektem będącym właściwością obiektu Planeta. Które rozwiązanie jest lepsze? To już zależy, m.in. od tego czy obiekt Planeta i MetodykaRozwojuPlanety są rozbudowane czy nie. Jednak prawdopodobnie osobny obiekt, będzie lepszym rozwiązaniem. |
|
|
30.05.2013, 00:42:12
Post
#11
|
|
Grupa: Zarejestrowani Postów: 251 Pomógł: 23 Dołączył: 23.04.2013 Ostrzeżenie: (0%) |
Krótko mówiąc, czysty model tworzenia planety za pomocą formularza. Nie chcę gotowca, prosiłbym o nazwę wzorca odpowiadającym do ww. logiki skryptu. Zastanawiam się nad wzorcem Decorator, Strategy. Wydaje mi się, że "The Strategy Pattern" by się tutaj świetnie spisał, mógłbyś stworzyć niezależne interfejsy oraz klasy zachowań poszczególnych planet, które można by nawet przydzielać planetom dynamicznie (w trakcie działania aplikacji). Poniżej przykład mojego pierwszego kodu (napisanego milion lat temu) z implementacją "The Strategy Pattern" - wklejam prosto ze starych notatek, nie chce mi się go nawet poprawiać. Jego przejrzenie może dać ogólne pojęcie nt. odizolowania rzeczy statycznych od rzeczy zmiennych. Na jego przykładzie widać jak łatwo można implementować nowe zachowania, czy zmieniać je dynamicznie podczas działania aplikacji (at run-time).
UWAGA: Kod służył tylko do praktyki, tak więc latające koty i miauczące psy nie powinny nikogo dziwić. Ten post edytował Dejmien_85 30.05.2013, 01:01:00 |
|
|
Wersja Lo-Fi | Aktualny czas: 25.04.2024 - 08:26 |