Java - vad är det som är pest och pina med det?

Jo helt riktigt. Jag ska vara tyst. Har bara lite svårt för enkelriktade diskussioner och blir ibland lite upprörd när jag hör saker som jag tycker är dålig programmeringsmetodik (dvs properties-funktionaliteten).

Som sagt, jag ska vara tyst 8-).

//C

Vad är dåligt med properties? Det är ju guld framför fula get set metoder

Har man en lösning som kräver massor med getters/setters så tyder det oftast på att ens nuvarande design/lösning är riktigt dålig och bör omarbetas.

I ett stort system med mycket ett stort Command lager kan det krävas en kontrollers som uppdaterar commando lagret med status, då är ju properties nödvändigt. Sedan är ju properties det man databindar mot...

Jag håller med MagnusL och conio, inkapslingen blir mycket sämre när programmeringsspråket man använder förespråkar getter/setter-metoder. Däremot finns det ett enda tillfälle jag kan se det användbart i Java, men det är inget stort område och det är väldigt få större projekt som utvecklas med den typen av programmering - och det är användandet av bönor vid backweb-programmering för formulär. Där är "man tvungen" att skriva getter/setter-metoder om man vill ha automatisk validering av sina formulär. Däremot tycker jag att det är varken pest eller pina att denna funktionalitet inte finns i Java...

Om nu propeties var så dåligt, varför har då utvecklarna på MS valt att utöka detta ännu mer i .Net 3.0?

Dålig sammanhållning, inkapsling och allmänt dålig arkitektur har inget med om du väljer properties eller get / set metoder, det har med att göra hur du implementerar det... Om du frågar mig

Då är jag intresserad hur du tycker man ska konstruera businessobjekt med ~50 attribut, om det är dålig design att använda publika (set/get eller properties) sätt att operera på dessa attribut?

Attribute ändras både på clienten och på servern av användaren, valideringsregler och businesslogik.

EDIT: Dessutom ska lösningen stöda olika cultures etc, dvs. krav man förknippar med ett businessobjekt.

Haha, vem tror det? Hjärnbefriat inlägg om du frågar mig. Men ffs, de flesta större system har ganska mycket data att skicka mellan de olika lagren (fast ni som inte förespråkar properties kanske inte kodar enligt lager arkitektur )

Och då är det ju rätt bra att ha ett Modell-lager som alla lager känner till där rena databärare ligger (tunna objekt utan logik, bara data). Och hur tror du man styr åtkomsten av data? Jo med properties

edit: ett rätt bra mönster är att använda internal konstruktorer så att Backend får agera factory och View bara kan läsa properties...

Men vem tror att OOP har att göra med om det valda språket stödjer properties eller get / set metoder?

Din lilla undersökning av detta kan ju inte gjorts på branschfolk iallafall.

Jag tror de flesta håller med mig om att OOP handlar om att göra flexibel, lättförståd, lättunderhållen och skalbar kod..

Om vi bortser från att du inte pratar med mig kanske du kan svara på detta..

Om vi nu förutsätter att vi har ett applikatonslager som helt enkelt kräver en rätt stor mängd databärare. Då förespråkar du allså att ha publika medlemmar istället för att styra accessen via properties?

Jag håller helt med dig att objektorientering handlar om inkapsling (bla.). Men det gäller ju implemenation. Man måste ju fortfarande kunna utbyta data på ett vettigt sätt...

Inte högre upp i hirarkin? Så om du vill uppdatera vyn då mappar du om modelobjektet till nått annat som vyn får känna till?

Vitsen (en av dem) med modellobjekt är ju att alla känner till dem men vyn bara kan läsa, vill den ändra nått får den göra det via Facade-lagret...

Ett exempel från ett program jag skrivit:

edit: detta är från en powerpoint slide jag gjorde, följer inte UML...
edit2: swec skalar bilden, titta på den i fullskala...

Kan du utveckla det där? Hur kommer det sig att det är så?

Var bara ett exempel. Applicerar inte alltid, har dock stött på ett par fall då det har varit ungefär så.

Tidiga javaversionerna var väl riktigt slöa i kanten, men nu förtiden skall man inte klaga. 3-4 gånger långsammare än C++ är inte alls dåligt.

För det första går det visst, men du måste deklarera som Integer (objekt) istället för int (primitiv). Tycker det är bra att man skiljer på primitiva typer och objekt. Allt annat känns väldigt konstigt i min värld. Som i C#. Har fortfarande inte fattat skillnaden mellan object och Object, string och String, int och Int32(!). För det verkar ju utmärkt att använda samma metoder på båda?

Java är iofs inte heller helt snyggt alla gånger. Arrays som inte är objekt men som ändå har length som "property" exv. Men tycker trots detta att Java är LÅNGT mer rent än tex C# (som jag just nu håller på att lära mig, burr).

Håller inte med. Gillar tex. swingbiblioteket bättre än windows forms, just för att det finns en tydligare separation mellan layout och innehåll. Där med inte sagt att swing är det ultimata GUI-biblioteket.

Jaha, och på vilket sätt är detta en nackdel?

Men detta beror väl mer på hemsk programmeringsteknik än språket i sig?

Glöm att C# är i princip lika snabbt som C++. Dock är det något snabbare än Java. Men detta beror ju mer på att C# är väldigt hårt integrerat och optimerat för ett speciellt operativsystem. Java är som bekant plattformsoberoende. Än jämförelse J2SE vs. Monoimplementationen vore mer rättvis.

För mycket skrivande för lite resultat. Lång utförlig syntax kanske är tydligare att läsa för de som är ny, men är en käpp i hjulet för mig när jag kodar.
Sedan att kombinera med C/C++-kod.. ajajaj så mycket syntax innan man får något gjort.

Jag skulle nog våga påstå att java jämfört med C och C++ inte på något sätt skulle ha ett långt syntax?
Vad i språket anser du är långt och besvärligt?