Author Topic: Programmierung Java Informatik 2007....prodiktiv (Read 5577 times)

Abus · « **on:** April 19, 2007, 02:10:49 pm »

Da die meisten von uns das gleiche über den Beleg denken, was ich jetzt hier nicht weiter publizieren möchte, würde ich im folgenden Thread um Mithilfe der "Javakönner" bitten, um einige methods widerzugeben.....

...weiterhin hab ich noch einen Kasten Bier deiner Wahl, der gern den Besitzer wechseln möchte, gegen den fertigen Beleg;-).....

meine Frage:

hat jemand ein programm in Java geschrieben, was man sich mal ansehen kann?
ich kann mir darunter nur mäßig was vorstellen!..

Wie ist die Hierarchie der Klassen und Packages überhaupt?

gebt ma überblick ...

Danke der Abus

badewannenchemiker86 · « **Reply #1 on:** April 19, 2007, 03:41:29 pm »

Spitzenidee Abus, aber was denkst du wie viele Leute Java können und du musst die Prüfung ja noch selber schreiben.

Hab ein Tutorial gefunden, was alles gar nich so schlecht erklärt hoff ich. Hier der Link:

http://www.gailer-net.de/tutorials/java/java-toc.html#01

Für den einen oder anderen, der Java nich kann ja vielleicht ne gute Sache.

DIGIT · « **Reply #2 on:** April 19, 2007, 04:42:25 pm »

Über 80 % der produzierten Nudelwaren, insbesondere Spaghetti, werden von StudentInnen konsumiert.

Ergo ist es anfangs sehr, sehr schwierig, keinen Spaghetti-Code zu schreiben, sondern das Programm zu strukturieren.

Gedankenexperiment:
Vielleicht sollte man versuchsweise eine "Klasse" mit "Baugruppe" gleichsetzen.
Wie es drinnen aussieht ist mir wurscht, aber es gibt Stecker, Kabel, Verbindungsstellen, einen ON-Knopf etc.
z.B. eine Kaffeemaschine, oder ein Kugellager

Zwei Dinge zeichnet eine Klasse/Baugruppe aus:
Methoden und Eigenschaften.

Methoden, wie der Name schon sagt, tun etwas, lösen etwas aus.
z.B. die Kaffeemaschine kocht Kaffee, oder "print", oder "draw" oder irgendwas.

Nun wird man als Hersteller nicht jede Kaffemaschine neu erfinden, sondern aus wenigen Grundkonzepten/Modell-Linien die ganze Produktpalette ableiten.
z.B. Kaffeemaschine "Basis" (bei Aldi)
z.B. Kaffeemaschine "Luxus" (bei Lidl) mit Kontrollampe.

Genauso werden die Klassen nicht neu erfunden, sonder, wie man sagt "vererbt".
Die Kaffeemaschinen-Klasse "Basis" wird auf die "Luxus"-Klasse vererbt, und in der "Luxus"-Klasse neue Methoden und neue Eigenschaften zugefügt.
Genauso wie es eine "Produktpalette" mit Stückliste(n) gibt, gibt es dann auch eine "Klassenhierarchie".

Genauso kann man bei der Vererbung "Eigenschaften" und (insbesondere) Methoden überschreiben. Beispielsweise wird die "Kontrollampe" durch "Warnsirene" überschrieben.

Wenn Du Deine Klassen anderen zur Verfügung stellst, gibst Du im Endeffekt nur deren "Eigenschaften" und "Methoden" bekannt.
Welchen Sauhaufen Du in den Klassen selbst hast, der ist für andere unsichtbar.
Und das ist dann die wunderbare Eigenschaft der Kapselung.

starKI · « **Reply #3 on:** April 19, 2007, 05:48:03 pm »

Ich glaub, dass Ding zu programmieren ist das allergeringste Problem. Man muss überhaupt erstmal begreifen, was die von uns wollen. Und das erscheint mir doch sehr schwierig, da alles nur sehr vage formuliert ist.
Und ein Kasten Bier reicht für die Aufgabe sicher nicht

Abus · « **Reply #4 on:** April 19, 2007, 09:55:24 pm »

...ok jungs da hat schon etwas licht ins dunkle gebracht!!....(Digit was trinkst du für bier??)

....aber wenn ich mir so die aufgaben durchlese, und mir auffällt, dass die nichtmal in der lage sind ordentliche und eindeutige fragen zu stellen bzw. angaben zu machen wächst mir ne feder an der stelle eurer wahl.....ist echt hart....!!

naja das tutorial hab ich auch schonmal angezoggt, wobei ich sagen muss, dass es einiges abverlangt....auch an zeit!

....das problem an der ganzen sache ist, dass man mit gesundem menschenverstand nicht weit kommt und nichtmal dem kumichl ordentliche fragen stellen kann.....

...er hat mir versucht ne halbe stunde zu erklären was ein programm ist......(ja auch an ihm nagt der zahn der zeit)....

ICH ERHOFFE MIR VON DIESEN THREAD EINSTEIGERFRAGEN ZU STELLEN UND SIE MÖGLICHST BEANTWORTET ZU BEKOMMEN

IM NAMEN VON MINDESTENS 80% ALLER BEDANKE ICH MICH IM VORAUS........abus

edit by Caschu: schalte mal lieber dein CapsLock aus, ich denke wir können auch so sehr gut lesen!

Rob69 · « **Reply #5 on:** April 22, 2007, 10:20:47 pm »

mal ne grundlegende frage zu der aufgabe: meiner meinung nach kann man das garnich so einfach programmiern weil das eigentlich eine zusammenhängende aufgabe ist, und die teile untereinander verbunden sind...

ich denke jede teilaufgabe ist auf klassen aus anderen teilaufgaben angewiesen..so seh ich das also müsste man die ganze aufgabe programmiern..man kann doch nich einfachs aufs blaue klassen aus dem zusammenhang gerissen programmiern und entwickeln...wie soll das gehn könnt ihr mir da weiterhelfen?

starKI · « **Reply #6 on:** April 23, 2007, 11:37:30 am »

Du entwickelst einfach dein Zeug und setzt voraus, dass die Methoden bzw. Schnittstellen der anderen Gruppen existieren. Das Programm funktioniert dann natürlich nicht wirklich. Aber darum geht es denen nicht. In der Testumgebung die wir machen sollen, kannste dann z.B. Zufallswerte für die nicht programmierten Funktionalitäten verwenden oder sie manuell eintippen, etc.

DIGIT · « **Reply #7 on:** April 23, 2007, 04:56:32 pm »

Quote from: Abus

...ok jungs da hat schon etwas licht ins dunkle gebracht!!....(DIGIT was trinkst du für bier??)

Dunkles Eibauer. (macht stark und schlau)

Schritt (1)
Die Schosse muss funktionieren, nicht mehr und nicht weniger.
Alles ist erlaubt: Heftpflaster, Gummiringerl, Büroklammer, Selbstklopfnägel...

Die Grundversion funktioniert und deckt alle (wesentlichen) Anforderungen ab.
Gleichzeitig gibt sie den ersten Eindruck, wo denn der "Kern des Programms" ist und auch der "Grundgedanke".
Bei welchen Details muss ich noch nachdenken, und welche sind nur mehr Schreibarbeit?
Diese Grundversion liefert auch die Referenzdaten/Ergebnisdaten für die nachfolgenden Versionen.

Auf eine virenverseuchte Floppy kopiert und fertig ist die erste Kundenversion...

Schritt (2)
Zwischenfrage:
Nimmst Du überall bzw. überhaupt die "richtigen" Komponenten (z.B. zum Grafik-zeichnen?)

Zwischenfrage:
Was ist abartig komplex und/oder durch die Brust ins Auge und/oder gut gemeint aber nicht wirklich "hübsch"?

Zwischenfrage(n):
Was ist doppelt gemoppelt?
Was kann ich zusammenfassen?
Was möchte ich zusammenfassen?
Was gehört "strukturell" zusammen"?
z.B. Rechenkern, Plausikontrolle, Datenkonversion, Einlesen, Speichern, Grafik.

Diese zusammengehörenden Dinge strukturieren, also z.B. in ein "Modul" (mit Funktionen etc) auslagern.

Dabei, oh Wunder, schrumpft das "Hauptprogramm" zusammen, weil ja der Code in die "Module" ausgelagert wird.

Am Ende dieses Schritts sollte "die bisherige Funktionalität" mindestens übertroffen werden.

Auf eine CD kopiert und fertig ist die zweite Kundenversion...

Schritt (3)
Der Schritt von einem "strukturierten Modul" zu einer Klasse ist nicht mehr weit.
Vage gesprochen ist ein "strukturiertes Modul" schon eine Klasse.
Spätestens dann, wenn ich oben in der Datei "class{" und unten "}" einfüge und das als Klassendatei umwandle.
Klingt brutal und ist es auch.:w00t:
Aber dabei eine Menge gelernt. Operativ und vom "trüben Blick".

Am Ende dieses Schrittes wieder Funktionalität prüfen.
Tipp: Eine "Struktur" unterscheidet sich von einer Klasse am ersten Blick wenig.
Aber: Eine Klasse hat aber im Gegensatz (und als starkes Hilfsmittel) eben Methoden und (!!!) "denkende" Eigenschaften.

Schritt (4)
Wie sehr man die Schosse in "Klassen" aufteilt ist wohl Geschmackssache, ob sich bei den wenigen Klassen schon eine "Klassenhierarchie" ergibt ist fraglich.

Generell (1)
Bei diesem Projektansatz glaubt man, dass das ewiglich dauert.
Stimmt, einige Zeit und Mühe wird es schon kosten -
Aber im Endeffekt ist man (als Anfänger) schneller fertig, als sich gleich mit einer "optimal hypergeistreichen Klassenhierarchie:blink: " herumzuärgern (die von Haus aus vielleich schon nie funktionieren kann) und wo man ewig ändert, herumdoktert, verzweifelt und letztlich keine Ergebnisse erzielt.

Schritt (5)
Wer also Schritt 1 bis 4 tapfer durchlaufen hat der sollte - nun mit einiger Erfahrung und mit "besserem Gefühl für die Sache" das ganze Ding noch mal wegschmeissen und mit neuen Gedanken, Ideen, Gerüchten nochmals machen - getippt ist es ja dann schnell.

Generell (2)
Verwendet sprechende Namen in Eurem Code streng, ausnahmslos und von Anfang an.
z.B. pstxxx für Zeiger auf Struktur, dxxx für Double, pstxxx Pointer to string, udCxxx für (user defined Class), TBxx für Textbox, etc.
Ihr kommt sonst in Teufels Küche.

Nachtrag:
Wer mit Java - also der Programmiersprache des Monats - nicht zurechtkommt, der wartet halt noch einen Monat...

Grüße
DIGIT
:limes_0:

tigerente · « **Reply #8 on:** April 23, 2007, 05:24:01 pm »

@DIGIT:
Ich wünschte, du hättest letztes Jahr unsere Vorlesung in Delphi gehalten!:sorcerer:

Kannst du auch Elektrotechnik für Anfänger mit Kaffeemaschinen erklären?:ph34r:

Ziu · « **Reply #9 on:** April 23, 2007, 05:31:00 pm »

hi leute wie wäre es wenn wir gemeinsam einmal die aufgabe zerlegen und strukturieren würden! denke dass ist erstmal wichtiger als sich um die umsetzung im programm zu kümmern, der maschinenbauer fängt auch nich mit solidworks an, wenn ihm ein neues teil einfällt, er fängt mit einer skizze an! also wäre ich für konstruktive beiträge sehr erfreut, werde mich selbst jetzt mal mit der aufgabe beschäftigen und versuchen

- eingangsgrößen sowie
- ausgangsgrößen und
- operatoren

aus der aufgabenstellung zu filtern und in beziehung zu setzen!

denke nach dem prinzip sollte es möglich sein, die aufgabe effektiv zu strukturieren und den richtigen ansatz zu erhalten!

meinungen und verbesserungen sind erwünscht!

mfg Ziu