Welche Programmiersprache für mich?

Status
Für weitere Antworten geschlossen.
F_GXdx schrieb:
Bei Java macht man es aber einfach nicht, dass man auf Membervariablen einer anderen Klasse zugreift.

Macht man bei C# auch nicht. Was ist jetzt das Problem mit Count?

F_GXdx schrieb:
Es muss nicht immer Datenkapselung verletzen, aber es tendiert dazu.

Properties? Wo denn :confused_alt:
 
1 Million Beispiele.

Membervariablen sind Teil der Daten einer Klasse. Verhalten, um diese Daten zu verändern gehört in Methoden. Die Klasse sollte selbst bestimmen, unter welchen Bedingungen etc. ihre Daten geändert werden dürfen.

Wenn jetzt externe Klassen bei anderen Klassen in den Variablen rumpfuschen, führt das langfristig garantiert zu Bugs. Außerdem erschwert es möglicherweise das debuggen, außer man hat einen Rückwärtsdebugger.

---

Das Problem mit count ist, dass ich das wort count nicht mag. Subjektiv.
 
Ja, das ist soweit klar. Aber deine Aussage zu Count ("...ist halt irgendwie besser als Count ...weil es zum Beispiel auch nicht gegen die Datenkapselung verstößt") ist halt einfach falsch, oder wie meintest du das?
 
Zuletzt bearbeitet:
OK - die Aussage war falsch so.

Allerdings hat man halt das Problem, wenn man Properties und Methoden mischt, dass man dann nie weiß, ob man Klammern braucht oder nicht. Das klingt jetzt lächerlich, aber mich stört es schon. Man muss immer kurz aufs Autocomplete warten (bzw es benutzen) und das nimmt Tempo raus, - außer man kennt alle Klassen mit allen Methoden und Properties eines Programms auswendig...

Bei Java und C++ weiß ich, alles ist eine Methode. Da wenn ich was runtercode, muss ich nicht überlegen, hab überall meine Methoden und fertig. Es programmiert sich so einfach homogener.

Auch längere Anweisungen sehen dann so aus:

Code:
meineKlasse.getChildKlasse().anotherChild.getFullQualifiedName().German.getShortName();

(BAAAAAHHHHH)

Bei C# stört mich das einfach ungemein. Ich mag Properties einfach nicht. Obwohl es im Prinzip natürlich schon stimmt - überflüssige Zeichen sollte eine Programmiersprache vermeiden, siehe Python.
 
Zuletzt bearbeitet:
Naja, kann man genau so gut andersherum argumentieren.

Sachen wie

Code:
String zip = customer.Address.ZipCode;
customer.Address.ZipCode = "6985";

sind imho 10x schöner als

Code:
String zip = customer.getAddress().getZipCode();
customer.getAddress().setZipCode("6985");

Zumal man im Gegensatz zu Java damit homogen zu Konstanten bzw. Enumerationen ist (schließlich heißt es auch in Java nicht Color.getGreen()). Properties sind für Daten, Methoden für Verhalten, gerade eben wenn beides vermischt wird ist das aussagekräftig: customer.Address.ZipCode.ToCharArray();.

Den Codeschnipsel, den du da gepostet hast, ist entweder erfunden oder aus einer sehr schlecht desingten Klasse oder API. Es gibt keinen Grund, warum der vollqualifizierte oder kurze Name über eine Methode zugänglich gemacht werden statt über ein Property, selbst getChildKlasse wird eher keine Methode sein (vgl. exemplarisch C# DOM API, z.B. node.FirstChild oder node.ChildNodes - beides keine Methoden, sondern Properties).

Aber der große Vorteil liegt ja eigentlich in der Vermeidung von boilerplate-Code bei gettern/settern, wenn diese eh nicht anderes beinhalten als die einzeilige Zuweisung bzw. return. Eine Klasse mit 6 Attributen besteht in C# in diesem Fall aus 6 Zeilen (+ Klassendefiniton oben), in Java hingegen aus 40-50 Zeilen.
 
Zuletzt bearbeitet:
Sehr gutes Beispiel dcobra. Stimme da 100% zu. Es ist schon richtig, dass man die Vorgänge hintendran nicht direkt sieht. Aber sowas wie
Code:
public string something { get; private set; }
ist dafür einfach unglaublich praktisch und gut lesbar. Ich bin auch noch nie dadurch bei Java oder C# durcheinander gekommen. Dafür habe ich aber schon Features wie Linq oder Extensions vermisst. Klar ist es doch sehr komfortabel und wird von vielen evtl. falsch eingesetzt, aber gerade in Sprachen wie Java/C# haben solche "extra" Sprachfeatures meiner Meinung nach schon Platz.
 
Zuletzt bearbeitet:
dcobra schrieb:
Aber der große Vorteil liegt ja eigentlich in der Vermeidung von boilerplate-Code bei gettern/settern, wenn diese eh nicht anderes beinhalten als die einzeilige Zuweisung bzw. return. Eine Klasse mit 6 Attributen besteht in C# in diesem Fall aus 6 Zeilen (+ Klassendefiniton oben), in Java hingegen aus 40-50 Zeilen.

In PHP gibts dafür einfach die Magischen Methoden. Einmal __get() definieren und fertig.
Der Vorteil an echten Gettern und Settern ist doch, dass man somit eine gute Zugriffssteuerung für Private/Protected Attribute hat.
 
Daaron schrieb:
In PHP gibts dafür einfach die Magischen Methoden. Einmal __get() definieren und fertig.

Ist imho leider nur eine Frickellösung, wobei man wieder was an PHP drangebastelt hat, was es eigentlich nicht kann. Das zeigt sich schon daran, dass du den Begriff "echte" Getter/Setter verwenden musst.
 
Ich bezog mich auf "String zip = customer.Address.ZipCode;".
Im vergleich dazu ist ein ->getZipCode() eben eine richtige Getter-Methode, die eben auch MEHR machen kann, als einfach nur ein Attribut stur zurückgeben. Man könnte z.B. dahinter noch eine Datenbank-Abfrage packen. Erst wenn das Attribut auch wirklich benötigt wird, wird es aus der DB geladen. Kann u.U. Sinn machen.

Spätestens bei ->setZipCode("00000") vs. ->zipCode="00000" merkst du einen gewaltigen Unterschied. setZipCode() kann hier z.B. erst mal noch eine Plausibilitätsprüfung machen. Ist mein Wert ein String (PLZs sind in Deutschland keine Integer)? Besteht er nur aus Ziffern? Hat er 5 Stellen? Lautet er NICHT "00000"?
Eine einfache Variablenzuweisung kann so etwas nicht.

Evtl. solltest du dich mal mehr mit PHP beschäftigten, dann würdest du gerade die Magischen Methoden nicht als Frickellösung bezeichnen. Aber du bist ja sicher auch so einer, der PHP mit Ruby on Rails vergleicht, nicht?
 
Code:
        private string zipcode;

        public string Zipcode
        {
            internal get 
            { 
                // Datenbankabfrage hier
                return zipcode; 
            }
            protected set 
            {
                if (value.Length != 5)
                {
                    // blabla
                }
                zipcode = value; 
            }
        }
kein Problem. Oder worauf wolltest du jetzt hinaus? Es ist eben alles möglich. Oder war das jetzt nur auf PHP bezogen?
 
Das geht in C# (und bestimmt auch in anderen Sprachen), nicht aber in Java ;).
Dann muss man dann schon zwischen einfachen Membervariablen und Properties unterscheiden, an der Schreibweise beim Zugriff ist da ja erst mal kein Unterschied zu erkennen.
 
Zuletzt bearbeitet:
Daaron schrieb:
Ich bezog mich auf "String zip = customer.Address.ZipCode;".
Im vergleich dazu ist ein ->getZipCode() eben eine richtige Getter-Methode, die eben auch MEHR machen kann, als einfach nur ein Attribut stur zurückgeben.

Was er meinte ist in C# ebenso ein "richtiger" Getter (customer.Address.ZipCode), siehe hierzu BlooDFreeZe, genau darum geht's doch die ganze Zeit...
Eine Variable mit Standard-Getter/Setter benötigt in C# und beispielsweise Scala genau eine Zeile, in Java, C++ und Co. hingegen neben der Variablendefinition selbst noch 2 Methoden.

Eventuell verwirren dich die Begrifflichkeiten, "Property" ist in C# der Begriff für das Konstrukt aus dem Beitrag von BlooDFreeZe, nicht etwa für die Attribute selbst.

iks-deh schrieb:
Dann muss man dann schon zwischen einfachen Membervariablen und Properties unterscheiden, an der Schreibweise beim Zugriff ist da ja erst mal kein Unterschied zu erkennen.

Das ist genau der Sinn der Sache, weil es viel intuitiver ist als ein getXXX() oder setXXX(). Und der Unterscheid ist Konvention: Membervariablen schreibt man klein, Properties groß. Die IDE zeigt es des Weiteren an, und aus technischer Sicht ist es eh etwas ganz anderes (man kann Properties z.B. in Interfaces definieren, Variablen nicht).
 
Zuletzt bearbeitet:
Daaron schrieb:
[....]
Eine einfache Variablenzuweisung kann so etwas nicht.

customer.Address.ZipCode = "6985" ist eben keine einfache Variablenzuweisung in Sprachen wie C#, Scala und Groovy, da kann genauso gut Logik dahinterstecken. Aber es wurde genug gesagt dazu, Google hilft weiter.

Daaron schrieb:
Evtl. solltest du dich mal mehr mit PHP beschäftigten...

Habe in der Tat nur selten mit PHP zu tun, aber __get und __set erscheinen mir eben als Frickellösung. Vielleicht habe ich es nur nicht kapiert, aber da hilfst du mir sicher gerne weiter.
Als Annahme lege ich vorab fest, dass man durchgehend entweder nur klassische get/set-Methoden verwenden sollte oder aber durchgehend nur __get und __set, um eben konsistent zu bleiben. Ich denke, da sind wir uns einig.

Ich entscheide mich also für __get und __set und baue sowas ein:

PHP:
public function __set($property, $value) {
        if (property_exists($this, $property)) {
            $this->$property = $value;
        }
}

Was ist jetzt aber, wenn ich feststelle, dass 3 oder 4 Membervariablen von 10 nun doch eigene Logik im Setter benötigen? Geht das auch einfach oder muss ich tatsächlich in obigen Code für jede dieser eine eigene Abfrage einbauen a la if($property == 'name') { // do sth.. } ? Falls nein, dann lasse ich mich gerne belehren, falls ja, dann ist das nunmal Gefrickel, sorry.
 
Zuletzt bearbeitet:
BlooDFreeZe schrieb:
Code:
public string something { get; private set; }
ist dafür einfach unglaublich praktisch und gut lesbar.

Das stimmt. Aber zu praktisch: Der moderne Workflow in Java ist allerdings 1) ich erstelle neue private Variablen und 2) lasse dann von der IDE getter und setter erzeugen. Das dürfte noch schneller gehen, vor allem wenn ich einen Shortcut dafür anlege.

Allerdings müllt es die Klasse relativ schnell zu :D
Aber wofür gibt es Outline?

Ich hab ja schon am Anfang geschrieben, dass C# tendenziell besser ist als Java, und ich Java irgendwie halt subjektiv trotzdem lieber mag. Abgesehen von den vielen Sicherheitsproblemen, seit es von Oracle "weiterentwickelt" wird.
 
Zuletzt bearbeitet: (Anführungszeichen bei "weiterentwickelt" vergessen)
dcobra schrieb:
Was ist jetzt aber, wenn ich feststelle, dass 3 oder 4 Membervariablen von 10 nun doch eigene Logik im Setter benötigen? Geht das auch einfach oder muss ich tatsächlich in obigen Code für jede dieser eine eigene Abfrage einbauen a la if($property == 'name') { // do sth.. } ? Falls nein, dann lasse ich mich gerne belehren, falls ja, dann ist das nunmal Gefrickel, sorry.

Einfachster Ansatz: du baust dir einen String aus dem Variablennamen und get/set, also z.B. $func='get'.$varname; und guckst, ob so eine Funktion existiert. Wenn ja, ruf sie auf, wenn nein, versuch den Wert direkt zurückzugeben. Das ist eine Zeile Code in den magischen Methoden, evtl. etwas mehr wenn du noch ne bestimmte Schreibweise erzwingen willst.
 
F_GXdx schrieb:
(...) 1) ich erstelle neue private Variablen und 2) lasse dann von der IDE getter und setter erzeugen. (...)
Funktioniert in C# mit Properties ganz genauso. Aber man hat eben auch die Option (erstmal) keine private Variable anzulegen. Wird später doch mehr Logik benötigt muss die Klasse nach außen nicht verändert werden aber man kann die Autoproperties beliebig durch komplexere Logik ersetzen.
 
Zuletzt bearbeitet:
Dis Diskussion um Properties ist müßig, das ist einfach nur ein Syntax Konstrukt. Der Compiler macht nachher eine Methode draus (was auch sonst?)....
 
Drexel schrieb:
Dis Diskussion um Properties ist müßig, das ist einfach nur ein Syntax Konstrukt. Der Compiler macht nachher eine Methode draus (was auch sonst?)....

Gut bemerkt, und was ist an der Diskussion nun müßig? Es geht um die Verwendung, nicht was auf Bytecode-Ebene herauskommt. Bei der Argumentation wäre das meiste müßig, Generics, Enumerationen usw.

ich freue mich schon auf den ersten Kommentar, der schreibt, dass Properties intern auch nur Methoden sind
 
Backslash schrieb:
Funktioniert in C# mit Properties ganz genauso. Aber man hat eben auch die Option (erstmal) keine private Variable anzulegen. Wird später doch mehr Logik benötigt muss die Klasse nach außen nicht verändert werden aber man kann die Autoproperties beliebig durch komplexere Logik ersetzen.


Genau das sehe ich als den Vorteil an. Ein Kleiner aber feiner. Es gibt noch paar so kleine Dinge. Mir fällt grad nix ein, aber die meisten werden ja wissen was ich meine.
Deshalb mag ich C# eigentlich besser und deshalb habe ich dem TE geraten, lieber mit etwas schwierigerem, tieferem anzufangen, damit er nicht von anfang an mit den modernen Sprachen verwöhnt wird. Denn wenn man mal die vorteile von solchen Sprachen kennt, will man nicht mehr zurück :D
 
Ja klar, für jemanden, der neu anfängt mit dem Programmieren ist das sicher alles total wichtig. :D

Meine Einschätzung ist eher, dass der TE nach 1-3 Jahren nochmal hierherkommen kann, damit er überhaupt versteht was wir hier schreiben :D

faraday schrieb:
habe allerdings gehört, dass c++ wesentlich performanter ist

Tatsächlich ist Java und C# tendenziell performanter, C++ ist bei richtiger Programmierung effektiver in der Speicherverwaltung. Das ist ein Unterschied.

Sprachen mit Pointern (wie C++) kann man mit Compilern viel schwieriger optimieren. Das ist der einfache Grund. Schreib schlechten Java-Code - egal - der Compiler macht das schon. Schreib allerdings schlechten C-Code und er bleibt schlecht!

Noch besser optimieren kann man allerdings funktionale Sprachen, weshalb auch schon gezeigt wurde, dass exotische Sprachen wie OCAML teilweise sogar C überlegen sind.

Aber das ist alles so komplex im Compilerbau, es lassen sich sowieso nur sehr eingeschränkt allgemeingültige Performanceaussagen treffen :D...

Faustregel ist, wenn es um Echtzeit geht oder um sehr viele Objekt-Instanzen, dann C/C++, sonst eher was höheres wie Java oder C# und das low-level Zeug vermeiden.
 
Zuletzt bearbeitet:
Status
Für weitere Antworten geschlossen.

Ähnliche Themen

Zurück
Oben