Sylně typovaný vs. dynamický má svoje výhody i nevýhody. Říká se, že se v něm rychleji píše. Otázkou je jak vhodně nebo nevhodně spustí automatické konverze z typu na typ.
Na druhou stranu pokud člověk použije inteligentní IDE (Eclipse, IdeaJ)
řekl bych, že odpadá tolik bušení do různých písmen – protože např. ví jaká instance kterého objektu je proměnná inteligentě napoví pouze dané metody nebo viditelné proměnné. Metody se můžou lišit, takže můžete zkrátit jejich jména a vyhnout se všem různým berličkám jako funcX_TStr atp.
Pak můžete pomocí doslová 2 kliknutí měnit metody a změny se projeví všude! Třeba já to hodně to využívám, že si nejdřív pojmenuju všechny věci jedním dvě písmeny „x = a(y);“ a ve finále je přejmenuju tak, aby se kod dal číst jako věty "Vec[] setridenePoleVeci = triditPole(poleVeci[]);
Ale celkově je spíš rozdíl v OOP vs Skript.
Třeba uživatelé můžou být:
User:
← IndividialUser implements PaymentAware
← CompanyUser (companUser [*] – [1] Company) kde Company implements PaymentAware
a pak zavoláte něco jako shoppingCart.pay(User.resolvePaymentAware( currentUser.principal ));
Celkově shrnuto a podtrženo: je o to minimalizovat udržování globálních stavů a šílených if elseif elseif elseif a switch větví.
viz na příkladě místo:
((A))
if(user is Individual)
return basePrice * vatMultiplier; /* osoba vzdy platí dph */
if (user is Company)
if(user.company.payVat)
return basePrice * vatMultiplier;
else
return basePrice;
nahradíte:
((B))
Interface VatPaymentAware { Money calculatePrice(Money price); }
class Individual implements VatPaymentAware
{
Money calculatePrice(Money price) { return basePrice * vatMultiplier; }
}
class Company implements VatPaymentAware
{
Money calculatePrice(Money price) { return basePrice * vatMultiplier; }
}
class VatPayerCompany extends Company
{
String euVatId;
Money calculatePrice(Money price) { return basePrice; }
}
a ted:
class PayerResolver {
protected static final PayerResolver singleton = new ...;
PaymentAware resolvePaymentAware(Individual ...);
PaymentAware resolvePaymentAware(CompanyUser ...);
}
a ((A)) se nahradi>
PayerResolver.resolvePaymentAware(
pravePrihlasenyUzivatel).calculatePrice();
Výhody:
a) nikde nemám konstrukci isVatPayer nebo boolean paysVat
b) PayerResolver.resolvePaymentAware(
pravePrihlasenyUzivatel).calculatePrice(); použiju všude kde potřebuju cenu
Takže to vypadá, že je lepší to napsat všude jako if ..
Pokud nemáte vyřešeno oddělení business logic a view tak if nebude nikde stejný (to znamená např. otestovat znova x stránek v PHP jestli jsem si nezavedl chybu někde jinde).
A pak je tu další rozšiřitelnost: zákazník běží aplikaci nějaký pátek a příjde že chce, aby jeho účetní měl cenu = 0.
Přidáse BookKeeperUser s OurCompany kde cena bude nula, ale jinak všude jinde se chová stejně, takže implementace ShoppingCart se vůbec nezmění a vy zůstane ušetřen mnoha možných chyb.
Ono na web* se to špatně vysvětluje, proč je to tak lepší. Lepší příklad je na počítačové hře.
Ty se sice dělají v C (a předělávají v jisté fázi do C++)
Vemte si třeba
function double armorDefenseRate(TStrelaTyp strela, TJednotka cil)
{
switch(cil)
{
case TANK: switch(strela->typ()) case RAKETA_Z_RPG: return -10;
case SOLDA: switch(strela->typ()) case RAKETA_Z_RPG: return -1000;
...
}
naproti tomu:
cil.dostalZasah(Strela strela)
P>
class T80 implements Tank {
double hp;
dostalZasah(Strela strela) {
strela.doDamage(this); /* Pomocí tohoto vzoru se dostanu na volaní konkretní střely s konkrétním jednotkou, tady tank a přitom nepoužiji explicitní přetypování */
}
Uplný závěr: překlepy nejsou díky IDE (skoro) možné. Vývoj je více stabilní (znovu-použití, zakrývání stavů), silně podporované Unit testování (i tzv. reflexe), za cenu poměrně pomalého vývoje. JBoss se dá alespoň verze 4 rozeběhat pro pár uživatelů (desítky) na ráz na 128MB paměti a 200MHz počítači (to k té nenažranosti Javy, nejsme sami, kdo má takhle devel a test mašiny postavené na VPS)
Zkuste se podívat na frameworky jako je JBoss Seam ( http://www.jboss.com/products/seam/ , http://java.cz/…czpodcast-21 ) je to skoro klikací framework!
Nebo na Google Widget Toolkit: http://code.google.com/…verview.html
Nevýhody: Pokud nemáte alespoň vlastní VPS (virtuální server) dost těžko se projekt někde vystavuje a zadarmo hodně težko. Vývoj může být delší (závisí jestli si vyberete správný framework a jaké máte znalosti best practices).
Komunita pro opensource projekt (free etc.) je menší u Javy…
