1. Diese Seite verwendet Cookies. Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies. Weitere Informationen

Objective-C und Objektedingenskirchen

Dieses Thema im Forum "OS X-Developer" wurde erstellt von Zettt, 25.08.07.

  1. Zettt

    Zettt Doppelter Melonenapfel

    Dabei seit:
    16.10.05
    Beiträge:
    3.374
    Hallo


    Ich habe eine grundlegende Frage, die man mir sicher schnell beantworten kann. Klar ich haette Grossmeister Maurer und Negm-Awad auch einfach eine PM schreiben koennen oder im KFKA Thread posten (welchen ich nicht mag...), aber stattdessen finde ich es doch viel lustiger hier einen neuen Thread zu eroeffnen, bei welchem jeder feucht und froehlich seinen Senf abgibt.

    OK hier ist sie.
    Ich versuche mich derzeit ein bisschen mit Objective-C und Cocoa fit zu machen. Zu diesem Zwecke lese ich auch ein Buechlein...

    In Objective-C programmiert man sich Objekte, die alle unabhaengig voneinander laufen und nur ueber Nachrichten miteinander kommunizieren.
    Seh ich das richtig, das die Dinge, also die Drueckerlis und Drehknopfis aus dem Interface Builder auch nur Objekte sind (im Sinne von Subklassen von NSObject?), welche dann ihrerseits Nachrichten erzeugen bzw. auffangen um mit dem eigentlichen Programm zu agieren? (Hier sind 2 Fragen versteckt. Suche sie. ;))
    Also ihr wisst schon...[​IMG]

    Ja ich weiss ich beantworte mir die Fragen gerade selber. Aber sei's drum...wir wollen ja alle was zu quatschen oder?
     
  2. LaK

    LaK Reinette Coulon

    Dabei seit:
    30.03.05
    Beiträge:
    953
    Ja so ist es.
    Und ich bin weder feucht noch fröhlich und Senf hab ich auch keinen dabei.
     
  3. MacApple

    MacApple Lord Grosvenor

    Dabei seit:
    05.01.04
    Beiträge:
    3.470
    Ja, das siehst Du richtig.

    Was denkst Du ist das "eigentliche Programm"? Das eigentliche Programm besteht aus den ganzen Objekten. Durch das Zusammenspiel der ganzen Objekte entsteht die Funktion eines Programms und damit "das eigentliche Programm".

    MacApple
     
  4. tjp

    tjp Baldwins roter Pepping

    Dabei seit:
    07.07.04
    Beiträge:
    3.250
    Nein, Du entwirfst Klassen, Klassen sind Meta-Objekte, denen man zwar ebenfalls Nachrichten senden kann (z.B. das [... alloc] ist eine Klassenmethode), aber i.d.R. verschickt man Nachrichten an Instanzen von Klassen (Objekte). Unabhängig sind die Objekte nicht, denn weder laufen alle Objekte unabhängig voneinander (was auch immer das heißen mag), es gibt nur einen oder mehrere definierte Threads. Die Objekte stehen in einer festen Beziehung zu einander, da zwischen all den Objekte Verknüpfungen bestehen, diese Verknüpfungen legst Du im Entwurf fest. Die Gesamtheit dieser Beziehungen in einem Programm nennt man Objektgraph, der sich natürlich während der Laufzeit des Programm ständig ändern kann.
    Nein, die verschiedene GUI-Elemente die Dir der Interface Builder zur Verfügung stellt sind Klassen (Meta-Objekte oder Klassenobjekte zur Laufzeit des Programms) und keine Objekte in Sinne von Instanzen einer Klasse. Erst wenn Du die Elemente in das GUI verbaust, wird für jedes dieser Elemente zur Laufzeit ein Objekt (Instanz einer Klasse) erzeugt.

    Es gilt zwischen Klassenobjekte und Instanzen zu unterscheiden: Es gibt nur jeweils ein Klassenobjekt pro Klasse, aber beliebig (nicht ganz irgend wann ist der Arbeitsspeicher voll) viele Instanzen einer Klasse.
     
  5. Zettt

    Zettt Doppelter Melonenapfel

    Dabei seit:
    16.10.05
    Beiträge:
    3.374
    Ja, tjp, das hab ich schon gemeint. ;)
    Schöne detaillierte Antwort. Wieder was gelernt. :)


    Aber aus der Diskussion raus hab ich noch eine Frage seit 5 Minuten.

    Heisst das eigentlich für mich, dass man eigentlich ganz leicht ein Programm schreiben kann, zu dem man dann erst später ein GUI bastelt? Oder welchen Schwierigkeiten steht man da gegenüber?
    Weil so wie ich das gerade sehe, für das Problem das ich erstmal angehen möchte, hatte ich schonmal ein Kommandozeilen Programm geschrieben (C++). Das wäre ja theoretisch nichtmal schlecht, kann ich doch einen grossen Teil des Programms übernehmen.
     
  6. tjp

    tjp Baldwins roter Pepping

    Dabei seit:
    07.07.04
    Beiträge:
    3.250
    Irgend wie geht immer, nur das ganz leicht ist so ein Problem. Wenn es sich um einen Daemon, Agenten, Application Server o.ä. handelt, dann kannst Du dazu nur mit viel Aufwand geschehen. Denn solche Software Komponenten sollen eben nicht direkt kontrolliert werden, und eine GUI-Applikation erfordert direkte Kontrolle.

    Wenn es sich um einen nicht interaktives Konsolenprogramm handelt, dann ist es nicht sinnvoll dazu ein GUI zu entwerfen. Denn außer Ein- und Ausgabedateien festlegen kann man da nicht viel machen.

    Wenn man ein Programm hat, welches die Konsole fürs UI benutzt, dann kommt es nur auf das Design der Applikatin an. Wenn man das richtig gemacht hat, dann hat man in einer OO-Konsolenapplikation ebenfalls MVC & Co. genutzt. Ob das Konsolen-UI nun ein GUI hat oder nicht ist von der Abstraktion im Design sekundär, es ist insofern von Bedeutung, da Cocoa und Frameworks keine Komponenten enthalten ein GUI auf die Konsole umzubiegen.
    Wenn Du das Programm sauber entworfen hast, sollten sich die Kernkomponenten wiederverwenden lassen.

    Die Kombination von Objective-C und C++ erfordert einige Zugeständnisse, lies Dir die Doku bei Apple durch. Unter anderem findet kein Stack-Unwinding statt (moderner C++ Code basiert immer darauf), wenn eine Objective-C Exception geworfen wird, so daß RAII leider nicht funktioniert. Das heißt, daß man von C++ keinen Objective-C Code aufrufen darf, der Exceptions werfen könnte bzw. dann spezielle Maßnahmen ergreifen muß.
     
  7. Bölzebub

    Bölzebub Querina

    Dabei seit:
    27.05.05
    Beiträge:
    180
    Evtl. macht es auch Sinn, einfach nur ein Frontend für dein bestehendes Kommandozeilenprogramm
    zu schreiben. Je nach Einstellungen in der Oberfläche rufst du dann dein bestehendes Programm mit den entsprechenden Optionen mit Hilfe von NSTask auf und liest die Ausgabe dann über eine NSPipe ein. Ein einfaches Beispiel findest du hier. Das Ganze hat dann den Vorteil, dass die Funktionalität weiterhin ein einem plattformunabhängigen C++-Programm steckt, du trotzdem ein »richtiges« Mac-Programm hast und nicht irgendwie C++ und Objective-C mischen musst.
     

Diese Seite empfehlen