[__42__]

Zitat (LoD14: 14. Juli 2012 - 23:31)

ich kenn leute mit nem batchlor in informatik, die haben keinen plan, wie man main in java schreibt...

Ich für meinen Teil wäre froh, wenn ich von Java so wenig mitbekommen hätte.

[Holger_N]

Zitat (CrownMiro: 15. Juli 2012 - 20:15)

Ich möchte es lernen, aber Stefan, kannst du es Mir irgendwie verständlich erklären mit dem OOA, OOD, OOP?

Ich setze mich dan ganz ruhig in eine Ecke und höre mit zu.

[Stefan_der_held]

Zitat (CrownMiro: 15. Juli 2012 - 20:15)

Ich möchte es lernen, aber Stefan, kannst du es Mir irgendwie verständlich erklären mit dem OOA, OOD, OOP?

mal eben so aus der Hüfte geschossen leider nein. Dafür ist es zu umfangreich.

Eine Grundlage zum UML ist zum Beispiel das wesentlich einfacherere Programm/Prozessablaufdiagramm.

OOA: "Was könnte es werden, was will ich haben"
OOD: "Wie könnte es aussehen/realisiert werden"
OOP: "So wird es umgesetzt"

Wie nun OOA/OOD stattfindet da empfehle ich dir entsprechende Bücher zum Beispiel von Gallileo-Computing und Wikipedia.

Denke ja mal nicht, dass du Programme schreiben willst die nur aus

Input $a
print "hallo, ",$a

bestehen sollen - also solche die recht wenig komplex sind und wo ohne Analyse/Design nich die Übersicht und das Ziel aus den Augen verloren werden kann.

Evtl. könnte das von dir ausgesuchte Java-Buch schon einiges mitbringen. Leider ist nicht abzusehen wieviel "Vorwissen" vorausgesetzt wird.

Zum einfachen (aber weniger Objektorientierten) Programm Ablaufplan:
http://de.wikipedia....grammablaufplan

Zum Erstellen der Pläne nehme ich persönlich gerne Microsoft Visio - ist aber nur eine von vielen Möglichkeiten

Dieser Beitrag wurde von Stefan_der_held bearbeitet: 15. Juli 2012 - 21:09

[Holger_N]

Zitat (Stefan_der_held: 15. Juli 2012 - 20:59)

OOA: "Was könnte es werden, was will ich haben"
OOD: "Wie könnte es aussehen/realisiert werden"
OOP: "So wird es umgesetzt"

Naja aber das ist doch eigentlich Blödsinn. Das ist ja als würde jemand fragen, wie man am besten Auto fahren lernen kann und kriegt dann so Weisheiten wie "Bevor man ins Auto steigt und losfährt, sollte man sich klar machen, wo man überhaupt hinfahren will." Das ist zwar für das Autofahren logisch, bringt aber jemanden nicht weiter, der wissen will, wie er die Fahrschule angehen soll.

[Stefan_der_held]

Zitat (Holger_N: 15. Juli 2012 - 21:12)

Naja aber das ist doch eigentlich Blödsinn. Das ist ja als würde jemand fragen, wie man am besten Auto fahren lernen kann und kriegt dann so Weisheiten wie "Bevor man ins Auto steigt und losfährt, sollte man sich klar machen, wo man überhaupt hinfahren will." Das ist zwar für das Autofahren logisch, bringt aber jemanden nicht weiter, der wissen will, wie er die Fahrschule angehen soll.

Für den AutoFahrer ist sowas selbstredend unsinn einen Plan zu machen... der Autofahrer währe auch nur vergleichbar mit dem Anwender - dem interessiert es ja auch nicht unbedingt wie etwas funktioniert solange es funktioniert.

ehr mit dem Entwickler eines Autos. Ein Auto zu entwickeln ohne sich vorher darüber gedanken und pläne gemacht zu haben ist sehr riskant und kann schnell nach hinten los gehen

[Holger_N]

Zitat (Stefan_der_held: 16. Juli 2012 - 06:11)

Für den AutoFahrer ist sowas selbstredend unsinn einen Plan zu machen... der Autofahrer währe auch nur vergleichbar mit dem Anwender - dem interessiert es ja auch nicht unbedingt wie etwas funktioniert solange es funktioniert.

ehr mit dem Entwickler eines Autos. Ein Auto zu entwickeln ohne sich vorher darüber gedanken und pläne gemacht zu haben ist sehr riskant und kann schnell nach hinten los gehen

Ich muß doch sowieso erst die Idee haben, was es werden soll und setze mich dann hin und programmiere. Also ohne dieses "OOA" fängt man doch dann gar nicht an. Man muß es also nicht irgendwie extra machen, weil es ja eine Bedingung ist.

[Stefan_der_held]

ja ein vernünftiger Mensch würde nicht ohne OOA programmieren - da hast du recht. Gehört aber trotzdem dazu (wie man die Analyse nun macht bleibt ja jedem selbst überlassen).

Nur es ist nicht verkehrt immer eine Vorgehensweise in der Entwicklung zu haben (stichwort "Projektplanung") - sonst kann es schnell recht chaotisch werden.

[Kirill]

Mal ein Tip, gerade für den Anfang. Erst machen, dann reden. Nach einer gewissen Programmiererfahrung ist die ganze OOP-Geschichte eine Kleinigkeit zum Verstehen. Ohne Programmiererfahrung kann man da noch so viel Theorie büffeln, nutzen wird es nix.

[Holger_N]

Zitat (Kirill: 16. Juli 2012 - 09:38)

Mal ein Tip, gerade für den Anfang. Erst machen, dann reden. Nach einer gewissen Programmiererfahrung ist die ganze OOP-Geschichte eine Kleinigkeit zum Verstehen. Ohne Programmiererfahrung kann man da noch so viel Theorie büffeln, nutzen wird es nix.

Also ich versuche jetzt seit 9 Jahren, hinter das Geheimnis von C++ zu kommen, praktisch und theoretisch aber bislang ohne Aha-Effekt.

[oldsqldma]

Also ich halte wenig davon, direkt mit OOP einzusteigen.
Nach meiner Meinung wäre es sogar am optimalsten, sich von der Digitaltechnik hochzuarbeiten, aber das ist dann am Ende auch eher etwas für Leute, die richtig wissen wollen, was da passiert. (Was auch hilfreich ist, wenn es um Optimierung geht, die nicht durch den Compiler vorgenommen werden kann)

OOP in seinen Grundzügen ist ja nicht sonderlich kompliziert und leicht verständlich. (Das lässt sich sogar mit anschaulichen Beispielen wie Autos etc. pp. erklären)

Aber irgendwann kommt es doch zu logischen Problemen, z.B. folgendes Konstrukt:

class A
{
    public:
        int add_three(int a)
        {
            return a+3;
        }
};

int main()
{
    A x;
    int (*ptr)(int) = x.add_three; // <-- error: argument of type 'int (A::)(int)' does not match 'int (*)(int)'

    return 0;
}

Wobei der Code an sich richtig aussieht, ist er grundlegend falsch. Für soetwas müsste man natürlich dann wissen, wie OOP in C++ (und wohl auch in fast allen anderen Sprachen) funktioniert.
(u.A. das der erste Parameter ein unsichtbare Pointer der Klasse ist, da Klassen im Prinzip ein struct ist und die vtable enthält. Wenn man das weiß, dann kann man sich sogar C++ Klassen in C warpen ;))

Es gibt viele Dinge, die man nicht ohne das Wissen der Materie handhaben kann. (Aber es ist ja auch selten, selbst in der Industrie gefordert. Das Wissen brauchen eher dann die Framework programmierer, mit dem andere dann programmieren)

Aber es gibt in keiner Sprache Geheimnisse. Wo liegt denn dein Problem genau, Holger_N?

[Kirill]

Zitat (Holger_N: 16. Juli 2012 - 10:07)

Also ich versuche jetzt seit 9 Jahren, hinter das Geheimnis von C++ zu kommen, praktisch und theoretisch aber bislang ohne Aha-Effekt.

C++ ist auch ein spezieller Fall. Ich kann OOP programmieren, mag C++ aber überhaupt nicht und kann C++ nur sehr mäßig. Ich finde C++ ohnehin reichlich nutzlos. An Komfort lässt die Sprache viel vermissen. An Fähigkeiten... Naja. Klar kann man mit C# (meine Sprache der Wahl) schlecht Systemprogrammierung betreiben, das wirst du aber auch eher mit C (mache ich für µ-Controller) arbeiten. Insofern kann man auf C++ ohnehin komplett verzichten.

PS: ich finde das Codebeispiel von oldsqldma ziemlich abartig, weil schwer zu lesen und schwer zu verstehen. Klar, das war auch das Ziel ("Wenn der Code richtig aussieht..."), aber da merkt man, finde ich, dass C++ einfach nur grottig ist. Ähnliche Konstrukte schreibt man in C# deutlich lesbarer.

Dieser Beitrag wurde von Kirill bearbeitet: 16. Juli 2012 - 11:45

[Holger_N]

Zitat (oldsqldma: 16. Juli 2012 - 10:45)

...
Aber es gibt in keiner Sprache Geheimnisse. Wo liegt denn dein Problem genau, Holger_N?

Ein kleines Beispiel (also ich kann PHP, damit hab ich keinerlei Probleme)

Folgenden Code kann man ja nahezu 1:1 übernehmen

switch (Zeichen)

{
 case '+' : Ergebnis = Zahl1 + Zahl2; break;
 case '-' : Ergebnis = Zahl1 - Zahl2; break;
 case '*' : Ergebnis = Zahl1 * Zahl2; break;
 case '/' : Ergebnis = Zahl1 / Zahl2; break;

}

cout << Ergebnis << endl ;

Das ganze Drumrum hab ich jetzt mal weggelassen, also deklariert sind alle Variablen.
Dieser Code funktionierte 9 Jahre lang nicht mit der Fehlermeldung beim compilieren, dass für dieses "switch" ausschließlich Zahlen erlaubt wären. (Testweise umgeschrieben mit Zahlen funktionierte die Konstruktion auch). Dann von einem Tag auf den Anderen funktionierte der Code aber ohne etwas daran geändert zu haben. Die gleiche Entwicklungsumgebung, der gleiche Compiler, der gleiche Code. Einen Tag gibts ne Fehlermeldung, am nächsten Tag gehts. Diese Logik möchte ich zunächst mal verstehen.