Wie lerne ich am Besten Java

[H3ctor]

Hi Leute,

ich bin neu hier und möchte mir im Selbststudium Java beibringen. Meine bisherigen Programmiererfahrungen beschränken sich auf: HTML, PHP, CSS, MYSQL.
Und zwar nur auf prozeduale Programmierung. OOP hab ich trotz eiinigen Versuchen noch nicht zu 100% verstanden.

Am Liebsten lerne mit Learning by Doing.

Deshalb habe ich mir ein Projekt folgendes Projekt überlegt, welches ich unbedingt umsetzen möchte. Nur weiß ich nicht wie ich am Besten vorgehe. Vielleicht gebt ihr mir ein paar Tipps:
Ich hätte gerne ein Kontoverwaltungsprogramm, bei dem ich im ersten Schritt aus der Zwischenablage durch Tabstops getrennt folgende Daten einfüge:
"Datum der Überweisung";"Überweisungstext";""Überweisungsbetrag"
Wenn ich den Text einfüge, welcher dem Kontodaten von ca. 1 Jahr entspricht, wähle ich die Anzahl der Spalten aus ( in diesem Fall 3 ) und das Trennzeichen (in diesem FAll Tabstop).
Dann hätte ich gerne, dass der Text getrennt und in ein Array übernommen wird.
Dann eine Auflistung der ersten Zeile. Danach wählt man aus, was für Daten in welcher Spalte vorhanden sind (mittels DropDown oder so).
Dann würde ich gerne die Daten weiterverarbeiten, damit ich meine Bilanz für jedes Monat anzeigen kann.

In weiterer Folge wäre es toll, wenn ich die Daten speichern und erweitern könnte.

Ich hoffe ihr fresst mich nicht gleich, wenn ich so viel verlange und so viel vorhabe.

Danke für Tipps.

LG euer H3ctor

 

[Ariol]

Gefressen wir niemand - meistens....

Zuerst einmal solltest du dich mit OO auseinandersetzen, sonst tust du dir ziemlich schwer.

Zum einfachmachen:
(Fast) alles ist ein Objekt:

• Die Zeichenkette
• Die Datenbankschnittstelle
• Der Datensatz
• Der Eingabestream

Ausnahmen sind primitiven Datentypen á la int, char, long,...

Bevor du dich also gleich an ein konkretes Projekt wirfst, solltest du die Grundlagen der OO-Programmierung zumindest ansatzweise intus haben. (Objekte, Vererbung, Interfaces)

Danach solltest du mal ein bisschen damit rumspielen - und zwar ganz ohne GUI.

Wenn du hier etwas sicherer bist was das Handling angeht dann kannst du mit der grafischen Programmierung beginnen.

GUI und Logik sollten eh immer getrennt sein - d.h. du kannst dir bei erstmal die Logik auf und dann die GUI drumherumbauen.

Ansonsten noch zum lesen:

Galileo Computing :: Java ist auch eine Insel (8. Auflage)
Das hat auch ca. die oben genannte Reihenfolge, wobei du einige der Kapitel zwischen 2 und 16 überspringen kannst (XML wirst du z.B. zu Anfang kaum brauchen.)

 

[H3ctor]

Danke für die schnelle Antwort.
Möchte meine bisherige Lektüre mit euch teilen:
Das Einsteigerseminar Objektorientierte Programmierung in Java: Der methodische und ausführliche Einstieg: Amazon.de: Alexander Niemann: Bücher
Java-Lehrbuch.: Amazon.de: Udo Müller: Bücher
Jetzt lerne ich Java 6 Start ohne Vorwissen - ISBN 978-3-8272-0767-8
Java 6 Video-Training Einstieg für Anspruchsvolle - ISBN 978-3-8273-6060-1
Jetzt lerne ich Java 5 Video-Training Start ohne Vorwissen - ISBN 978-3-8272-0754-8

Zum Thema OOP:
In der o.g. Lektüre wird OOP eh immer erklärt, aber ich verstehe den "Vorteil" von OOP einfach nicht.
Die Bsp. ein Fahrzeug ist ein Objekt, welches das Attribut rot oder blau haben kann und die Methode beschleunigen und bremsen unterstützt ist für mich zu unverständlich. Weil ich mir nicht vorstellen kann, was das mit programmieren zu tun hat.

OOP ist sicher eine wichtige Grundlage. (nach Datentypen und Typisierung, welches ich verstehe und nachvollziehen kann)

Probieren ohne GUI ist mal langweilig. für Konsolenprogramme alla "Hallo Welt" fehlt mir die Geduld. Ich brauche ein Erfolgserlebnis größeren Ausmaßes. *g*

 

[Landei]

OO hat viele Vorteile. Ein Objekt beinhaltet nicht nur Daten, sondern weiß, was es damit anstellen kann, sie bilden "sinnvolle Einheiten". Nehmen wir den Abstand zweier Punkte. Ohne OO sieht das etwa so aus:

public double distance(double x1, double y1, double x2, double y2) {
   double dx = x1-x2;
   double dy = y1-y2;
   return Math.sqrt(dx*dx+dy*dy);
}

Um diese Funktion benutzen zu können, musst du mit den einzelnen Koordinaten hantieren, du musst wissen in welcher Reihenfolge sie kommen usw.

class Point {
  double x,y; 
  public Point(double x, double y) {
     this.x = x;
     this.y = y;
  }
  public double distance(Point that) {
    double dx = this.x-that.x;
    double dy = this.y-that.y;
    return Math.sqrt(dx*dx+dy*dy);
  }
}

//Aufruf:
Point p1 = ...
Point p2 = ...
double dist = p1.distance(p2);

Jetzt hat man eine kompakte Punkt-Klasse, die selber "weiß", wie sie den Abstand berechnet. Kein Irrtum möglich.

Wenn wir jetzt z.B. in unserem System 3D- statt 2D-Punkte verwenden wollten, wäre das kein Problem: Wir ändern ein einziges mal unsere Punktklasse, und alle Stellen, an denen mit dem Abstand gearbeitet wird, arbeiten weiter, als wäre nichts geschehen. In der ersten Version müsste dagegen bei jedem einzelnen Aufruf nun zusätzlich die zwei z-Koordinaten übergeben werden. Genau diese Bündelung von "Kompetenzen" macht OO-Systeme robuster und flexibler gegenüber Änderungen.

 

[Ariol]

Die Bsp. ein Fahrzeug ist ein Objekt, welches das Attribut rot oder blau haben kann und die Methode beschleunigen und bremsen unterstützt ist für mich zu unverständlich. Weil ich mir nicht vorstellen kann, was das mit programmieren zu tun hat.

Das kommt auf den Anwendungsfall an.
Wenn du z.B. eine Software für die Berechnung der KFZ-Versicherung schreiben willst/musst erstellst du z.B. eine Klasse Fahrzeug.

Diese Klasse machst du abstrakt, d.h. du kannst kein direktes Objekt davon erstellen, aber innerhalb dieser Klasse kannst du bereits bestimmte Attribute festlegen.
Z.B. dass das Fahrzeug Eigenschaften wie Anzahl der PS/KW und Reifen haben muss.

In einer erbenden Klasse Klasse wie beispielsweise Auto kannst du dann weiter Attribute wie Sitze, Airbags, Türen usw. einbauen.

Usw, usw...

Der Vorteil dabei ist, dass gleiche Attribute nicht wieder erneut gesetzt und definiert werden müssen.

Probieren ohne GUI ist mal langweilig. für Konsolenprogramme alla "Hallo Welt" fehlt mir die Geduld. Ich brauche ein Erfolgserlebnis größeren Ausmaßes. *g*

Kannst du natürlich, aber dir muss bewusst sein, dass es sich hierbei auch wieder um Objekte handelt und du auch des öfteren von diesen erben musst. Deshalb ist ein gewisses Grundverständnis von OOP von Vorteil.


Ich schreib dir hier mal ein kleines Beispiel:

package fahrzeug;

abstract class Vehicle
{
	protected String manufacturer; 
	protected String name;
	protected double kw;
	protected int numberOfWheels;
	
	public Vehicle(String manufacturer, String name, double kw, int numberOfWheels)
	{
		this.manufacturer = manufacturer;
		this.name = name;
		this.kw = kw;
		this.numberOfWheels = numberOfWheels;
	}

	public double getKw()
	{
		return kw;
	}

	public void setKw(double kw)
	{
		this.kw = kw;
	}

	public String getName()
	{
		return name;
	}

	public void setName(String name)
	{
		this.name = name;
	}

	public int getNumberOfWheels()
	{
		return numberOfWheels;
	}

	public void setNumberOfWheels(int numberOfWheels)
	{
		this.numberOfWheels = numberOfWheels;
	}

	public String getManufacturer()
	{
		return manufacturer;
	}

	public void setManufacturer(String manufacturer)
	{
		this.manufacturer = manufacturer;
	}

	
}

package fahrzeug;


public class Car extends Vehicle
{
	protected int numberOfSeats;
	protected int numberOfDoors;
	protected int numberOfAirbags;
	

	public Car(String manufacturer, String name, double kw, int numberOfSeats, int numberOfDoors, int numberOfAirbags)
	{
		super(manufacturer, name, kw, 4);
		this.numberOfSeats = numberOfSeats;
		this.numberOfDoors = numberOfDoors;
		this.numberOfAirbags = numberOfAirbags;
	}
	
	public int getNumberOfAirbags()
	{
		return numberOfAirbags;
	}

	public void setNumberOfAirbags(short numberOfAirbags)
	{
		this.numberOfAirbags = numberOfAirbags;
	}

	public int getNumberOfDoors()
	{
		return numberOfDoors;
	}

	public void setNumberOfDoors(short numberOfDoors)
	{
		this.numberOfDoors = numberOfDoors;
	}

	public int getNumberOfSeats()
	{
		return numberOfSeats;
	}

	public void setNumberOfSeats(short numberOfSeats)
	{
		this.numberOfSeats = numberOfSeats;
	}

	
}

package fahrzeug;

public class Motorcycle extends Vehicle
{

	public Motorcycle(String manufacturer, String name, double kw)
	{
		super(manufacturer, name, kw, 2);
	}

}

Und zum ausprobieren:

package fahrzeug;

import java.util.ArrayList;

public class Main
{
	public static void main(String[] args)
	{
		Car fiatPanda = new Car("FIAT","Panda",30,4,3,0);
		Car opelKadett = new Car("Opel","Kadett",52,5,5,0);
		Motorcycle yamahaYZ450F = new Motorcycle("Yamaha","YZ 450 F 010",44);
		
		ArrayList<Vehicle> vehicles = new ArrayList<Vehicle>();
		vehicles.add(fiatPanda);
		vehicles.add(opelKadett);
		vehicles.add(yamahaYZ450F);
		
		for(Vehicle vehicle:vehicles)
		{
			System.out.println(vehicle.getManufacturer());
			System.out.println(vehicle.getName());
			System.out.println(vehicle.getKw());
			System.out.println(vehicle.getNumberOfWheels());
			System.out.println("#########################");

		}
	}
}

Als Ausgabe erhälst du dann:

FIAT
Panda
30.0
4
#########################
Opel
Kadett
52.0
4
#########################
Yamaha
YZ 450 F 010
44.0
2
#########################

Geh beim OOP erstmal vom programmieren weg und denk in realen Begriffen und Objekten.
Das Einbauen von Algorithmen kommt dann verhältnismäßig leicht (v.a. da du ja darin schon Vorkenntnisse hast).

 

[Painii]

Die Bsp. ein Fahrzeug ist ein Objekt, welches das Attribut rot oder blau haben kann und die Methode beschleunigen und bremsen unterstützt ist für mich zu unverständlich. Weil ich mir nicht vorstellen kann, was das mit programmieren zu tun hat.

Du versuchst Objekte der realen Welt auf dein Programm abzubilden.
Ein Auto hat dann eine Farbe und kann beschleunigen/bremsen.

Dein Programm kann dann entsprechend mit den Objekten arbeiten (z.b. den "Fahrer" für dein Auto spielen, bzw. besser einem Fahrer ein Auto geben mit dem er dann fahren darf).

Dauert sicher etwas, aber wenn du bei Java bleiben willst dann wird sich die OOP dir bestimmt noch erschliessen.

 

[H3ctor]

Danke für eure intensiven Bemühungen mit OOP näher zu bringen.
Das Bsp. vom Landei hat mich einen Schritt näher gebracht. Dennoch finde ich es sehr schwer OOP wirklich zu verstehen. Dabei ist OOP ja genau deswegen eingeführt worden, um Programmieren leichter zu machen und mit Alltagsdingen zu verbinden, oder?

Werde mir in Ruhe eure Bsp noch durchdenken und mal etwas probieren.
Danke einstweillen, wenn jemand noch Tipps für Lektüre oder sonst was hat - nur her damit!
Eine Frage noch: Wie haben die Profis unter euch Java erlernt???
Wahrscheinlich alle über ein Informatik o.ä. Studium, und (fast) keiner über Selbststudium zu Hause, oder?

 

[H3ctor]

    public Car(String manufacturer, String name, double kw, int numberOfSeats, int numberOfDoors, int numberOfAirbags)
    {
        super(manufacturer, name, kw, 4);
        this.numberOfSeats = numberOfSeats;

Eine Frage hätte ich noch:
this.numberOfSeats ist das gleiche wie Car.numberOfSeats oder?

Und für was steht super?

 

[Painii]

Eine Frage hätte ich noch:
this.numberOfSeats ist das gleiche wie Car.numberOfSeats oder?

Das this bezieht sich auf dein Objekt.
Ein Objekt Auto hat 5 Sitze, dann ist this.numberOfSeats==5.
Ein anderes hat vielleicht nur 4, dann ist da this.numberOfSeats==4.
Würde Car.numberOfSeats exisitieren, dann hätten alle Objekte von Car genau soviele Sitze wie da drin steht.

Und für was steht super?

Den Konstruktor der Oberklasse (hier vehicle).
Der macht die Sachen die für alle Objekte von Vehicle gleich sind. (z.b. wurde eben ein Fahrzeug, egal ob Auto oder Fahrrad, von einem Hersteller gebaut)


Und ich studier zwar Informatik, aber das wirkliche programmieren hab ich mir so schon selbst beigebracht (also die Sachen die über "hello world" rausgingen ).

 

[H3ctor]

Aha...schon klarer.
Im o.g. Bsp geht es also darum, dass in erster Linie die Gemeinsamkeiten aller Fahrzeuge gefunden und deklariert werden.
Dann werden speziellen Fahrzeuge wie Auto und Motorrad vererbt und genauer spezifiert.
sehe ich das richtig?

Auch wenn ich das verstehe, hab ich keine Ahnung, wie ich das in der Praxis umsetzen soll/kann.

 

[Ariol]

Naja, bei der GUI-Erstellung zum Beispiel.

In Swing erben alle Objekte von JComponent.

JComponent vereint solche Dinge wie Position, Größe usw.
Dann kann man andere Komponenten davon ableiten (einen Button, ein Texfeld,...) die sich alle nicht mehr um die eh gemeinsame Attribute kümmern müssen, aber können.

Außerdem kann mal auf einem Panel (also einer Fläche) verschiedene Komponenten plazieren.
Wenn man die Methoden zum hinzufügen von Komponenten also mit einem JComponent-Parameter ausstattet ist es dem Panel egal, ob jetzt ein JButton oder ein JTextfield hinzugefügt wird - hauptsache es ist eine Komponente.

 

[babuschka]

Wurde hier im Forum bestimmt schon öfters genannt, aber um OOP zu verstehen, kann ich dir das Buch Head First Java vom O'Reilly Verlag empfehlen, falls du mit dem Stil klarkommst. Unter dem Link kannst du mal reinlesen. Ich find's super, aber vielen ist dieser "bunte" Ansatz offenbar suspekt
Ich habe OOP zwar nicht aus dem Buch, sondern in der Schule gelernt, aber es ist sehr schön erklärt. Gerade weil nicht nur das Prinzip erklärt, sondern richtig in die Denkweise eingeführt und die Vorteile dieses Vorgehens erläutert werden.

Ach ja: Ob die deutsche Übersetzung was taugt, weiß ich nicht.

 

[Gast2]

Das Bsp. vom Landei hat mich einen Schritt näher gebracht. Dennoch finde ich es sehr schwer OOP wirklich zu verstehen. Dabei ist OOP ja genau deswegen eingeführt worden, um Programmieren leichter zu machen und mit Alltagsdingen zu verbinden, oder?

und das macht es - um einiges ... ich habe 1990/91 mit BASIC auf einem KC85 angefangen - ist immer feinster Spagetticode geworden ... dann habe ich auf Pascal gewechselt - Spagetti ist weniger geworden ... anschließend C ... im Studium habe ich OOP auch nicht wirklich verstanden ... die Effektivität von OOP verstehst Du erst wirklich wenn Du es nutzt ... wenn Du dann noch Polymorphie einsetzen kannst :toll: ... ich habe OOP erst im Praxissemester richtig kapiert - Polymorphie nach dem Studium

beib erstmal bei der Konsole und solchen Spielen wir KFZ/Tiere/Welt ... wobei das KFZ Beispiel schon Polymorphie enthält

hand, mogel

 

[H3ctor]

Danke für die Buch-Empfehlung. Hab schon bei amazon in den Empfehlungen gelesen, dass diese Serie sehr gut verständlich und eine interessante Art hat.

 

[hdi]

Bei der Head First Reihe kann ich nur zustimmen! Hab mir das Design Pattern Buch von denen geholt, und das ist echt Klasse! Wäre auch für dich eine weiterführende Literatur nach dem Grundkurs Buch. Weil bei den Grundkurs-Büchern lernst du nur, was OOP ist und wie man es im Code einsetzt, aber nicht wann man es einsetzt und was es bringt.
Ich habe über ein Jahr lang fleißig Interfaces geschrieben und benutzt, ohne dass es auch nur einen Hauch von Sinn gehabt hätte, aber das ist mir erst ziemlich spät aufgefallen.
Das Design Pattern Buch rüttelt einen da ziemlich wach...

 

[titus]

Ich habe Vorlesungsfolien aus Programmierung I (Java-Grundlagen, OOP, etc.) und Programmierung II (einfache Algorithmen, Nebenläufigkeit, Grafikprogrammierung, etc.) und die dazugehörigen Übungsblätter zu beiden Vorlesungen. Die Folien sind recht ausführlich. Ich denke, wenn du dir ein Buch noch dazu holst – für Sachen, die aus den Folien nicht ganz klar hervorgehen – dann sollte es ganz gut klappen.

Wenn du Interesse hast, dann schick mir eine PN mit deiner E-Mail-Adresse.

 

[H3ctor]

Ist es sinnvoll sich mit DesignPattern vor den Programmieren zu beschäftigen, oder reicht es auch, wenn man sich nachher damit quält.

 

[Painii]

Ist es sinnvoll sich mit DesignPattern vor den Programmieren zu beschäftigen, oder reicht es auch, wenn man sich nachher damit quält.

Zum reinen Java lernen würd ichs erstmal lassen.
Wenn du irgendwann dazu kommst dass dein Programm auch mal später verwendet werden könnte, dann würde ich sie mir erst anschauen. Den richtigen Zeitpunkt dafür zu finden ist dann das schwierige.

Andererseits, Dinge wie MVC oder so lohnen sich bestimmt auch ganz am Anfang, dann hat man direkt die Trennung vor Augen auf die man achten sollte.

Naja, spätestens wenn du im Job damit arbeitest solltest du DesignPattern kennen und sagen können warum du ein bestimmtes (nicht) einsetzt.

 

[darkeye2]

da es hier um oop passt, mal ne frage, wenn ich ne klasse figur habe, und von dieser klasse erbt die klasse mensch wenn ich jetzt eine klasse arbeiter erstellen würde, die von mensch erben würde, dann hätte die doch auch die methoden von figur, da mensch davon ja erbt? Oder funktioniert es nicht über mehrere klassen?

 

[hdi]

Also generell geht das schon über mehrere Klassen, ja. Aber es ist ein wenig komplizierter.. Ich muss gestehen ich bin mir grad nicht in allen Details zu 100% sicher, also prüfe meine folgenden Aussagen nochmal nach, wenn es dich interessiert:

1) private Attribute werden vererbt, sind aber in der Subklasse nicht sichtbar
2) private Methoden werden nicht vererbt
3) protected Attribute werden vererbt und sind in der Subklasse sichtbar, aber nicht mehr in der Subklasse der Subklasse
4) protected Methoden werden vererbt und sind in der Subklasse sichtbar, werden aber nicht mehr an die Subklasse der Subklasse vererbt.
5) Mit Packages hängt das glaube ich auch noch zusammen...

Ich weiss nicht ob ich noch was vergessen hab. Das ist wie gesagt nicht allzu trivial, nur bei public kann man sich sicher sein: Das wird schön brav die Hierarchie heruntergeerbt, und bleibt auch in jeder Subklasse voll sichtbar.

 

[Landei]

protected Methoden und Felder sind in beliebig "tiefen" Kindklassen sichtbar. Eigentlich logisch: Sonst würde in dem gar nicht so seltenen Fall, dass C von A erbt und man sich später überlegt, noch dazwischen eine Klasse B einzuführen (also C erbt von B und B von A) auf einmal alle protected Members von A in C "unsichtbar".

Und ganz allgemein: Was sollte so eine Beschränkung überhaupt bringen?

 

[hdi]

Hab mal eben nachgelesen was ich mir aufgeschrieben hatte als das Thema mal im SCJP-Guide zur Sprache kam. Das ist schon gut n halbes Jahr her, und ich hatte da tatsächlich etwas verwechselt:

Protected: (ACHTUNG das ist schwer!)
1) Access von Nicht-Sub-Klassen:
Direkter Zugriff möglich falls im selben Package, sonst nicht.
ACHTUNG:
protected heisst ja an sich:
Alle nicht-erbenden Klassen im selben Package haben direkten Zugriff auf das Member.
Bei erbenden Klassen gilt dies auch, wenn sie in einem anderen Package liegen.
Soweit denk ich ist das klar.

Aber jetzt die Sache:
Für nicht-erbende Klassen wird der Zugriff
auf private geschaltet, wenn das Kind in einem anderen Package liegt als der Vater.

Sprich hat Klasse A ein protected Member "x", und eine Subklasse B in einem anderen Package
erbt davon.
Da wir ja gesagt haben protected Member sind im gleichen Package für ALLE Klassen
sichtbar, kommt hier der Unterschied:
Eine andere, nicht erbende Klasse, im selben Package wie die Klasse B, kann NICHT
auf das Member von B zugreifen.

Nochmal zum Kontrast: Eine nicht erbende Klasse im selben Package wie A KANN auf
das protected Member von A zugreifen.

Wichtig also:
1) Subklasse liegt in einem anderen Package als Vaterklasse
2) Alle nicht-erbenden Klassen haben keinen Zugriff mehr
auf das Member von dieser Subklasse, auch nicht wenn sie im gleichen Package wie das Kind liegen.

...jaja SCJP 2011 ^^ Muss mal wieder weitermachen damit, diese ganzen Sachen vergisst man zu schnell.

 

[Painii]

Also protected sollte nur im gleichen package sichtbar sein, kein modifier nur in subklassen:

public class Parent{
 protected int erbt; //im package, vererbung egal -> nur sichtbar für Children wenn sie im gleichen package liegen
 int pack; //vererbung, kein package -> nur für Parent und Children (und deren Children etc.)
}

Sinn davon... hmm, keine Ahnung, wenn man vielleicht im package eine Klasse hat die nach draussen keiner braucht (quasi eine Zwischenstufe zwischen private und public Klassen ), aber die im package wichtig wären. Konkretes Beispiel fällt mir auf Anhieb nicht ein wo es sinnvoll wäre.

 

[Landei]

Äh, ich glaube du verstehst hier etwas miss:

8.2.1.2 Inheritance with public and protected
Given the class Point:

    package points;
    public class Point {
    	public int x, y;
    	protected int useCount = 0;
    	static protected int totalUseCount = 0;
    	public void move(int dx, int dy) {
    		x += dx; y += dy; useCount++; totalUseCount++;
    	}
    }

the public and protected fields x, y, useCount and totalUseCount are inherited in all subclasses of Point.

Therefore, this test program, in another package, can be compiled successfully:

    class Test extends points.Point {
    	public void moveBack(int dx, int dy) {
    		x -= dx; y -= dy; useCount++; totalUseCount++;
    	}
    }

Java Language Specification

 

[Burki]

Wurde hier im Forum bestimmt schon öfters genannt, aber um OOP zu verstehen, kann ich dir das Buch Head First Java vom O'Reilly Verlag empfehlen, falls du mit dem Stil klarkommst. Unter dem Link kannst du mal reinlesen. Ich find's super, aber vielen ist dieser "bunte" Ansatz offenbar suspekt
Ich habe OOP zwar nicht aus dem Buch, sondern in der Schule gelernt, aber es ist sehr schön erklärt. Gerade weil nicht nur das Prinzip erklärt, sondern richtig in die Denkweise eingeführt und die Vorteile dieses Vorgehens erläutert werden.

Ach ja: Ob die deutsche Übersetzung was taugt, weiß ich nicht.

Ich habe dann wohl die deutsche Übersetzung bis fast zur Hälfte durchgefressen
"Java von Kopf bis Fuß"
Das ist das beste Buch über's programmieren, das ich je geschmökert habe.
Da werden wirklich alle Zusammenhänge erstklassig herübergebracht :toll:

 

[petterson]

"Java von Kopf bis Fuß"

Das lese ich auch gerade und finde es sehr lustig und spannend. Es macht richtig Spass!
Vor einigen Jahren hatte ich schon mal in "Java lernen mit BlueJ" reingelesen - das hatte ich auch ganz gut gefunden, zumindest, was OO betrifft (ich habe aber das meiste schon wieder vergessen ).

 

[darkeye2]

also so wie ich das sehe, sollten die classen public sein, dann hat man keine problem es über mehrere klassen hinweg zu vererben.

 

[Landei]

also so wie ich das sehe, sollten die classen public sein, dann hat man keine problem es über mehrere klassen hinweg zu vererben.

So pauschal kann man das nicht sagen. Das, was public oder protected ist, ist das, was der "Außenwelt" (außerhalb des Packages) präsentiert wird. Und hier sollte man aus gutem Grund nur soviel "preisgeben", wie man wirklich muss, und die innere Arbeitsweise verstecken. Wenn man z.B. Klassen braucht, um intern einen Algorithmus zu implementieren, dann sollte das "geheim" bleiben. Vielleicht möchte man morgen einen andere, effizientere Version implementieren, oder eine fremde Bibliothek dafür benutzen - aber davon soll der Nutzer unseres Packages bitte nichts mitbekommen. Die Schnittstelle zwischen Package und Außenwelt sollte so schmal wie möglich gehalten werden, das erleichtert Änderungen (auf beiden Seiten), Refactoring und Tests.

 

[H3ctor]

Danke für die Info. Dann werde ich mir das einmal bestellen. Die Kritiken auf amazon waren auch super. Also muss es wirklich gut sein.