Ein Projekt, zwei Vorgehensweisen und Eure Meinung...

hustbaer

Varinate 1 ist gar nicht gut. Jeder einfach direkt reinhacken wie es ihm beliebt - das führt bloss dazu dass die "Integration" zum Schluss der totale Horror wird.
Bewertung ist dann auch sehr schwer und sehr subjektiv. Es sei denn man vernachlässigt die "Integration", und bewertet nur wie gut der Teil jedes Schülers alleine, vor der Integration funktioniert hat.

Varinate 2 ist auch nicht ganz optimal. z.B. weil man meist erst dann eine gute Schnittstelle festlegen kann, wenn man das "Plugin" bereits implementiert hat -- oder zumindest angefangen hat es zu implementieren.
Weiters kann es sein dass die fix vorgegebene Schnittstelle für das Plugin von Schüler A toll passt, aber für das Plugin von Schüler B sehr problematisch/schlecht passend ist.

Ideal wäre ein Mittelweg: man arbeitet über definierte Schnittstellen, aber meisselt diese nicht vor Beginn der Plugin-Entwicklung in Stein, sondern entwickelt & adaptiert sie während die Plugins entwickelt werden.

Wenn ich mich nur für Variante 1 oder 2 entscheiden kann, dann ganz klar 2. Schonmal damit die Kids lernen dass man für Programme dieser Art gefälligst Schnittstellen zu verwenden hat. Und eben wegen des totalen Chaos das Variante 1 verursachen würde.

ps: Eine Modifikation von Variante 2 die mMn. bitter nötig ist: jeder bekommt den Source-Code des Projekts, darf bloss keine Änderungen darin machen. Ausgenommen eindeutige Bugs fixen. Dadurch wird keiner unnötig durch unklare Dokumentation oder Bugs ausgebremst.
(Bzw. von Bugs natürlich schon ein wenig, aber viel weniger als wenn er den Source-Code nicht hätte. Mit Source kann er wenigstens gucken warum und wie etwas schief geht, und es dann fixen, damit er an seinem Teil weiter arbeiten kann)
Ebenso könnte/sollte es vielleicht eine Ansprechstelle geben für fehlende bzw. "unpassend" definierte Funktionen in der Schnittstelle. Wobei dann entweder gemeinschaftlich entschieden werden müsste ob die Schnittstelle erweitert/angepasst wird, oder der Prof müsste das entscheiden.
Und dann sind wir fast schon dort was ich als Mittelweg bezeichnet habe.

themerx

Erstmal vielen Dank für die Antworten. Werde jetzt mal ein bisschen was dazu schreiben.

Variante zwei ist natürlich die von dem Studenten und um genau zu sein (wer hätte es gedacht) von mir.
Wie kam es dazu? Jede Gruppe sollte sich Gedanken über die Umsetzung machen und eine eigene Idee entwickeln. Für mich schien die Variante mit den DLL Dateien sinnvoll aus folgenden Gründen:
- jeder Student der ein Modul programmiert hat eine einheitliche Schnittstelle und damit alle Daten die er benötigt. Da jedes Modul als Ziel hat das Bild zu verändern war es auch recht klar, welche Daten die Schnittstelle übergeben muss und welche Methoden der Student braucht.
- Objektorientierte Programmierung statt Spaghetti-Code. Im zweiten Semester wurde uns die OOP in C++ beigebracht, also jeder war in der Lage eine Klasse zu schreiben, die von einer anderen erbt. Somit konnte man in dieses Projekt eine geordnete Struktur einbringen.
- Erweiterung ohne erneute Kompilierung. Dies ist wohl eine der wichtigsten Gründe und das nicht nur im Studium sondern vor allem in der späteren Berufswelt. Um das Programm mit einem Modul zu erweitern musste nicht das ganze Projekt kompiliert werden. Wenn ein Modul fehlerhaft war entfernte man die DLL Datei und/oder fügt sie, wenn sie repariert wurde, zu einem späteren Zeitpunkt wieder hinzu. Und jetzt kommt der eigentliche Vorteil. Angenommen dies ist ein Projekt, welches ihr an einen Kunden verkauft. Der Kunde sagt "ich brauche noch ein Modul, dass die Farbe invertieren kann". Wollt ihr dem Kunden jetzt dazu auffordern das ganze Programm nochmal neu zu installieren, nur weil eine neue 10kb Funktion hinzugekommen ist? Stellt euch das mal mit einem Programm vor wie Cinema4D oder Cubase. AUA!

Es gibt noch ne Menge diverser Vorteile. Ein Nachteil ist, und der wurde hier genannt, dass es ein bisschen Zeit zur Einarbeitung bedarf, jedoch sind wir in einem Studiengang der Informatik und haben schon im 3. Semester ein C++ Fach. Da sollte man sowas langsam können. Zudem habe ich mich komplett um das Hauptprogramm, das SDK sowie ein vier seitiges Tutorial gekümmert, womit jeder problemlos einsteigen konnte.

Also gut, ich habe mich also für diese Variante entschieden und unsere Gruppe fand die Idee gut, also schlug ich sie unserem Prof vor. Was ich jedoch nicht wusste ist, dass der Prof eigenes Denken scheinbar überhaupt nicht leiden konnte. Er hatte seine Vorstellung des Programms (Variante 1) die für mich absolut katastrophal ist und wenn man diese Variante nicht vorschlägt, wird er böse. Ernsthaft er wurde wirklich böse und fing noch während der Vorstellung meiner Idee an mich zu diskriminieren. Also es wurde teilweise unschön aus mir völlig unerklärlichen Gründen. Seine Argumente waren in etwa so "Das versteht doch keiner, DLLs nutzt niemand, warum sollte man die Module vorkompilieren,...". Er brachte schein Argumente um meine Idee eben in den Boden zu stampfen.
Da ich von meiner Idee doch überzeugt war, hat unsere Gruppe es trotzdem umgesetzt und es funktionierte wunderbar.

Tag der Präsentation:
Jede Gruppe stellte nun sein Projekt vor. Zuerst waren wir dran. Die Module wurde bewusst während der Präsentation eingebunden und das Programm lief ohne Probleme. Die andere Gruppe, die nach Variante 1 ihr Projekt umsetzte hatte jedoch Probleme. Ein Modul wurde vor der Präsentation nicht richtig eingebunden und das Programm stürzte während der Präsentation ab. Der Fehler wurde im Quellcode gesucht und auch irgendwann gefunden. Im Anschluss musste das komplette Projekt neu kompiliert werden. Alles passierte während die Gruppe präsentierte.

Ok, warum mache ich das ganze hier:
Ehrlich gesagt stelle ich mir gerade selber kritisch die Frage, warum. Ich denke ich brauche nochmal die Bestätigung, denn ihr müsst wissen, seit dieser Aktion hasst mein Prof mich und das hat er mir letzte Woche wieder zu spüren gegeben. Leider habe ich noch ein Fach, dass ich bei ihm belegen muss und es geht wieder um C++ Programmierung. Eigentlich ist es jetzt egal was ich wann sage, er hat einfach total Bock drauf mich jedes mal zu diskriminieren. Es ist nicht so, dass er Ideen von mir argumentativ widerlegt sondern sich (wie eben erwähnt) Scheinargumente aus den Fingern zieht. Ehrlich gesagt bin ich ein bisschen verzweifelt, weil es auch so langsam an meinen Nerven nagt und mir schon selber die Frage stelle ob das alles richtig war, was ich damals gemacht habe.
Aber so wie es scheint lag ich mit meiner Variante wohl doch nicht ganz falsch.

Ich bin jetzt mal sehr auf eure Meinungen dazu gespannt.

Werner Salomon

Hallo themerx,

.. bin i.A. etwas busy.
Nur soviel - meiner Meinung nach ist Variante 2 ganz klar der Favorit, wenn man nur die Wahl zwischen den beiden hat. Ansonsten bin ich einer Meinung mit der Aussage von hustbaer. Das von ihm beschriebene Vorgehen würde ich als professionell bezeichnet.

Die Implementierung muss nicht zwingend eine mit DLLs sein, aber wenn Dein Prof sagt: "DLLs nutzt niemand", dann stellt er sich klar in's Abseits. Zumindest im Windows-Umfeld kenne ich keine mittlere bis große Applikation, die keine DLLs nutzt.

heute Abend melde ich mich vielleicht noch mal.

Gruß
Werner

Skym0sh0

themerx schrieb:

Ok, warum mache ich das ganze hier:
Ehrlich gesagt stelle ich mir gerade selber kritisch die Frage, warum. Ich denke ich brauche nochmal die Bestätigung, denn ihr müsst wissen, seit dieser Aktion hasst mein Prof mich und das hat er mir letzte Woche wieder zu spüren gegeben. Leider habe ich noch ein Fach, dass ich bei ihm belegen muss und es geht wieder um C++ Programmierung. Eigentlich ist es jetzt egal was ich wann sage, er hat einfach total Bock drauf mich jedes mal zu diskriminieren. Es ist nicht so, dass er Ideen von mir argumentativ widerlegt sondern sich (wie eben erwähnt) Scheinargumente aus den Fingern zieht. Ehrlich gesagt bin ich ein bisschen verzweifelt, weil es auch so langsam an meinen Nerven nagt und mir schon selber die Frage stelle ob das alles richtig war, was ich damals gemacht habe.
Aber so wie es scheint lag ich mit meiner Variante wohl doch nicht ganz falsch.

Ja das Gefühl kann ich nachvollziehen.
Aber denk dran, wenn dich Computerspiele (wie. z.B. Doom oder so) eins gelehrt haben, dann das hier: Wenn du keine Gegner mehr siehst bist du auf dem falschen Weg. Oder umgekeht ausgedrückt, solange du auf Gegner triffst, bist du auf dem richtigen Weg

Als Prof sollte man sich eigentlich nicht so quer stellen und das auf persönliche Ebene runter ziehen. Mit dem Ausdruck "Diskriminierung" wäre ich etwas vorsichtig, da es schon ein recht hartes Wort ist. Aber wenn die Behandlung echt in die Richtung geht, dann würde ich mal mit dem Dekan oder Vertrauensprofessor reden. Da wird man sicherlich was machen können, und sei es nur ein Gespräch. Ausserdem gibt es genau für sowas Zweitprüfer.

Zum Inhaltlichen: Wie du auch selbst sagst (bzw meinst), jeder kann seine Meinung haben (z.B. für oder gegen DLLs) und das ist auch gut so, solange man sie gehaltsvoll begründen und vertreten kann. Und genau das ist auch Wissenschaft (Informatik ist zumindest bei uns ein Bachelor/Master of Science Titel). Egal ob etwas schön ist oder nicht, es hat seine Vor- und Nachteile und hat seine nachprüfbaren Wahrheiten. Da kann sich keiner gegen wehren.

Bei solchen Projektorganisationen kommt es sehr stark aufs Team an, die einen können [besser] mit Variante 1, die anderen [besser] mit Variante 2.
Und wenn wir mal in große Produkte schauen würden, ich glaube aus der Software-Engineering Sicht würden da viele durchfallen ;).

Sqwan

Ich z.B.
Habe das im Studium nie gelernt. Ich weiß bis heute nicht wie man dlls erzeugt, wann das Sinn macht, und wie man diese dann verwendet.
Nach dem Studium habe ich 1 Jahr entwickelt. Mit Java.
Dort habe ich aber fast nichts selbst geschrieben sondern mehr den Problemfall analysiert. Klar, auch programmiert im Sinne von tippen, aber das was höchstens 5% der Arbeit, wenn überhaupt. Dort haben wir auch keine dlls genutzt. Denke mal, das ist in Java auch nicht so gängig, bin mir aber auch nicht sicher.

Wo ich mir jedenfalls sicher bin, ist das Architektur nahezu überall fehlt. Auch die frischen Anfänger in meiner jetzigen Firma haben da 0 schimmer von. Das ist ein riese Versäumnis. Sehr sehr schade.

volkard

Sqwan schrieb:

Das ist ein riese Versäumnis. Sehr sehr schade.

Nö.
Fast alle DLLs sind Unfug, da wäre eine statische lib besser gewesen. Dann hat die exe einfach die passende Version und fertig. Nur für fette Brummer wie das MS-Office macht es Sinn, DLLs zu bauen oder wenn man dem User erlauben will, Plugins von Fremdanbietern dazuzuschalten.

Sqwan

Aber dieses wissen gehört doch dazu.
Wenn ich sage eine DLL machen wir nicht, dann erkläre ich doch warum nicht.
Dann erkläre ich doch den unterschied zwischen Lib und dll.
Dann erkläre ich doch warum ich in diesem Fall lib nehme.
Das gehört doch mit zur "Architektur" und deshalb durch aus ein versäumnis.

otze

Ich bin für 1). Denn: eigentlich sind beide Varianten gleichwertig. Im zweiten Fall einigt man sich in der Gruppe über ein Interface und baut dann die Programme passend. Im ersten Fall kann man das aber genausogut machen. Wenn die Interfaces festgelegt sind, dann unterscheiden sich beide Varianten nur noch dadurch, ob man einen weiteren Komplexitätslayer einbaut. Da bei einem kleinen Studienprojekt diese Komplexität nicht benötigt wird(Compilation dauert wahrscheinlich < 2min, s gibt keine 1000 unabhängig voneinander implemntierten module), schlägt für mich das Pendel zur ersten Variante.

Die ganzen Argumente darüber hinaus - von beiden Seiten - sind scheinargumente, weil es ansonsten keinen Unterschied gibt.

daddy_felix

otze schrieb:

Im ersten Fall kann man das aber genausogut machen. Wenn die Interfaces festgelegt sind, dann unterscheiden sich beide Varianten nur noch dadurch, ob man einen weiteren Komplexitätslayer einbaut.

Es handelt sich um Studenten, die sich ein oder zwei Semester mit C++ beschäftigt haben. Ich bezweifle ganz stark, dass diese die Disziplin haben, die Interfaces zu beachten und das Hauptprogramm nicht zu verändern (kann bei Anfängern ganz schnell mal passieren, muss nichtmal absichtlich sein).

hustbaer

otze schrieb:

Ich bin für 1). Denn: eigentlich sind beide Varianten gleichwertig. Im zweiten Fall einigt man sich in der Gruppe über ein Interface und baut dann die Programme passend. Im ersten Fall kann man das aber genausogut machen.

Ja, kann. Die Beschreibung klingt aber nicht danach als ob das vorgesehen wäre.

Natürlich kann man die DLL-Sache bei Variante 2 weglassen, die ist eben nicht der Knackpunkt bei Variante 2. Der Knackpunkt ist dass bei Variante 2 vorgeschrieben ist dass ein Interface definiert wird, und nur über dieses zugegriffen werden darf (bzw. mit DLLs: kann).

Und genau das ist der Unterschied, und genau deswegen sind die Varianten eben nicht gleichwertig.

Werner Salomon

IMHO ist es hier nicht angebracht ein Diskussion über Sinn und Unsinn von DLLs vom Zaun zu brechen.
Ob das in der Realisierung der Variante 2 eine DLL wird oder eine statische Lib - oder womöglich ein paar Source-Dateien, aber mit wohldefiniertem Interface, halte ich für zweitrangig.
Ich interpretiere den Hilferuf von themerx (ich unterstelle es ist ein Hilferuf) so, dass er sich die Bestätigung hier abholen möchte, dass er mit seinem Vorschlag auf einem besseren Weg ist, als es der Prof vorgeschlagen hat.

Aus meiner Erfahrung heraus kann ich sagen, dass man sich bei jedem Programmentwurf von Anfang an zwingend über die 'grobe' Struktur Gedanken machen muss. Und zwar insbesondere darüber, wie es am Ende(!) aussehen soll. Und die endgültige Fassung besteht doch hier ohne Zweifel aus genau einem Programm, für das jeder der Beteiligten seinen Beitrag abzugeben hat.
Und ohne eine vorhergehende Planung wie diese Teile zusammen spielen sollen, ohne jede Diskussion oder klärende Leitlinien wie das geschehen soll - so interpretiere ich die Variante 1 - ist so etwas bei nicht trivialen Programmen zum Scheitern verurteilt.

Aber das wichtigere Thema hier ist IMHO die von themerx beschriebene Reaktion des Profs. Also ein zwischenmenschliches Problem.
Wir kennen die Meinung des Profs nicht, sondern nur die von themerx. Deshalb möchte ich mich auch mit jeder Beurteilung seiner Person zurückhalten.
@themerx: ich würde Dir empfehlen, Dich an Deine Studentenvertretung zu wenden. Und zwar möglichst frühzeitig, bevor irgendwas eskaliert. Und auch nicht nach dem Motto "der böse Prof", sondern eher "ich habe ein Problem".
Wenn alles 'normal' läuft, wirst Du mit ihm klar kommen müssen. Die Frage, die Du Dir nur selber beantworten kannst, ist: wie mache ich das?

Solltest Du später mal die Gelegenheit haben, eine SW-Architektur zu gestalten, so wirst Du schnell merken, dass es nicht nur darauf ankommt, eine technisch gute Lösung zu haben, sondern sie auch verkaufen zu können. Die größten Widerständen resultieren dabei aus folgenden Denk-Schemata:

"die Idee ist nicht von mir, also kann sie nicht gut sein"
"das verstehe ich nicht, was soll das"
"das haben wir schon immer so gemacht"

Am Anfang meiner Karriere habe ich auch großzügig meine Gedankengänge an meine Kollegen weiter gereicht und mir dabei manch blutige Nase geholt. Im Laufe der Zeit bin ich mehr dazu übergegangen Fragen zu stellen. .. wenn Du wirklich gut bist, bekommst Du es so hin, dass der andere denkt, es wäre seine Idee Aber auch da muss man vorsichtig sein, man kann auch mit Fragen jemanden bloß stellen.
Und wenn man sich dann irgendwann mal einen guten Ruf erarbeitet hat, dann darf man auch mal zu "wir machen das jetzt so - und Basta!" greifen; und das wird dann auch akzeptiert.

Mich würde noch interessieren, welchen Background der Prof hat. Wie alt ist er? Wie viel praktische Erfahrung hat er? An welchen Projekten hat er mit wie vielen Beteiligten führend mit gewirkt?

Schöne Ostertage
Werner

themerx

Schöne Antwort Werner.

Werner Salomon schrieb:

Aber das wichtigere Thema hier ist IMHO die von themerx beschriebene Reaktion des Profs. Also ein zwischenmenschliches Problem.
Wir kennen die Meinung des Profs nicht, sondern nur die von themerx. Deshalb möchte ich mich auch mit jeder Beurteilung seiner Person zurückhalten.

Natürlich kennt ihr die Sicht des Profs nicht, deshalb habe ich auch versucht die Varianten so neutral wie möglich zu beschreiben. Ich wollte ja auch eine ehrliche Meinung und keine erhaschte Bestätigung.

Werner Salomon schrieb:

@themerx: ich würde Dir empfehlen, Dich an Deine Studentenvertretung zu wenden. Und zwar möglichst frühzeitig, bevor irgendwas eskaliert. Und auch nicht nach dem Motto "der böse Prof", sondern eher "ich habe ein Problem".
Wenn alles 'normal' läuft, wirst Du mit ihm klar kommen müssen. Die Frage, die Du Dir nur selber beantworten kannst, ist: wie mache ich das?

Es sollte definitiv was unternommen werden, jedoch habe ich Bedenken und glaube dass es die Sache verschlimmern könnte wenn ich ein Gespräch aufsuche.
Je nachdem wie sich die kommenden Vorelsungen enwickeln werde ich meine Entscheidung treffen.

Werner Salomon schrieb:

Solltest Du später mal die Gelegenheit haben, eine SW-Architektur zu gestalten, so wirst Du schnell merken, dass es nicht nur darauf ankommt, eine technisch gute Lösung zu haben, sondern sie auch verkaufen zu können. Die größten Widerständen resultieren dabei aus folgenden Denk-Schemata:

"die Idee ist nicht von mir, also kann sie nicht gut sein"
"das verstehe ich nicht, was soll das"
"das haben wir schon immer so gemacht"

Das verrückte ist, ich bin neben meinem Studium selbständig als Programmierer und habe als Freelancer mit einigen Firmen an Projekten gearbeitet. Dort wurden Vorschläge erwünscht statt niedergetrampelt. Ein Grund der mich auch wohl so aufwühlt. Warum schmettert ein Prof gut gemeinte Ideen ab bzw. warum buttert er einen dabei noch runter. Es war ja nie böse gemeint,... im Gegenteil, man möchte Einsatz zeigen.
Für mich wirkt das eher als hätte er ein grundlegendes Problem damit, wenn man eigene und eventuell bessere Vorschläge bringt.

Werner Salomon schrieb:

Mich würde noch interessieren, welchen Background der Prof hat. Wie alt ist er? Wie viel praktische Erfahrung hat er? An welchen Projekten hat er mit wie vielen Beteiligten führend mit gewirkt?

Der Prof müsste so mitte 50 sein. Sein Schwerpunkt ist die Bildverarbeitung. Genauer möchte ich nicht auf seinen Beruf eingehen (wo er mal gearbeitet hat usw., da ich ihn hier auch nicht an den Pranger stellen möchte).
Seine Erfahrungen beruhen auf die damalige "struktierte" Programmierung, jedoch nicht mehr auf die heute "objektorientierte" Programmierung. Da liegt auch das eigentliche Problem, denke ich. So etwas wie Vererbungen oder Schnittstellen lehnt er grundsätzlich ab und sagt dann "zu kompliziert, versteht keiner,...".

Werner Salomon schrieb:

Schöne Ostertage
Werner

Danke. Wünsche ich Dir/Euch auch.

PS: auch ein großes Danke an alle die sich an dieser Diskussion beteiligen.

Mechanics

themerx schrieb:

Seine Erfahrungen beruhen auf die damalige "struktierte" Programmierung, jedoch nicht mehr auf die heute "objektorientierte" Programmierung. Da liegt auch das eigentliche Problem, denke ich. So etwas wie Vererbungen oder Schnittstellen lehnt er grundsätzlich ab und sagt dann "zu kompliziert, versteht keiner,...".

Ja, sowas kenne ich auch. Hatte auch Profs, die bei C und Nassi-Schneidermann stehengeblieben sind und alles andere ist dann zu kompliziert und braucht keiner. Am besten erst gar nicht versuchen mit denen zu diskutieren, sondern einfach ignorieren. In deinem Fall leider schon zu spät.
Da gibt es einfach völlig unterschiedliche Menschen, sowohl Profs als auch in Firmen. Wundert mich ein bisschen, dass du die Erfahrung nicht schon früher gemacht hast. Einige Profs sind offen für Vorschläge und neue Ideen, andere wollen einfach ihre Vorlesung, die sie genauso seit 20 Jahren halten, in Ruhe durchziehen. Sowas sollte man vorher in Erfahrung bringen, bevor man mit eigenen Vorschlägen kommt. Hatte auch schon paar Profs, die versucht haben, bestimmte Studenten zu schickanieren. Macht halt einfach Spass und bringt etwas Abwechslung in den langweiligen Professorenalltag, wenn man sich schon weigert, was neues zu lernen
Ist in Firmen genauso. Da wirst du sicher noch genug Leute treffen, die es gar nicht haben können, wenn jemand eine eigene Meinung oder eigene Vorschläge hat.

themerx schrieb:

Seine Argumente waren in etwa so "Das versteht doch keiner, DLLs nutzt niemand, warum sollte man die Module vorkompilieren,...".

War das, was er gesagt hat, nicht vielleicht eher etwas in der Art von "vorkompilierte DLLs kann nicht jeder nutzen"?

themerx schrieb:

Seine Erfahrungen beruhen auf die damalige "struktierte" Programmierung, jedoch nicht mehr auf die heute "objektorientierte" Programmierung. Da liegt auch das eigentliche Problem, denke ich. So etwas wie Vererbungen oder Schnittstellen lehnt er grundsätzlich ab und sagt dann "zu kompliziert, versteht keiner,...".

Auch heute ist Objektorientierung lediglich ein möglicher Ansatz ein Problem zu lösen. Nicht der einzige. Oft eignet er sich gut. Nicht immer ist das jedoch so. Wenn man ein Beispiel braucht wo übertriebene Anwendung von Objektorientierung und Vererbung zu komplizierter Software geführt hat, die kaum jemand noch versteht (und verstehen will!), braucht man nur in die Java-Welt zu blicken.

Klar definierte Schnittstellen sind jedoch praktisch immer sinnvoll, haben aber erstmal nichts mit Objektorientierung zu tun.

themerx schrieb:

Ein Nachteil ist, und der wurde hier genannt, dass es ein bisschen Zeit zur Einarbeitung bedarf, jedoch sind wir in einem Studiengang der Informatik und haben schon im 3. Semester ein C++ Fach. Da sollte man sowas langsam können. Zudem habe ich mich komplett um das Hauptprogramm, das SDK sowie ein vier seitiges Tutorial gekümmert, womit jeder problemlos einsteigen konnte.

Darum wird es in deiner Gruppe auch funktioniert haben. Ich kann mir gut vorstellen, dass eine andere Gruppe, die keine Ahnung hat, wie man ein SDK per DLL verwendet, die Hälfte der Zeit damit verbracht hätte und dann nicht mehr genügend Zeit für das eigentliche Projekt gehabt hätte.

themerx schrieb:

Ebenfalls ist er selbst dafür verantwortlich wie er z.b. an Daten wie das geladene Bild, die Breite und Höhe bekommt.

Wenn das wirklich so vom Prof vorgegeben wurde ist das ziemlich schrecklich. Zumindest dafür sollte es eine einheitliche Schnittstelle geben, ob diese Schnittstelle per DLL oder direkt zugreifbar ist, ist für diese Miniprojekt egal.

Das Problem ist halt, dass an vielen Unis/von vielen Profs immer noch Mathematik mit programmieren gelert wird und nicht Informatik.