Programmieren lernen

[tommy]

Der Grundgedanke ist ja immer gleich, sonst hies es ja OOP-Objective-C? Es kann natürlich sein das ich mich da irre, da ich noch nicht lang damit programmiere (1 Jahr, ohne ein Buch gekauft zu haben - wenn man das bei Amazon so liest scheinen sie ja nicht der Hit zu sein).

@Amin Negm-Awad
Gute Beispiele sind auf WinAPI gestützte Programme oder GTK+. Wie willst Du jetzt also die Wiederverwendbarkeit >>garantieren<< wenn man es schon einen Namenskonflikt geben wird bei einer Funktion die ein Fenster bereitstellt? Overloading fällt ja in diesem Falle gleich mal aus. Nun müsste man die Funktion irgendwo austauschen, d.h. aber auch man hat wieder einen Zeiger auf eine Funktion gesetzt, sonst ist erst erstmal gar nichts mit flexiblen austauschen.

Sicherlich alles möglich, der Aufwand ist aber bei weitem höher. Schon mal eine unbekannte Struktur gehabt, bei der Du über einen void Zeiger etwas aufrufen wolltest?

struct abc {int i;}; void *p; p = (abc *)malloc(..);

// irgendwo anders im Code
void o(void *p) {
p->i; // stop
}

Sage jetzt nicht alles einzeln deklarieren!

 

[Amin Negm-Awad]

Der Grundgedanke ist ja immer gleich, sonst hies es ja OOP-Objective-C?

Diese Schlussfolgerung wäre richtig, wenn ich behauptet hätte, dass Objective-C ein einzigartiges Konzept durchsetzt. Dies hatte ich nicht gemacht.

Vielmehr hatte ich behaupte, dass es unterschiedliche Konzepte von dem gibt, was man heute OOP nennt. Daher sind die Konzepte nicht alle gleich. Objective-C und Smalltalk ähneln sich. Hier würde ich von weitestgehend einem Konzept sprechen.

Objective-C und C++ ähneln sich nicht in ihrem Konzept. Das sind völlig verschiedene Ansätze.

Es kann natürlich sein das ich mich da irre, da ich noch nicht lang damit programmiere (1 Jahr, ohne ein Buch gekauft zu haben - wenn man das bei Amazon so liest scheinen sie ja nicht der Hit zu sein).

Womit wir den ersten Fehler gefunden hätten.

@Amin Negm-Awad
Gute Beispiele sind auf WinAPI gestützte Programme oder GTK+. Wie willst Du jetzt also die Wiederverwendbarkeit >>garantieren<< wenn man es schon einen Namenskonflikt geben wird bei einer Funktion die ein Fenster bereitstellt?

Ich sagte ja, dass man die Funktionen entsprechend benamsen müssen. Übrigens machen die ersten Compiler nichts anderes.

Das funktionierte ganz gut.

Overloading fällt ja in diesem Falle gleich mal aus. Nun müsste man die Funktion irgendwo austauschen, d.h. aber auch man hat wieder einen Zeiger auf eine Funktion gesetzt, sonst ist erst erstmal gar nichts mit flexiblen austauschen.

Sicherlich alles möglich, der Aufwand ist aber bei weitem höher. Schon mal eine unbekannte Struktur gehabt, bei der Du über einen void Zeiger etwas aufrufen wolltest?
Sage jetzt nicht alles einzeln deklarieren!

Äh nein. Schaue dir einfach mal an, wie man das mit einem Objective-C oder C++-Precompiler löst. Für C++ dürfte es das sogar noch geben.

 

[tommy]

ich rede aber jetzt von C, keine Klassen wie Du es wolltest! Zur Laufzeit kann man damit nicht wissen ob in der Bibliothek eine Struktur namens abc mit einen Member "i" gibt. Wie willst Du das jetzt also austauschen?

Sind wir wieder am Anfang angelangt, alles einzeln deklarieren? Das nenn ich jetzt aber nicht sehr flexibel! Vielleicht ein kleines Beispiel wäre da nicht schlecht, wenn es wirklich gehen sollte in den Himmel zu schauen.

mindestens 2 Strukturen die in einer Funktion vom Datentyp her unbekannt sind, aber beide "int i" beinhalten.

 

[Amin Negm-Awad]

ich rede aber jetzt von C, keine Klassen wie Du es wolltest! Zur Laufzeit kann man damit nicht wissen ob in der Bibliothek eine Struktur namens abc mit einen Member "i" gibt. Wie willst Du das jetzt also austauschen?

Sind wir wieder am Anfang angelangt, alles einzeln deklarieren? Das nenn ich jetzt aber nicht sehr flexibel! Vielleicht ein kleines Beispiel wäre da nicht schlecht, wenn es wirklich gehen sollte in den Himmel zu schauen.

Ich sprach auch von C. Und wie gesagt: Die ersten Compiler machten aus C++ bzw. Objective-C einfach C.

Ich deklariere die Struktur ebenso, wie ich eine Klasse deklariere. Strukturen und Klassen sind ohnehin in C++ (für tjp: in vielen Dingen) austauschbar.

mindestens 2 Strukturen die in einer Funktion vom Datentyp her unbekannt sind, aber beide "int i" beinhalten.

Ich verstehe dich nicht. Statt einer Klasse foo einfach eine Struktur foo

// foo
typedef struct _foo {
    int i;
} foo;

foo_doSomething( foo* this, … ) {
    …
    this->i = 5;
}

// bar
typedef struct _bar {
    int i;
} bar;

bar_doSomething( bar* this, … ) {
    …
    this->i = 5;
}

Wo hast du ein Problem? Oder ist das kein C?

Den Griff zum Buch würde ich empfehlen. *SCNR*

+++

Übrigens habe ich früher derlei Dinge über einige 100.000 Zeilen Quellcode gemacht. Ds funktionierte eigentlich ziemlich gut.

 

[tommy]

Ich glaube wir reden seit 2-3 Seiten aneinander vorbei!
Ich gebe Dir das ganze mal in Java wie ich das meinte.

example 1:
public interface Adapter {
public boolean parse();
public ConfigContainer getContainer();
}

class c {
public c(Adapter i) {
i.parse();
}
}

// irgendwo in static void main():
c config = new c(new XmlConfig);
c config = new c(new IniConfig);

example 2:

// .. in einer anderen Zeit *scnr*
struct config {
struct xml *pxml;
struct ini *pini;
struct 50-andere *p;
}
// Was ist nun effektiver ?

example 3:

struct xml {int (*parse)(char *file); char *set;}; struct ini{...}; struct mysql{...};

int main() {
void *p;
dlsym usw...; //xml->parse Speicheradresse zuweisen, sowie ini und mysql
}

void controller([B]void[/B] *p) { // [B]ohne[/B] explizite Angabe vom Datentyp
p->parse; // kein Zugriff!
}

Du hast eine bekannte Struktur in Deiner Funktion implemtiert. Das ist nicht das was ich meinte. Spreche sie über einen void Zeiger an, und es wird verwehrt sein.

In Example 2 schreibst Du dann 50 if-else Zweige und prüfst auf NULL? So könnte man echt 100000 Zeilen leicht füllen. So habe ich jetzt Dein Beitrag von oben interpretiert.

Der Sinn ist besteht jetzt dadrin das man nicht alles 1000.000 im Code schreiben muss, sondern alles über einen Controller steuern kann. Du hast ja auch nicht für jeden TV Sender 1 Bedienung in der Hand, oder? Mit dieser Methode verfahre ich zwar nicht in 100000 Zeilen Code allerdings finde ich es effektiver, und habe mich deswegen damals ins Java Lager begeben.

Anderes Beispiel: EJB: Natürlich würde Java auch ohne die Schnittstelle die Daten nicht kennen.

Natürlich führen viele Wege nach Rom, aber der C Weg mit einer 50 km Verlängerung. Möglich ja, aber zu welchem Preis?

Achja, in welchem C Buch soll das stehen (void Zeiger -> 2 verschiedene Strukturen)? Vielleicht verstehen wir uns jetzt etwas?

Gruß, Tommy

 

[Amin Negm-Awad]

Ich weiß ja auch bei einer Klasse ihren Namen. Sonst geht das auch bei C++ nicht.

Und wenn du ein dynamisches Dispatching willst, wie es etwa Objective-C unterstützt, so ist das auch kein Problem. Den Sourcecode brauche ich auch nicht abzutippen. Der steht in dem RTE. Ist Open-Source.

Das gesamte Dispatching ist C-Code! Das RTE macht das so, bis heute. Und ich kann nicht erkennen, warum der C-Code des RTE irgendwie langsamer oder schneller sein sollte als der C-Code eines gedachten RTE.

Du kannst übrigens die gesamte Funktionalität von Objective-C alleine aus C-Code heraus nutzen. Alles: Instanzvariablen, Methodenaufrufe usw. usf. Wie gesagt: Das ist C. Den Code hast du einmalig für alle Instanzen aller Klassen. Da muss man gar nichts erweitern.

Und nein, dazu braucht man auch kein Durchhecheln. Dazu bedarf es eines vtable-Zeigers oder einer isa-Struktur. Ersteres (C++) findest du definitiv in jedem Buch zu C++. Und die isa-Kontrolle steht auf meiner Webseite:
http://www.cocoading.de/Common/Article.php?Area=2&Article=4

 

[tommy]

Interessant! ich habe mal bei Google nach RTE (objective-c usw...) gesucht, allerdings das interessanteste war Wikipedia. Aber das kannte ich schon.

Wie soll man darauf Zugriff haben, und ist das Systemgebunden?

ediT. aha, also und wie geht das mit C? Du schriebst oben etwas von C++

 

[Amin Negm-Awad]

Interessant! ich habe mal bei Google nach RTE (objective-c usw...) gesucht, allerdings das interessanteste war Wikipedia. Aber das kannte ich schon.

Ja, auch so ein Thema, wozu es entweder nichts gibt, oder nicht Verständliches (aka Apple-Doku) oder sachlich Falsches (zahlreiche Bücher). Der Artikel ist aus einer Seminararbeit von Jérome entstanden und der hatte die Literaturlage gut sondert: Viel Crap. (Nein, nicht Tippfehler wie _namee, sondern inhaltlicher Crap. Aber die Ansprüche verschiedener Rezensenten sind unterschiedlich. )) Auf osxentwicklerforum.de dürftest du dazu noch den Thread finden.

Wie soll man darauf Zugriff haben, und ist das Systemgebunden?

Du kannst dir freilich frech die verschiedenen Strukturen holen. Das ist natürlich gefährlich. Das RTE hat aber Methoden zur Kapselung, mit denen du zugreifen kannst.

Es gibt auch immer wieder Fälle, in denen man über so etwas nachdenken kann. Das sind aber Leute, die mehr als 900 Seiten zu Objective-C gelesen haben.

Apple unterstützt das auch offiziell. In Objective-C 2 gibt es extra ein Schlüsselwort @dynamic, um dynamische Änderungen an deiner Klasse zur Laufzeit dem Compiler schmackhaft zu machen. (Dem würden sonst Methodenimplementierungen fehlen->Warning)

API: (Besserer Link)
http://developer.apple.com/documentation/Cocoa/Reference/ObjCRuntimeRef/Reference/reference.html

+++

Zur Plattabhängigkeit:
Es gibt ein RTE für Intels
Es gibt ein RTE für ppc.
Es gibt ein RTE für GnuStep/was auch immer.

Erweiterungen ergeben sich vor allem aus Objective-C 2 und dort noch einmal aus der 64-Bit-RTE.

 

[tommy]

Also damit gestaltet sich Objective-2 für mich schon interessanter. Syntax kann ich trotzdem auf den Tod nicht leiden.. Vor ein paar Tagen habe ich auf Xcode 3 umgestellt. Vielleicht zwinge ich mich da mal wieder rein.

Hab dank für die seltene Information.
Ich versteh aber nicht warum Apple Java aus der Liste "gekickt" hat, und so etwas wie Ruby rein nimmt.

 

[Amin Negm-Awad]

Also damit gestaltet sich Objective-2 für mich schon interessanter. Syntax kann ich trotzdem auf den Tod nicht leiden.. Vor ein paar Tagen habe ich auf Xcode 3 umgestellt. Vielleicht zwinge ich mich da mal wieder rein.

Hab dank für die seltene Information.
Ich versteh aber nicht warum Apple Java aus der Liste "gekickt" hat, und so etwas wie Ruby rein nimmt.

In dieser Beziehung enthält Objective-C 2 wenig Neues. Ds ging so oder ähnlich ganz überwiegend schon mit Objective-C 1. Wirkliche Funktionserweiterung ergibt sich eigentlich mehr mit der 64-Bit-Variante. (Weil dort der Zugriff doppelt indirekt erfolgt.)

Der Grund ist, dass Java gewisse Dynamik nicht anbietet, die für Cocoa lebensnotwendig ist.

Schreib mal Bindings oder nur KVO/KVC für Java. Du wirst damit reich!
+++
Ah, mit KVC hat sich Apple sogar noch die Mühe gemacht.

 

[tommy]

Kraftstoffverordnung? :-D
Naja, vielleicht auch nur einen Teilzugriff, dass man wenigstens die "Geschäftslogik" mit Java machen kann. Die Entwicklung würde meines erachtens schneller von statten gehen.

Reich? Hast Du auch dazu einen Link? :-D

 

[Zettt]

Ich bin ein Zitat von Amin, das nur dazu da ist um zu sagen, dass Zettt gerade auf sein Posting antworten moechte.

Heisst also, dass der Gag an OOP letztendlich der ist, Teile eines Programmes unabhaengig voneinander ablaufen zu lassen.
Somit muss ich als Programmierer das Programm so auslegen, dass die Interaktion ueberhaupt erst moeglich wird?

Das ist dann aber auch der Grund, warum manche Programme Performance Probleme haben?
Weil das Programm in der jeweiligen Methode "festhaengt" und auf eine Eingabe vom Benutzer wartet.

 

[tommy]

Meinst Du damit Threads? Mehrere Dinge auf einmal zu erledigen? Die haben aber dann nichts mit OOP zutun (bei Objective-C kann das natürlich anders sein )

 

[Amin Negm-Awad]

Heisst also, dass der Gag an OOP letztendlich der ist, Teile eines Programmes unabhaengig voneinander ablaufen zu lassen.

Wenn du mit unabhängig gekapselt meinst: Ja. Wenn du Nebenläufigkeit meinst: nein.

Aber Objekte sind ja über Beziehungen miteinander verbunden. Also ein Objekt schickt zur Erledigung der Arbeit wieder Nachrichten an andere Objekte usw.

Somit muss ich als Programmierer das Programm so auslegen, dass die Interaktion ueberhaupt erst moeglich wird?

Du musst einer Interaktion zunächst eine Methode in einem Objekt zuordnen. Da diese Methode in den meisten Fällen von dir stammt und keine Standardfunktionalität ist (was aber auch sein kann: Save bei Core Data etwa), musst du eine entsprechende Klasse programmieren, die als Beschreibung dient. Vielleicht sollte ich morgen noch einmal die Graphiken hochladen.

Das ist dann aber auch der Grund, warum manche Programme Performance Probleme haben?
Weil das Programm in der jeweiligen Methode "festhaengt" und auf eine Eingabe vom Benutzer wartet.

Wenn du meinst, dass die Applikation nicht mehr reagiert und dieser komische Beachball erscheint: Ja. Aber sie erwartet keine Eingabe vom Benutzer. Sie macht ihre Arbeit und kehrt zum System zurück. Bei der nächsten Eingabe, bekommt sie wieder eine Nachricht. Manchmal dauert aber diese Arbeit sehr, sehr lang. Dann hängt das Programm.

So lange die "verbundene" Methode läuft, ist die Event-Loop gesperrt. Diese nimmt die Ereignisse vom System entgegen und baut daraus die Nachrichten. Da OS X hin und wieder selbst "Herzschlag"-Nachrichten verschickt, bemerkt es irgendwann, dass da nichts mehr entgegengenommen wird. Der Beachball erscheint.

Mal so in etwa der Ablauf:

1. Programmstart
2. Programminitialisierung
3. Programm verabschiedet sich in die Event-Loop und gibt die Kontrolle an das System ab.
-- Jetzt schläft das Programm und tut gar nichts. IIRC nimmt es OS X sogar aus dem Schedule.
4. User drückt eine Taste.
5. OS X weckt das Programm.
6. OS X sickt das Ereignis an das Programm.
7. Im Programm (Cocoa) wird aus dem Ereignis eine Nachricht gezaubert.
8. Die Nachricht wird an das zuständige Objekt geschickt.
-- Jetzt geht die Arbeit des Programmierers los:
9. Eine Methode für diese Nachricht wird ausgeführt. Sie muss den Tastendruck verarbeiten, also etwa das Zeichen in ein Textfeld einbauen.
10. Die Methode ist fertig
11. Das Programm gibt wieder die Kontrolle an das System ab (3)
-- schnarch
12. Der User klickt auf einen Button
-- weiter wie bei (5)
-- schnarch

 

[Amin Negm-Awad]

Meinst Du damit Threads? Mehrere Dinge auf einmal zu erledigen? Die haben aber dann nichts mit OOP zutun (bei Objective-C kann das natürlich anders sein )

OOP und Threads sind orhtogonal zueinander. Aber natürlich kennt Cocoa Klassen zur Verwaltung und Steuerung von Threads. Etwa NSThread, NSLock, NSOperation und auch Objective-C das Shclüsselwort @synchhronize.

Aber das dürfte in Java nicht viel anders sein.

 

[tommy]

OOP und Threads sind orhtogonal zueinander. Aber natürlich kennt Cocoa Klassen zur Verwaltung und Steuerung von Threads. Etwa NSThread, NSLock, NSOperation und auch Objective-C das Shclüsselwort @synchhronize.

Aber das dürfte in Java nicht viel anders sein.

Ich habe das eher auf Software Design bezogen, die Realisierung ist ja am Ende ganz klar das sie mit den gegebenen Umgebungsumständen erbracht wird.

Man könnte ja sonst auf die ganz blöde Idee kommen über JNI die pthread Bibliothek zu nutzen. Das einzigste wäre dann noch "System.loadLibrary" was zu deiner Aussage passen könnte. Dies wäre denk ich auch bei Obj-C möglich..

 

[Zettt]

Ok Danke.
Hab's verstanden.

Mir glueht reichlich die Birne, wenn ich das so lese.
Threads, Nibs, KVO, KVC und MVC alles Dinge die ich vorher nicht kanne oder nur mal als Erwaehnung irgendwo gelesen habe.

Ich hoffe mal, alles in allem, dass ich diese "Hochsprache" noch irgendwie erlerne und ENDLICH meine eigenen Programme programmieren kann.
Es bleibt...schwer!

 

[Amin Negm-Awad]

Es ist wie überall: Übung macht den Meister. Und immer wieder darüber nachdenken, warum man etwas macht.

 

[tjp]

Mir glueht reichlich die Birne, wenn ich das so lese.

Daher ist es auch kein guter Gedanke als totaler Anfänger zu meinen man müsse unbedingt die perfekte Cocoa-Applikation gleich erstellen. Das klappt eh nicht. Besser ist es erstmal in einfachen Mini-Programmen die Grundlegenden Techniken zu erlernen. Was uns zu Deiner Frage zum Thema OOP zurückführt.
Zwei Bücher als Empfehlung, letzteres gibt es mittlerweile nur noch im englischen Original in der 3. Auflage (2008). Beide ücherbeschäftigen sich mit den Thema wie man aus Problembeschreibungen wie OOA, OOD zur OOP kommt. (OO Analyse, OO Design, OO Programmierung)

[Bal99] Balzert, Heide: Lehrbuch der Objektmodel lierung. Spektrum Akademischer Verlag, Heidelberg, Berlin, 1999, ISBN 3-8274-0295-9.
[Boo94] Booch, Grady: Objektorientierte Analyse und Design. Addison-Wesley, München, 1994, ISBN 3-89319-673-0.

Dazu kommt, daß man möglichst eine einfache Programmiersprache benutzt, die Fehler möglichst gutmütig behandelt. Alles C basierte ist das nicht so toll, früher war es aber sehr viel schlimmer. Bei einem Programmcrash eines C-Programms mußte man meist den Computer neustarten. Da kam Freude auf.

 

[Zettt]

Klar ist das nicht so einfach. Natuerlich versuche ich mich erstmal an Mini-Programmen, an den grossen scheitere ich eh ganz schnell.

Aber Amin hat da schon Recht. Uebung macht den Meister.
Das ist nicht nur beim programmieren so...