Frage zu generischer Klasse und Casten

[Julesy]

Hiho,

hier meine erste Frage in diesem Forum Bin noch Java Anfänger also bitte nicht in der Luft zerreißen^^

Problembeschreibung:
Ich möchte einen Art Planer zu Übungszwecken programmieren. Ich habe mir die Klasse Day geschrieben die verschiedene Eigenschaften und Methoden mit Hilfe des GregorienCalendar hat.
Zusätzlich gibt es eine Klasse Workday die von Day erbt und zusätzliche Attribute besitzt.
Nun möchte ich eine Calendar Klasse mit einer LinkedList<T extends Day> erstellen.
Also irgwelche Kalendertage besitzen kann.

Meine Idee ist immer nur den aktuellen Tag im Konstruktor zu erstellen und dann mit Hilfe eines Iterator alle folgenden Tage zu konstruieren. Ist das sinnvoll?

Auch wenn das Objekt mit MyCalendar<Workday> erstellt wird, erzeugt LinkedList<T> eine LinkedList<Day> und leider nicht LinkedList<Workday>. Das wäre prinzipiell noch kein Problem, aber da hab ich zum ersten mal gemerkt, dass ich mit T.getInstance() (habe mir jeweils eine Methode in Day und Workday geschrieben, die eine Instanz der Klasse zurückgibt.) immer ein Day Objekt erstellt und ich somit immer nur Zufgriff auf Day und nicht auf Workday Methoden und Attribute habe.

	public MyCalendar() {
		calendar = new LinkedList<T>();
		@SuppressWarnings("unchecked")
		T toAdd = (T) T.getInstance(new GregorianCalendar());
		calendar.add(toAdd);
		it = new CalenderIterator<T>(this);
	}

Eine allgemein Frage die ich hätte:
Ein Upcast funktioniert problemlos von Workday auf Day.
Aber ein Downcast also von Day zu Workday wirft eine Exception. Wobei eigentlich, doch nur zusätzliche Attribute initialisiert werden müssen. Muss ich eine cast methode schreiben? oder wie kann ich da vorgehen?

Danke im Vorraus für Alles
habt Rücksicht, ist mein erstes Projekt^^

 

[Marco13]

Das casten von Day auf Workday kannst du vergessen, verallgemeinert würde das ja bedeuten, dass man von "Object" auf jede beliebige andere Klasse casten könnte, und alles "magisch" initialisiert wird. Wenn es kein Workday ist, dann ist es keiner.

EDIT: Man kann natürlich ein Workday aus einem Day erstellen, wenn man die Zusätzlichen Informationen mitgibt, z.B.

public Workday(Day day, float additionalInfo)
{
    this.bla = day.bla;
    this.blub = day.blub;
    this.additionalInfo = additionalInfo;
}

Meintest du sowas?


Der Rest... joa, so ganz hab' ichs nicht kapiert. Da steht wohl irgendwas mit

class MyCalendar<T extends Day> { ...}

?! Aber das mit dem T.getInstance sieht suspekt aus.... Kannst du ein KSKB posten?

 

[Julesy]

also ich habe mir nur eine getInstance Methode geschrieben, da ich mir sonst keine neue Instanz erzeugen kann. T() oder sonstiges geht nicht habe ich herausgefunden und wollte mir so behilflich sein.
erstmal nachschauen müssen was ein KSKB ist :-D
so hier ma schaun obs hier verständlicher ist^^

package KSKB;

public class Day {

	String out;
	
	Day(String outString) {
		out = outString;
	}
	
	public String toString() {
		return "Class Day -> " + out;
	}
	
	public static Day getInstance() {
		return new Day("tryDay");
	}
	
}

package KSKB;

public class Workday extends Day{

	String workOut;
	
	Workday(String outString) {
		super("doesn't matter");
		out = outString;
	}
	
	public String toString() {
		return "Class Workday -> " + out;
	}
	
	public static Workday getInstance() {
		return new Workday("tryWork");
	}
	
	
}

package KSKB;

import java.util.LinkedList;

public class Calendar <T extends Day> {

	LinkedList<T> cal;
	
	public Calendar() {
		cal = new LinkedList<T>();
		// jetzt soll hier ein Day bzw Workday erzeugt werden.
		// das soll abhängig davon sein, was bei <> übergeben wird
		// in diesem Fall also Workday
		T testday = (T) T.getInstance();
		System.out.println(testday); 
		// Class Day -> tryDay
		// Hier sollte eig stehen
		// Class Workday -> tryWork
		cal.add(testday); 
	}
	
	
	public static void main(String[] args) {
		Calendar<Workday> test = new Calendar<Workday>();	
	}
}

PS: das mit dem alternativen Konstruktor ist eine idee^^ werd ma schauen ob ich so weiterkomme^^

achja mein Ziel ist es eigentlich nur, eine Calendar Klasse zu haben, die nicht nur mit einer Art von Objekten also Day oder Workday zurechtkommt, sondern eben mit allen von Day erbenden Klassen. Hoffe, dass das klar wurde.

Gruß
Jules

 

[Michael...]

achja mein Ziel ist es eigentlich nur, eine Calendar Klasse zu haben, die nicht nur mit einer Art von Objekten also Day oder Workday zurechtkommt, sondern eben mit allen von Day erbenden Klassen.

Dann darf sie entweder nur in Day implementierte Methoden und Attribute nutzen oder muss jede Subklasse von Day kennen.

Im ersten Fall kann eine Befüllung der Kalenderklasse nur von "außen" vor genommen werden.

 

[Marco13]

Ahso OK ... Die getInstance-Methode ist static. Die kann also nicht polymorph verwendet werden. Es wird dort IMMER die von 'Day' aufgerufen. (Ehrlich gesagt war mir gar nicht bewußt, dass man auf Typparametern static-Methode aufrufen kann ).

Dieses Problem: "Ich muss Instanzen einer Klasse erstellen können, weiß aber nicht, von welcher Klasse" ist sehr allgemein (und mündet in letzter Konsequenz in Spring & Co :autsch: ). Aber für den "einfachsten" Fall gibt es für sowas das "Factory Pattern" - grob sowas wie

interface DayFactory<T extends Day>
{
    T create();
}

class SimpleDayFactory implements DayFactory<Day>
{
    @Override
    public Day create()
    {
        return new Day("day");
    }
}

class WorkdayFactory implements DayFactory<Workday>
{
    @Override
    public Workday create()
    {
        return new Workday("workday");
    }
}

public class CalendarTest <T extends Day> {
 
    LinkedList<T> cal;
    private DayFactory<T> factory;
    
    public CalendarTest(DayFactory<T> factory) 
    {
        this.factory = factory;
        
        cal = new LinkedList<T>();
        cal.add(factory.create());
        
        System.out.println("Created cal with "+cal);
    }
    
    
    public static void main(String[] args) {
        CalendarTest<Day> testDay = new CalendarTest<Day>(new SimpleDayFactory());   
        CalendarTest<Workday> testWorkday = new CalendarTest<Workday>(new WorkdayFactory());   
    }
}

Also im Prinzip ähnlich zu dem, was du schon mit dem getInstance vorhattest, aber eben über ein Interface und verschiedene Factory-Instanzen, weil nur so die Methode polymorph aufgerufen werden kann.

 

[Julesy]

ahh... thx für die schnelle schnelle Antwort.
also wenn ich das KSKB richtig verstanden habe, wird durch das Interface eben die create Methode von der WorkdayFactory aufgerufen, falls ich als Parameter im Kalender-Konstruktor eine Instanz der WorkdayFaktory übergebe?
Hatte schon die Idee mir einfach ein Beispiel Objekt im Konstruktor zu übergeben, aber hab es dann nicht hinbekommen die Klasse der Instanz zu bestimmen.
Aber dann werde ich den Lösungsvorschlag implementieren. thx @Marco

Allerdings hätte ich allgemein gedacht, dass es eine elegantere Möglichkeit gibt.

Zu meiner Frage von oben: Ist es sinnvoll jetzt mit einem Iterator Tage erzeugen zu lassen?
Wie sollte ich bei einem Kalender vorgehen, erstmal einfach von 2010 bis irgwann Tage erzeugen lassen und bei Bedarf weitere oder immer wenn auf ein Tag, der noch nicht vorhanden ist, gezeigt wird, den Iterator einen Tag erzeugen lassen (also anfangs mit nur einem Tag beginnen) oder immer Tage 5 Jahre im voraus parat haben...

Gruß
Jules

##@@Edit:
Mir ist grad noch die Idee gekommen, dass ich auch einfach eine wiederverwertbare Klasse erzeugen könnte, wenn ich einfach einen Konstruktor bei der Day Klasse implementiere, der es erlaubt ein Content-Objekt zu übergeben und diesen intern als public deklariert. So könnte ich jedem Tag, falls erwünscht, ein Attribut bzw auch eine ganze Collection übergeben und intern speichern, was ja der Grundgedanke war.

 

[Marco13]

Ob das mit dem Iterator sinnvoll ist, ist schwer zu sagen... Es klingt erstmal... "interessant", aber ... eskommt in erster Linie darauf an, was du mit diesen Days dann genau machen willst. Eigentlich "hat" ein Kalender ja unendlich viele Tage. FALLS ich das jetzt richtig verstanden habe, geht es ja daraum, dass zu ZU jedem Tag irgendwelche weiteren Informationen speichern willst (z.B. bei einem Arbeitstag die Arbeitszeit). Oder besser: Eben nicht "ZU jedem" Tag (weil es davon ja unendlich viele gibt) sondern zu einer bestimmten Menge von Tagen. Wenn dieser Kalender also z.B. einen Arbeitsplan repräsentieren soll, klingt das eher, als hätte er die Funktion einer Map ... Beschreib' vielleicht nochmal genauer, was du vorhast.

 

[Julesy]

also es soll später eine Art Schichtplaner werden.
vermutlich sollte ich mit Datenbanken arbeiten, aber wollte es vorerst mit Objekten versuchen.

Ich hatte mir das so gedacht:
Ich habe eine Klasse Person bei der ich eine Liste mit den Schichten habe. Zusätzlich habe ich bei jedem Tag eine Liste Schicht bei der ich die Person vermerke. Ist von Prinzip her doppelt gemoppelt, aber glaube ich von der Zugriffzeit her am schlausten.
Gibt es eine elegantere Variante?

Frage:
Habe nun schon mal mit einer Calendar Gui begonnen und mir mit dem GridBagLayout einen Calendar erstellt.
Nun geht es darum, die tableCells mit dem Inhalts zu füllen. Also day.toString().
Habe es zZ so gelöst, dass ich ein Array mit den Tagen in meiner Gui speichere und mir immer das KalenderArray des aktuellen Monats übergebe. Hier auch wieder die Frage wie es denn besser geht^^


Gruß
Jules

 

[Volvagia]

Ich hab nen Kalendar vor kurzen so geschrieben:

private static final String[] WEEKDAY_NAMES = {
		"Montag",
		"Dienstag",
		"Mittwoch",
		"Donnerstag",
		"Freitag",
		"Samstag",
		"Sonntag",
};

private void createGui(int month, int year, Map<CalendarDate, Event> map)
{
	removeAll();
	addHeader();
	
	int weekDayOfFirstDay = getWeekday(1, month, year);
	byte fieldCounter = 0;		
	
	for(byte b = 1; b < weekDayOfFirstDay; b++, fieldCounter++)
		add(createEmptyLabel());

	GregorianCalendar calendar = new GregorianCalendar(year, month - 1, 1);
	int daysInMonth = calendar.getActualMaximum(GregorianCalendar.DAY_OF_MONTH);

	for(byte b = 1; b <= daysInMonth; b++, fieldCounter++)
		add(new DateButton(b, month, year, map));
	
	for(byte b = fieldCounter; b < 42; b++)
		add(createEmptyLabel());
	revalidate();
}
public void addHeader()
{
	for(byte b = 0; b < WEEKDAY_NAMES.length; b++)
	{
		JLabel label = new JLabel(WEEKDAY_NAMES[b]);
		label.setHorizontalAlignment(SwingConstants.CENTER);
		add(label);
	}
}

Ist vielleicht nicht das Schönste, aber läuft schnell genug ab, dass eine Verbesserung vermutlich keine sichtbare Leistungssteigerung bringt. (Ich erkenne nämlich keine sichtbare Verzögerung trotzdem kompletten EDT.)
Basiert auf GridLayout(0, 7, 5, 5).

 

[Julesy]

kk. ich denke ich sollte auch eine map benutzen
kannst du ma ein bild von deiner gui uppen? hast du comboBoxes für monate? oder wie hast du das gelöst?

bei mir siehts noch so aus:

noch net so toll aber ich hoffe es wird^^

Gruß
Jules

 

[Volvagia]

Geheime Top Secret Aufnahme meines neuesten Programmes, von dem der Kalendar warscheinlich weniger als 1 % ausmacht. (Ein wenig angeben muss sein. )

Ich würde dir aber dringend davon abraten, das GridBagLayout zu verwenden. Es ist wirklich sau schwer. Die selben Erfolge kannst du grundsätzlich mit Boxen und eventuell Kombo mit ein paar anderen Managern machen. Der Nachteil ist, dass du für eine GUI manchmal recht viele Boxen brauchst, was den Code verkomplizieren kann, alleine schon beim Namen suchen. Aber es ist auf jeden Fall besser, als sich mit dem GBL herumzuschlagen.

 

[Julesy]

muss sagen, ich persönlich fand jetzt GBL recht angenehm für meine Zwecke.
ich wollte eben links eine Sidebar haben, die nicht so groß sein sollte wie die Tabellenbreite.
ich hatte erst zwei Container: einen links mit GL eben mit der einen Width und noch einen Container wieder mit GL
mit der Tabellen Width. dann hatte ich die beiden Container mit FlowLayout nebeneinander gestellt.

jetzt mit GBL ist es meiner Meinung nach wesentlich übersichtlicher. Aber hab auch beim Einlesen gemerkt,
dass es kein triviales thema ist^^

 

[Marco13]

Was machst du eingentlich mit dem GridBagLayout (Totally Gridbag – madbean ). Das bisherige wäre ein GridLayout für den Kalender, und ... das da links... wird ja wohl ohnehin noch mehr...

 

[remy]

Was machst du eingentlich mit dem GridBagLayout (Totally Gridbag – madbean ). Das bisherige wäre ein GridLayout für den Kalender, und ... das da links... wird ja wohl ohnehin noch mehr...

Erst mal: geiles Video

es zeigt, was für ein großer Mehraufwand bzw. wie viele Zeilen an Code mehr entstehen. Erst kürzlich durfte ich wieder die Erfahrung machen, wie schnell und einfach eine GUI mit allen anderen Layouts gebastelt werden kann...
Nur leider stößt man da irgendwann an gewisse Grenzen, wenn man nicht mehr weiß, wie man Grid, Flow und Border-Layout verschachteln soll, um halbwegs an eine komplexe GUI nach seinen Vorstellungen zu kommen. Wie auch im Video sehr gut demonstriert wurde: verändert man die Größe oder aber ein Textfeld vergrößert sich ein wenig durch z.B. einer ScrollPane, ist das Programm nicht mehr nutzbar. Für fixe, koplexe Layouts, die für immer und ewig feststehen sollen, ist es dennoch eine gute Alternative.

 

[Marco13]

Naja, es gibt immer wieder sehr ... "spezielle" Anforderungen. Teilweise sehr, sehr, sehr spezielle, gerade in bezug auf's GUI ("Wie macht man ein Toolkit dessen Hintergrund einen Farbverlauf hat?", "Wie kann man ein Smiley auf dem Knopf einer JScrollbar zeichnen" :autsch: :joke: ). Aber in den ALLERmeisten Fällen tut's eine relativ einfache Verschachtelung von Border, Grid, Box und ggf. Flow. Es gibt IMHO nur EINE "übliche" Sache, für die ich das GridBagLayout verwenden würde - nämlich sowas wie

----------------------------------------------------------------
| Label               |   TextField       | Button             |
| LabelWithLongText   |   TextField       | Button             |
| Label               |   TextField       | ButtonWithLongText |
----------------------------------------------------------------

EDIT: Sowas wie Layout Manager Showdown: We have results! | Java.net kann man sich aber mal ansehen, wenn man die angedeuteten speziellen Anforderungen an Layouts hat.