na gut…
programme
ein programm ist üblicherweise eine datei, die vom betriebssystem ausgeführt werden kann und die dann irgendwas am computer anstellt.
funktionen/methoden
funktionen und methoden sind im prinzip das selbe. der erste begriff stammt eher aus der prozeduralen ecke, der zweite aus der objektorienierten. es geht aber um das selbe: du hast irgendein modul, dass irgendwas tut. was das ist, hängt von der programmierung ab. üblicherweise will ich vom modul irgendeine arbeit erledigt haben. diesen wunsch nennt man manchmal auch anwendungsfall oder „use case“. eine funktion ist nun eine sammlung aller notwendiger arbeitsschritte, die notwendig ist, um diese arbeit zu erledigen. man kann nun eine wirklich grosse funktion schreiben, die sämtliche arbeitsschritte inkludiert, was aber nicht so gut ist - habe ich einen zweiten anwendungsfall, der eine ähnliche arbeit erledigt haben will, müsste ich viel von der ersten funktion kopieren oder neu schreiben. statt dessen untergliedert man die funktion in mehrere unterfunktionen, die sich alle um kleinere, abgeschlossene einheiten kümmern. eine übergeordnete funktion steuert dann die unterfunktionen an.
Übergabeparameter/Parameterübergabe
tja, du kannst eine funktion auch so schreiben, dass sie alles, was sie zum arbeiten braucht, fix einprogrammiert hat. ist aber blöd. stell dir vor, du willst zwei zahlen addieren. dein anwendungsfall ist also z.b. „addiere 1 und 2“. du kannst nun eine funktion schreiben, die die zahlen 1 und 2 addiert und dir das ergebnis rausschreibt. wenn du nun den anwendungsfall „addiere 3 und 5“ hast, müsstest du eine neue funktion schreiben. statt dessen schreibst du lieber eine funktion, die „addiere x und y“ erledigt und zur laufzeit für die variablen x und y werte von dir erwartet. damit hast du nur eine funktion für beide anwendungsfälle. das übernehmen von werten und befüllen der internen variablen mit diesen werten ist eben die übergabe von parametern.
Ereignisse
ereignisse sind was ähnliches wie funktionen/methoden. sie stammen auch aus der objektorientierten ecke. der hintergedanke dabei: es kommt oft vor, dass ein modul auf eine bestimmte zustandänderung von aussen reagieren muss. z.b. wird eine schaltfläche in einem programm darauf warten, dass der benutzer mit der maus darauf klickt. oder das darunterliegende fenster wartet darauf, dass jemand den button klickt usw. der prozedurale ansatz wäre nun, dass du eine hauptschleife hast, die ständig alle notwendigen zustände überprüft (z.b. position des mauszeigers, maustasten gedrückt oder nicht, etc.) und daraus dann irgendwelche folgeaktionen ableitet. also so wie ein manager einer firma, der ständig durch die zimmer läuft und schaut, ob eh alles ok ist. der objektorientierte ansatz ist, dass das fenster die kontrolle ständig an andere module delegiert und nur benachtrichtigt wird, wenn ein klar definierter zustandsübergang eintritt. z.b. prüft die schaltfläche selbständig, ob der mauszeiger sich über ihr befindet und die maustaste gedrückt wurde. ist das der fall, weiss die schaltfläche, dass sie von einem anderen modul eine klar definierte methode aufrufen soll, über die das drücken der schaltfläche gemeldet wird. also wie ein manager, der brav in seinem büro sitzt und angerufen wird, wenn irgendwas nicht stimmt.
die tatsache, dass der vordefinierte zustandsübergang eintritt, nennt man ereignis. die methode, die aufgerufen werden soll, wenn das ereignis auftritt, nennt man ereignismethode. meist sagt man aber einfach nur „event“, sowohl zum ereignis selbst als auch zur methode, die das ereigniss behandelt.
der sinn dahinter ist, dass die software klarer strukturiert werden soll. eine funktion soll nicht ständig sämtliche zustände überwachen, weil das den code extrem unübersichtlich und schwer handhabbar macht. statt dessen wird der code aufgeteilt auf kleine blöcke, die sich nur um spezielle zustände kümmern. laut theorie wird damit der code lesbarer und wartbarer. in der praxis schaffen es die programmiere aber immer wieder, auch mit ereignisprozeduren gröbsten spaghetti-code zu erzeugen.