NetBeans oder Eclipse?

[_ebm_]

Irgendwann stellst du jedoch fest, daß du mit einem String nicht mehr weiter kommst, weil du z.B. wissen willst, wie viel diese Person monatlich verdient.

Oh nein, das einzige was du da feststellst, ist dass du zu früh angefangen hast zu implementieren!

Dieses Getter/Setter-Geraffel wurde nur für einen Zweg erfunden, um EJB zu ermöglichen, auf Felder zuzugreifen und dabei Zugriffskontrolle zu haben. Dieses Gehangel mit nachträglichem Erweitern der Fähigkeiten eines Feldes zeigt einfach nur, dass drauf los programmiert wurde, ohne vorher einen Entwurf der Anwendung zu machen. Der Entwurf stimmt also nicht und soll dann mit "sauberen" OO-Techniken kaschiert werden. Oh nein, mir wird schlecht. Ich glaub, sowas nannte man Fast Prototyping oder auf neudeutsch "hingehackt"...

Sorry, dein Beispiel zieht bei mir nicht.

Gruß Carsten

 

[gishmo]

@_ebm_:
Schon mal an den Application Life Cycle gedacht? Ganz ehrlich, deine Software möchte ich nicht warten ...

 

[_ebm_]

gishmo,

ich weiß ja nicht, was du so programmierst. Ich bin in den letzten 10 Jahren gänzlich ohne getter/setter-Pärchen ausgekommen. Es mag Fälle geben, wo sie sinnvoll sind. Für mich ist das aber ein Kropf wie goto.

Gegen getFoo() allein hab ich übrigens garnichts! (siehe oben) Mit dem obigen Beispiel änderst du aber die Semantik von Person, fügst Eigenschaften hinzu! Benutzt du dann weiterhin die alte Schnittstelle, setzt du nur ein einziges Feld der Klasse Person. Das kann zu sehr unschönen Nebeneffekten führen.

Wenn sich Person ändert, muss die klasse GibtsNich erweitert werden, nicht irgendein Feld darin! Wenn du Person einführst, musst du dann auch Person als Struct verarbeiten und nicht als String! Wenn du der Meinung bist, Person könnte sich irgendwann mal ändern, legst du es gleich als Struktur an! Das nenne ich Software-Entwurf!

Um solche Veränderungen zu sehen, gibt es übrigens Refactoring-Funktionen!

 

[das_Pathos]

wir sind von Eclipse auf Netbeans wegen UML umgestiegen, wobei mir persoenlich besser Eclipse gefaellt. Fuer PHP benutz ich weiterhin Eclipse.

 

[_ebm_]

Ich trag mal noch etwas zum Thema bei: Ich setze derzeit primär Eclipse ein (Java, PHP, HTML, CSS, ...). Hauptgrund sind die besseren Team-Fähigkeiten (Trac-Anbindung, Mylyn....).

Netbeans ist für mich ein erstklassiger GUI-Editor. Da gibt es derzeit nichts besseres für Java.

Dann heb ich nochmal IntelliJ IDEA hervor, leider kommerziell, aber mit den besten Refactoring-Funktionen, die ich bisher gesehen hab.

 

[Darii]

Und schon hast du das Dilemma. Wenn die Klasse GibtsNich nur in einer Anwendung genutzt wurde, zu der du auch den Quellcode hast, ist es halb so tragisch. Wird die Klasse GibtsNich jedoch von diversen anderen Projekten genutzt, müssen alle Projekte umgeschrieben werden.

Hättest du mit Gettern und Settern gearbeitet gäbe es nicht das Problem. Lösung:

Eine geeignete Sprache vorausgesetzt, ersetzt man das Attribut bei Bedarf einfach durch eine Property und die anderen Projekte merken gar nicht, dass sich irgendwas geändert hat.

 

[mybookpro]

OK... und was ist für nen Java- Neulich geeigneter? Eines übersichtlicher oder startklarer, oder so??

Für einen "blutigen Neuling" würd ich BlueJ verwenden. Das hatten wir auch in der Schule. Das nimmt dir für den Anfang einmal das erstellen der main-Methode ab und stellt den Aufbau der Klassen, Assoziatonen, Vererbungen, ... auch recht gut grafisch (UML-Like) dar.

Wenn man dann mal soweit ist, dass man das Grundkonzept verstanden hat, mit den Datentypen klarkommt und die main-Methode versteht würd ich auf Eclipse umsteigen. Ich benutz auch seit langem Eclipse und muss sagen, dass es recht praktisch ist. Muss aber zugeben das ich noch kein anderes IDE ausprobiert habe.

MfG
mybookpro

 

[mybookpro]

Setter halte ich grundsätzlich für überflüssig, solange dort nur Felder gesetzt werden. Getter dienen ja wenigstens noch als Read-Only-Option. Und sobald eine Methode mehr tut als nur einen wert zu setzen, ist das kein Setter mehr!! Eine Kombination von Beiden auf einem Feld ist absoluter Schwachsinn!

Ich weiß übrigens genau, was Code-Encapsulation ist...

Das dachte ich anfangs auch. Aber sobald du über den Rand einer Klasse hinauskommst und du lernst was Assoziationen und Vererbungen sind wirst du schon sehen das du ohne get- und set-Methoden nicht weit kommen wirst.

Das "blöde" an Java ist meiner Meinung nach, dass man Anfangs vieles als gegeben hinnehmen muss und nicht gleich alles als logisch erscheint. Umso weiter man dann in Java eintaucht um schlüssiger wird einem dann das ganze.

MfG
mybookpro

 

[_ebm_]

Bei der Zusammenarbeit zwischen Projekten entwirft man üblicherweise auch soetwas wie APIs. Was hinter diesen Schnittstellen passiert, interessiert dann nicht weiter. Veränderungen an den Implementierungen darf nicht in andere Projekte durchschlagen. Das betrifft auch über diese APIs ausgetauschte Datenstrukturen! Globale Properties sind übrigens bei sowas tabu! Du weißt nicht, welche Properties in dem anderen Projekt gesetzt werden und ob sie diese überschreiben. Austausch lokaler Properties lohnt sich nur, wenn man diese auch persistieren möchte. Sonst sind Klassen/Strukturen die bessere Wahl weil leichter handhabbar.

Fabian, so ganz nebenbei: du hast in deinem Beispiel die Personen-Struktur ohne Getter/Setter gestaltet. Warum?

Gruß Carsten

 

[_ebm_]

Das dachte ich anfangs auch. Aber sobald du über den Rand einer Klasse hinauskommst und du lernst was Assoziationen und Vererbungen sind wirst du schon sehen das du ohne get- und set-Methoden nicht weit kommen wirst.

Das "blöde" an Java ist meiner Meinung nach, dass man Anfangs vieles als gegeben hinnehmen muss und nicht gleich alles als logisch erscheint. Umso weiter man dann in Java eintaucht um schlüssiger wird einem dann das ganze.

MfG
mybookpro

So ganz nebenbei: Ich programmiere seit 8 Jahren mit Java und kenne Stärken und Schwächen sehr gut. Aber gerade Getter/Setter haben nichts mit Java sondern mit einem Designpattern (Bean-Pattern) zutun.

 

[mybookpro]

So ganz nebenbei: Ich programmiere seit 6 Jahren mit Java und kenne Stärken und Schwächen sehr gut. Aber gerade Getter/Setter haben nichts mit Java sondern mit einem Designpattern (Bean-Pattern) zutun.

Dann muss ich mich wohl entschuldigen . Ich hab in meinem Halbschlaf wohl was missverstanden bzw. war ich zu Faul die Vorgeschichte zu lesen. Aber mir war das Problem noch so von meinem Start in Java bekannt, da konnte ich nicht anders.

Ich bitte um Entschuldigung

MfG
mybookpro

 

[_ebm_]

Schon ok

 

[Fabi_K]

Fabian, so ganz nebenbei: du hast in deinem Beispiel die Personen-Struktur ohne Getter/Setter gestaltet. Warum?

War zu faul.


Gruß Fabian

 

[_ebm_]

War zu faul.


Gruß Fabian

Ich hoffe, du hast aber dabei daran gedacht, dass es eine Instanz von Person geben muß, wenn du getPerson() rufst. Da person eine Klassenvariable vom komplexen Typ Person (eine Klasse) ist, muß sie dann im Konstruktor initialisiert werden, damit danach jederzeit darauf zugegriffen werden kann. Damit nagelst du GibtsNich auf eine einzige Instanz von Person fest. Du kapselst also nur ein paar Eigenschaften in eine Klasse und erzeugst Overhead durch Classloader-Operationen und überflüssige Funktionsrufe. Da ist es dann besser, du erweiterst GibtsNich um die paar Felder aus Person und dokumentierst ordentlich.

Meine letzte Meinung zu dem Thema..