Drobne pytanie [Java]

[Libertyn]

Wyobraźmy sobie grę tekstową.
Mamy na początku wybór:
a
b
Wybierając a mamy:

a1,
b1,

c1,

d1.
Po wyborze d1 powinien się znów wyświetlić początkowy wybór:

a
b
Z możliwością wyboru a lub b. Póki co po a->d1 wyświetla mi się pierwotny wybór, nie mniej program się zamyka. Jak temu zapobiec?
 

[Baelish]

Wklej kod do pastebina, albo daj link do githuba.

[Libertyn]

13 minut temu, Baelish napisał:

Wklej kod do pastebina, albo daj link do githuba.

https://pastebin.pl/view/fd1f2146

[azagoth]

Zastosuj na samym początku pętlę while z jakąś zmienną boolean. Daaaawno nie programowałem ale będzie to w pseudo-kodzie coś takiego

 

wyjście = false;

while (wyjście == false) {

// wyświetl menu 1 (a,b)

//tutaj wszystkie Twoje początkowe operacje, które mają przerwać pętlę muszą mieć wyjście = true

...

 switch {

 // opcje a1, b1, c1

 

   case "d1": {

     // Twoje operacje

     wyjście = false;

     break;

   }

 }

}

[Ancalagon]

1. Wszelkie Stringi typu "a", "b" powinny zostać zamienione na enumy.

2. Każdy switch do osobnej metody, powinno się unikać wszelkiego rodzaju zagnieżdżeń.

3. break zamieniłbym na return enum ExitGame(TRUE, FALSE) - zwiększy to czytelność.

4. Te wszystkie new MarketXHorseShopOldMule() dobrze nadają się do umieszczenia w Factory, dodatkowo stosując wzorzec Flyweight.

5. playerWealth wydaje się mieć przyszłość jako pole wealth klasy Player.

6. Składając to do kupy, stosujesz while, jak to powyżej pokazał @azagoth, tyle że ten while jest "nieco krótszy

 

Tyle mi się nasunęło, bo nie widzę całego kodu

 

Do dzielenia się pełnym programikiem dobre jest:

https://ideone.com/

[Libertyn]

31 minut temu, Ancalagon napisał:

1. Wszelkie Stringi typu "a", "b" powinny zostać zamienione na enumy.

Oho, sporo pracy przede mną. 

31 minut temu, Ancalagon napisał:

2. Każdy switch do osobnej metody, powinno się unikać wszelkiego rodzaju zagnieżdżeń.

Nie mniej tu może być trudne. Z racji na to że tu niejako sama logika jest zagnieżdżona. Chciałbym by to było tak proste jak się da

31 minut temu, Ancalagon napisał:

3. break zamieniłbym na return enum ExitGame(TRUE, FALSE) - zwiększy to czytelność.

Napewno spróbuję to zaimplementować

31 minut temu, Ancalagon napisał:

4. Te wszystkie new MarketXHorseShopOldMule() dobrze nadają się do umieszczenia w Factory, dodatkowo stosując wzorzec Flyweight.

Zastanawiam się nad The State pattern.

Factory? Jak to widzisz?

31 minut temu, Ancalagon napisał:

5. playerWealth wydaje się mieć przyszłość jako pole wealth klasy Player.

Tak zrobię.

 

[Druid]

3 godziny temu, Libertyn napisał:

Wyobraźmy sobie grę tekstową.

Nie lepiej przerzucić się na PYTHONA, za niedługo JAVA będzie przeżytek.

[Ancalagon]

2. Chodzi o to, by to zagnieżdżenie przenieść do innej metody, jak to jest pokazane tutaj:

private ExitGame a() {
	(...)
	switch(input) {
	case A:
		return b();
	case B:
		(...)
		return ExitGame.TRUE;
	}
	case C;
  		(...)
  		return ExitGame.FALSE;
}

private ExitGame b() {
	(...)
	switch(input) {
	case A:
		(...)
		return ExitGame.TRUE;
	case B:
		(...)
		return ExitGame.FALSE;
	}
}

 

4. Tu jest mi ciężej coś zawyrokować, bo nie znam do końca intencji.

Factory - dla danego Marketu zwracasz obiekty OldMule, Mule, StrongMule z odpowiednią ceną.

Możesz też mieć sam MarketX z metodami typu getMulePrice(), tutaj już wiele zależy od wykorzystania tego Mule.

Wszystko ma jeden podstawowy minus - przy dodaniu kolejnego typu Mule trzeba się trochę opisać.

Ja tam lubię sobie w Factory używać klas anonimowych, ciekawe co na to wszystko @Reflux 

 

@Boromir 

O tym "niedługo" słyszałem już dawno temu 

[Libertyn]

33 minuty temu, Boromir napisał:

Nie lepiej przerzucić się na PYTHONA, za niedługo JAVA będzie przeżytek.

Nie chciałbyś mieć banku postawionego na Pythonie i Django. Bo te dobre są do małych projektów

Java będzie miała się dobrze przez długie lata bo na Javie stoi większość backendu banków i tego typu instytucji. Wciąż jest zresztą zapotrzebowanie na programistów COBOLa , którego wspomniana JAVA miała zastąpić

[mindo]

 

 

Generalnie dla długiego drzewa decyzyjnego najlepiej gdybyś napisał sobie jakąś jedną metodę którą wywołujesz w stylu:

moja_metoda(null,[

'a1'=>[

   function(){//rob coś},[

        'c'=>[

               function(){

                 //rób coś

             },[

                 //itd...

             ]

        ]

    ]

],

'b1'=>

[

   function(){//rob coś},[

        'd'=>[

               function(){

                 //rób coś

             },[

                 //itd...

             ]

        ]

    ]

]

,

'c1'=>

[

   function(){//rob coś},[

        'e'=>[

               function(){

                 //rób coś

             },[

                 //itd...

             ]

        ]

    ]

]

  'd1'=>

[

   function(){//rob coś},[

        'f'=>[

               function(){

                 //rób coś

             },[

                 //itd...

             ]

        ]

    ]

]

]);

 

gdzie moja_metoda ma definicję w stylu:

 moja_metoda(func,arr) {

    func(); //wywołanie funkcji anonimowej

    switch case z arraya i na nim wywołanie rekurencyjne

}

 

Ale to już rozwiązanie dla hardcorowców i długiego drzewa decyzyjnego.

Pisanie osobnej metody do każdego switch case przy długim drzewie jest słabe, potem odnalezć i zrozumieć i rozrysować ścieżkę kolejnych switch case'ów jest straszliwą katorgą dla niewtajemniczonego zasiadającego do Twojego kodu programisty.

51 minut temu, Libertyn napisał:

Nie chciałbyś mieć banku postawionego na Pythonie i Django.

Odwrotnie, Python, PHP czy .node są do dużych serwisów internetowych publicznych. Nie znam dużego serwisu webowego napisanego w Java. Java jest raczej do wewnętrznych systemów, nie do dużych otwartych serwisów, bo do tych pisze się w językach skryptowych.

fb, yahoo, ali express, ebay, itd. wszystko to jest pisane w skryptowych językach.

 

Edytowane 20 Marca 2020 przez mindo

[Reflux]

@Libertyn Zastanów się co chcesz zrobić, bo przedstawiony przez ciebie problem można sprowadzić do zwykłego lookup table'a, paru enumów i jednego switcha. 

9 godzin temu, Libertyn napisał:

Zastanawiam się nad The State pattern.

Factory? Jak to widzisz?

State pattern -> jeśli w twoich stanach jest coś więcej niż tylko proste informacje takie jak lista opcji i metoda exit lub też twoja maszyna stanu oparta na switchach będzie gigantyczna.
Factory -> Możesz oczywiście tylko potem masakryczne będzie dodawanie kolejnych opcji.

Wszystko rozbija się o parę rzeczy, jak skomplikowane drzewo decyzyjne przewidujesz, czy masz ustalone ścieżki za każdym razem i na czym ci najbardziej zależy.
Czy na poznaniu sposobu poruszania się po drzewach? 
Czy zwyczajnym zrobieniu zadania?
 

8 godzin temu, Ancalagon napisał:

Ja tam lubię sobie w Factory używać klas anonimowych, ciekawe co na to wszystko @Reflux 

Do tak prostego przykładu to za dużo pisania mieć nie będzie i to chyba najlepsze rozwiązanie w tym wypadku.
Jeśli jego drzewko się rozrośnie do zbyt dużych rozmiarów to wtedy state pattern będzie lepszy i znacznie bardziej czytelny.

Edytowane 20 Marca 2020 przez Reflux

[Libertyn]

To drzewko decyzji samo w sobie jest skomplikowane.

Mam nadzieję że to jakoś zobrazuje. Cyfra symbolizuje ilość możliwych decyzji przy założeniu braku cofania się do poprzedniego widoku. Na górze mamy karczme, niżej sklepy

3--5 --4 --3 --2-- 1(powrót na początek)

     6

     3

Jak się uda, rozrysuje z pomocą bpmn

[Druid]

22 godziny temu, Libertyn napisał:

którego wspomniana JAVA miała zastąpić

Bardzo ciekawe spostrzeżenia, jeśli chodzi o programowanie to co według ciebie jest lepsze na rynku pracy ? Znajomość JAVY czy Pythona ?

[Kapitan Horyzont]

Naucz się porządnie dowolnego z nich.

[Libertyn]

24 minuty temu, Boromir napisał:

Bardzo ciekawe spostrzeżenia, jeśli chodzi o programowanie to co według ciebie jest lepsze na rynku pracy ? Znajomość JAVY czy Pythona ?

Różnie. To się co chwile zmienia, raz Python, raz Java, innym razem znowu Node.js.

Ważne by w tym siedzieć i coś realnie móc pokazać.

 

Koniec końców użyłem State Machine Pattern

Edytowane 20 Marca 2020 przez Libertyn