Diskussion:Klasse (Objektorientierung)

Diese Diskussionsseite dient dazu, Verbesserungen am Artikel „Klasse (Objektorientierung)“ zu besprechen. Persönliche Betrachtungen zum Thema gehören nicht hierher. Für allgemeine Wissensfragen gibt es die Auskunft.

Füge neue Diskussionsthemen unten an:

Klicke auf Abschnitt hinzufügen, um ein neues Diskussionsthema zu beginnen.

• Diskussionsregeln
• Hilfe zu Diskussionsseiten
• Sei sachlich und freundlich!
• Greife niemanden persönlich an!
• Geh von guten Absichten aus.

Automatische Archivierung

Auf dieser Seite werden Abschnitte ab Überschriftenebene 2 automatisch archiviert, die seit 14 Tagen mit dem Baustein {{Erledigt|1=--~~~~}} versehen sind. Die Archivübersicht befindet sich unter dieser Spezialseite. Das aktuelle Archiv befindet sich unter /Archiv.

Innere Klasse

Beispiel (Java):

 public class Hasenmaennchen extends Hase
 {
   public Felltyp papaFell ;
 }

 public class Hasenweibchen extends Hase
 {
   public java.util.Vector<Hasenkind> kinder = new java.util.Vector<Hasenkind>() ;
   public Felltyp mamaFell ;

   public class Hasenkind extends Hase
   {
     public Felltyp kindFell ;

     public Hasenkind( Hasenmaennchen vater )
     {
       if( alter % 2 == 1 )
         kindFell = vater.papaFell ;
       else
         kindFell = mamaFell ;
       // end if

       alter = 0 ;
       kinder.addElement( this ) ;
     }
   } // end inner class
 }

 public abstract class Hase
 {
   public static enum Felltyp
   {
     uni , gepunktelt , gestreift , punkte_und_streifen
   }
   public int alter ;

   public static void main( String[] args )
   {
     Hasenweibchen mamaHase ;
     Hasenmaennchen papaHase ;
     Hasenweibchen.Hasenkind kindHase ;

     mamaHase = new Hasenweibchen() ;
     mamaHase.alter = 2 ;
     papaHase = new Hasenmaennchen() ;
     papaHase.alter = 3 ;
     kindHase = mamaHase.new Hasenkind( papaHase ) ;
   }
 }

Das Beispiel ist etwas lang, und vmtl. noch mit dem ein- oder anderen Aspekt "überfrachtet". Vielleicht erfindet ja jemand ein besseres Beispiel, an dem man sieht, dass der new nur über ein Objekt der äußeren Klasse funktioniert, und der zugehörige Konstruktor auf Attribute des äußeren Objekts zugreift...

--arilou (Diskussion) 11:11, 26. Feb. 2013 (CET)

Ein kürzeres Beispiel, bei dem das new nur über ein Objekt der äußeren Klasse funktioniert könnte sein:

import java.util.Vector;

class Outer {
    Vector<Inner> range = new Vector<Inner>();

    class Inner {
        Inner() {
            range.add(this);
        }
    }
}

class Main {
    public static void main(String[] args) {
        var out = new Outer();
        var in = out.new Inner();
    }
}

--Diaspomod (Diskussion) 17:32, 2. Aug. 2019 (CEST)

Auch wenn dieses zweite Beispiel keinen "konkreten Fall" mehr aufgreift, ist es dafür schön kurz und knackig. --> Sollte in den Artikel übernommen werden.

Allerdings würde ich den import auf java.util.* erweitern, damit dann 'Vector' durch 'List' und 'ArrayList' ersetzt werden kann, dann versteht eine WP:OmA leichter, dass range eine Liste ist, und .add wird intuitiver.

--arilou (Diskussion) 09:43, 5. Aug. 2019 (CEST)

Speicherbedarf

Natürlich belegt eine Klasse zur Laufzeit einmalig den Speicher für ihre Methoden.

Lediglich die Objektvariablen (Mitgliedsvariablen, Membervariablen) werden erst durch Instanziierung eines Objekts auf der Halde (heap) angelegt. Dies kann 0 oder mehrmalig erfolgen.

H.-J. Scheibl (nicht signierter Beitrag von 2A02:810D:1100:2240:35D6:E6C1:257D:5A01 (Diskussion | Beiträge) 10:43, 10. Nov. 2014 (CET))

Richtig, habe das mal (zumindest als Anmerkung) in den Artikel eingefügt.

--arilou (Diskussion) 13:39, 11. Nov. 2014 (CET)

Klassen als Objekte

In einer streng objektorientierten Sicht ist alles ein Objekt. Auch Klassen sind Objekte. Sie besitzen Attribute (Klassenattribute, -variablen) und Methoden (Klassenmethode bzw. statische Methoden). Diese Sicht fehlt hier total. Der Artikel suggeriert eine Dichotomie zwischen Klassen und Objekten, die es so nicht gibt. (nicht signierter Beitrag von 2001:4C50:22E:A200:694E:78C3:5095:6C75 (Diskussion | Beiträge) 16:02, 18. Feb. 2015 (CET))

Auch in einer streng objektorientierten Sicht ist nicht alles ein Objekt. z.B. existieren zur Compilezeit und bei der Analyse nur in Ausnahmefällen (z.B. Smalltalk) Objekte. Der Artikel beschreibt auch nicht die Klasse in einer "streng objektorientierten Sicht", sondern allgemein. Zur Laufzeit können Klassen in vielen Sprachen nicht als Objekte betrachtet werden. Wenn das der Fall ist, dann repräsentieren diese Objekte tatsächlich Klassen und besitzen daher nicht nur Klassenattribute / -methoden, sondern allgemein Attribute und Methoden mit Eigenschaften wie scope, Annotationen, Parameter, ...

Dass also Klassen wie Objekte behandelt werden können ist eine Eigenschaft von einigen Programmiersprachen und sollte dort angeführt werden. --Sebastian.Dietrich ✉ 20:35, 18. Feb. 2015 (CET)

Ähm, jein. Dass Klassen (in manchen Sprachen) selbst als Objekte angesehen werden (können), darf durchaus auch in hiesigem Artikel erwähnt werden - nur eben mit Hinweis, dass dies nicht in jeder Sprache geht, selbst nicht in allen, die als "voll objektorientiert" angesehen werden.

--arilou (Diskussion) 13:19, 30. Jan. 2019 (CET)

Python

Wenn die Python-Einrückung für den Anfänger syntaktisch nicht verständlich sein soll, dann schlage ich vor, das Beispiel in Ruby umzuschreiben, da es da ein explizites "end" gibt und sich sonst zu Python ähnlich verhält. --Diaspomod (Diskussion) 13:33, 2. Aug. 2019 (CEST)

Das Beispiel in Ruby sieht so aus:

# Die Klasse "Fahrzeug" ist die Basisklasse.
class Fahrzeug
    def bewegen()
        print "Fahrzeug wird bewegt."
    end
end

# Die Klasse "Auto" ist die abgeleitete Klasse.
class Auto < Fahrzeug
    def bewegen()
        print "Auto wird bewegt."
    end
end

def fahren(fahrzeug)
    # zur Verdeutlichung der sog. "Polymorphie"
    fahrzeug.bewegen()
end

# Hauptprogramm
fahrzeug = Fahrzeug.new
auto = Auto.new

fahrzeug.bewegen()
auto.bewegen()

# Polymorphie: Methode 'fahren'
fahren(fahrzeug)
fahren(auto)

--Diaspomod (Diskussion) 16:35, 2. Aug. 2019 (CEST)

Das sehe ich als sinnvollen Kompromiss, und hab's in den Artikel übernommen.

Afaik gibt es außer Python kaum eine andere verbreitete Sprache, die derart ausgiebig die Quelltextformatierung als semantischen Aspekt verwendet. Verbreitet ist allenfalls "Befehl ist zu Ende am Zeilenende". Daher ist es für eine WP:OmA überraschend (d.h. sie versteht's ggf. nicht gleich), wenn Code-Abschnitte nur über die Einrückung als "zu Ende" markiert sind.

Soweit ich das sehe, führen "Block-Ende-Kommentare" in Python nicht zu nicht-validem Code; sie widersprechen auch ganz und gar nicht der Maxime, durch das Einrücken gut lesbaren Code zu erzwingen - im Gegenteil, sie unterstützen sogar noch, dass der Code leicht verständlich wird. Imo sollte jeder Python-Programmierer, der einen Funken Programmierer-Ehre in der Brust trägt, jeden Block mit so einem Kommentar abschließen. Das gehört einfach zu "schönem Code".

--arilou (Diskussion) 09:54, 5. Aug. 2019 (CEST)

PS: Ebenso wie man in C heute keine Variablennamen mit 2 oder 3 Buchstaben mehr wählt. Lange, sprechende Namen sind sogar in C möglich, oh Wunder!

Dem kann ich als Softwareentwickler absolut nicht zustimmen. Man sollte m.E. Kommentare dafür benutzen zu erklären, warum man etwas macht und nicht dafür zu beschreiben, was man offensichtlich sieht. Im Linux-Kernel wird der Code beispielsweise mit 8 Leerzeichen eingerückt, da man die Codestruktur dann gut erkennt und nicht, indem man so etwas wie "END" Kommentare sucht oder ein Klammerstack "{ ... }" auf und ab zählt. (Das Rubybeispiel ist nur mit 4 Leerzeichen eingerückt.) Besonders Anfänger sollte man m.E. eher das Einrücken als Syntaxelement beibringen und nicht das End-Kommentar lesen. Anfänger sind für mich Menschen, die noch nie Programmcode gesehen haben und nicht die, die früher mit Pascal oder Fortran programmiert haben.

--Diaspomod (Diskussion) 11:39, 5. Aug. 2019 (CEST)

Als Softwareentwickler, der andauernd mit allen Sorten von mehr-oder-weniger-Anfängern arbeitet, hab' ich mir's längst abgeschminkt, fixe Standpunkte wie "das sieht man [doch] offensichtlich", "8 Leerzeichen sind das einzig richtige" oder "Kommentare sind nur für xxx gedacht" zu vertreten.

Das Argument "[man] sollte [...; Anfängern] eher das Einrücken als Syntaxelement beibringen" ist Python-only, denn in anderen Sprachen ist Einrücken ja kein Syntaxelement, sondern (nur) guter Stil.

Speziell für "Anfänger [...], die noch nie Programmcode gesehen haben" sollte man imo jede nur erdenkliche Verständnis-Hilfe in den Code einbauen, und nicht aus persönlichen Ansichten auf irgend eine Hilfe verzichten.

--arilou (Diskussion) 13:36, 5. Aug. 2019 (CEST)

Einrücken ist als Strukturierungselement ganz bestimmt nicht Python-only. --Diaspomod (Diskussion) 14:44, 6. Aug. 2019 (CEST)

Es geht mir nicht um persönliche Vorlieben. Ich bin nur der Meinung, dass man entweder die Sprache mit der Syntax nach eigener Vorliebe (Ruby mit "end") vorgibt oder Prosatext schreibt, bevor man z.B. Python nimmt und so kommentiert, bis man die Syntax von Pascal sieht. Es wäre aber verständlicher nur noch einen Erklärungstext zu schreiben, da man ja eigentlich von gar keinem Syntaxverständnis ausgehen kann. Irgendwann muss man dann den Code weglassen und nur noch Prosakommentar schreiben.

Folgender Code ist z.B. Python kommentiert bis zum Exodus. Da muss man sich die Frage stellen, warum man nicht in Fortran programmiert hat oder einfach nur Erklärungstext geschrieben hat.

# Die Klasse "Fahrzeug" ist die Basisklasse.
class Fahrzeug(object):
#begin Fahrzeug
    def bewegen(self):
    #begin bewegen
        """call"""; print( "Fahrzeug wird bewegt." );
    #end bewegen
#end class Fahrzeug

# Die Klasse "Auto" ist die abgeleitete Klasse.
class Auto(Fahrzeug):
#begin class Auto
    def bewegen(self):
    #begin bewegen
        """call"""; print( "Auto wird bewegt." );
    #end bewegen
#end class Auto

def fahren(fahrzeug):
#begin fahren
    #zur Verdeutlichung der sog. "Polymorphie"
    """call"""; fahrzeug.bewegen();
#end fahren

#--Hauptprogramm--
fahrzeug = Fahrzeug();
auto = Auto();

fahrzeug.bewegen()
"""call"""; auto.bewegen();

#Polymorphie: Methode 'fahren'
"""call"""; fahren(fahrzeug);
"""call"""; fahren(auto);
#--end Hauptprogramm--

Also ich bin ja der Meinung, dass jeder ernsthafte Pythonentwickler ein "call" vor jedem Funktionsaufruf schreiben sollte. Jede Stütze zur Syntaxverständnis sollte kommentiert werden. --Diaspomod (Diskussion) 14:58, 5. Aug. 2019 (CEST)

Am besten wir erfinden eine Programmiersprache mit dem Namen "Explicit Prosa". Die wird ja bereits bei Gesetzen aktiv implementiert. Wikipedia-Lang kompiliert leider nicht immer. --Diaspomod (Diskussion) 15:14, 5. Aug. 2019 (CEST)

Ich möchte dazu anmerken, dass Pascal extra/vor allem zu Lehrzwecken von Herrn Professor Wirth entwickelt wurde. --arilou (Diskussion) 15:59, 5. Aug. 2019 (CEST)

Ja dieses kryptische Python kann sowieso kein Anfänger lesen. Nur habe ich als Anfänger auch Probleme die englischen Schlüsselwörter in Pascal zu verstehen. Man kann doch in der deutschen Wikipedia kein Englisch voraussetzen. Herr Professor Wirth hat die deutschen Studierenden nicht berücksichtigt. --Diaspomod (Diskussion) 16:08, 5. Aug. 2019 (CEST)