Zdroje k rozvoji OOP myšlení

[Polymath]

No jasně, mezi ně patří ty hromady veřejných *etterů, které ve třídách nemají co pohledávat. Když je odstraníš, často zbude jen hromada privátních (v horším případě protected) atributů a žádná metoda. S takovými objekty se pak nedá ani pracovat, protože nic neumí.

To ale ničemu nevadí. Prostě OOP je in, tak ho tam je třeba narvat za každou cenu. Tak je to správné a tak to má být.

OOP je římskými číslicemi dnešní doby...

Každé paradigma má své výhody i nevýhody a každé z nich má své uplatnění. Teď je sice hype funkcionální programování (podobně jako před 20-30 lety), ale například na deklarativní se docela zapomíná. Zřejmě proto, že nemá chybu

FP je deklarativní.

[Reklama]

[Kit]

Každé paradigma má své výhody i nevýhody a každé z nich má své uplatnění. Teď je sice hype funkcionální programování (podobně jako před 20-30 lety), ale například na deklarativní se docela zapomíná. Zřejmě proto, že nemá chybu

FP je deklarativní.

Ovšem ne každé deklarativní programování je funkcionální.

[-j-]

Arafat je pro OOP úplnej základ.

[Kit]

Arafat je pro OOP úplnej základ.

Byl...

[jpu]

ako by ste premenili toto do OOP pomocou polymorfizmu:

Kód: [Vybrat]

public string Deregister(ServerReason reason)
        {
            switch (reason)
            {
                case ServerReason.Operator:
                    Navigate(typeof(LoginPage1), true);
                    return string.Format(LocalizationHelper.GetLocalizedString("OP"));
                case ServerReason.DifferentLocation:
                    Navigate(typeof(LoginPage1), true);
                    return LocalizationHelper.GetLocalizedString("AnotherLocation");
                case ServerReason.LimitReached:
                case ServerReason.SupportedFeaturesLimitReached:
                    Navigate(typeof(LoginPage1), true);
                    return LocalizationHelper.GetLocalizedString("MaxUsers");
                case ServerReason.TrialExpired:
                    Navigate(typeof(LoginPage1), true);
                    return LocalizationHelper.GetLocalizedString("UserTrial");
                default:
                    return string.Format(LocalizationHelper.GetLocalizedString("Disconnected"));
            }
        }


Dakujem za napady

[Reklama]

[dustin]

Ty jednotlivé reasons by nebyla pouhá čísla, ale enumy s metodami navigate() a toString()/getDescription(). Očividně je ten reason nejen číslo, ale nese si i nějaké znalosti/dovednosti (konkrétní postupy v navigate(), nějak se v UI jmenuje, atd.). Tipuju si, že při likvidaci takových casů přes reasons rozházených různě po kódu by se nakonec ukázalo, že  reasons toho umí ještě víc -> další metody.

[Kit]

ako by ste premenili toto do OOP pomocou polymorfizmu:
Dakujem za napady

Zkus se podívat, jak se v Javě používá enum.

[balki]

ako by ste premenili toto do OOP pomocou polymorfizmu:

Kód: [Vybrat]

public string Deregister(ServerReason reason)
        {
            switch (reason)
            {
                case ServerReason.Operator:
                    Navigate(typeof(LoginPage1), true);
                    return string.Format(LocalizationHelper.GetLocalizedString("OP"));
                case ServerReason.DifferentLocation:
                    Navigate(typeof(LoginPage1), true);
                    return LocalizationHelper.GetLocalizedString("AnotherLocation");
                case ServerReason.LimitReached:
                case ServerReason.SupportedFeaturesLimitReached:
                    Navigate(typeof(LoginPage1), true);
                    return LocalizationHelper.GetLocalizedString("MaxUsers");
                case ServerReason.TrialExpired:
                    Navigate(typeof(LoginPage1), true);
                    return LocalizationHelper.GetLocalizedString("UserTrial");
                default:
                    return string.Format(LocalizationHelper.GetLocalizedString("Disconnected"));
            }
        }


Dakujem za napady

Ak to velmi treba objektovo, tak vzor visitor. Kazdy potomok triedy Serverreason by mal v sebe metodu deregisterVisit (meno som zvolil debilne, ale nazorne) a v nej prislusny kod, co treba vykonat.

V metode deregister, ktoru ste napisali vyssie by sa uz len volala metoda deregisterVisit.

[jpu]

aby som este ozrejmil. deregister je event, ktory je vyvolany na zaklade volania metody z kniznice od tretej strany

[balki]

aby som este ozrejmil. deregister je event, ktory je vyvolany na zaklade volania metody z kniznice od tretej strany

Tak potom, ak aj tak silou-mocou to musi byt objektovo, tak pre kazdy Serverreason si vytvorit objekt s danou logikou a spolocnou metodou "tralala". Ulozit tieto objekty  do hashmapy a indexovat hashmapu pomocou ServerReason.

Pri zavolani vytiahnut objekt z hashmapy a zavolat patricnu metodu "tralala".

[jpu]

nehovorim, ze to musi byt silou-mocou OOP, len mi prislo na mysel spytat sa, ako by ste to zoptimalizovali do OOP podoby.
dakujem za navrhy

[dustin]

Pokud je to volání jen na jednom místě a ty ServerReasons nemají v tvém kódu jiné využití, pak nějak nechápu, k čemu by bylo předělání do objektů užitečné.

[Kit]

nehovorim, ze to musi byt silou-mocou OOP, len mi prislo na mysel spytat sa, ako by ste to zoptimalizovali do OOP podoby.
dakujem za navrhy

Optimalizovat pouze část aplikace do OOP bez objektových vazeb na zbývající komponenty je jen plýtváním časem.

Volání by mělo vypadat asi takto:

Kód: [Vybrat]

reason.deregister();nezávisle na třídě, ze které je vytvořena instance reason. Každá taková třída musí tedy implementovat rozhraní, které obsahuje metodu deregister(). Dle rozpisu to budou třídy Operator, DifferentLocation, LimitReached, SupportedFeaturesLimitReached, TrialExpired apod. Samozřejmě se předpokládá, že tyto třídy budou implementovat i další metody takového rozhraní a z aplikace tak zmizí i další switche s objektem reason. Třídu ServerReason předěláš dle vzoru Factory.

[BoneFlute]

nehovorim, ze to musi byt silou-mocou OOP, len mi prislo na mysel spytat sa, ako by ste to zoptimalizovali do OOP podoby.
dakujem za navrhy

No, při zvažování jak to zoptimalizovat záleží na dalších aspektech, ne jen zda to jde. Něky převést to do OOP může být neoptimální.

Třeba já bych zvažoval, zda chci, aby objekty: Operator, DifferentLocation, LimitReached,... uměli zpracovat registraci a deregistraci. Dovedu si představit případ, kdy bych to považoval za nežádoucí a nechtěl bych, aby to znali.