Trick für Compilerfehler bei fehlendem Interface

[nocturne]

Hallo,

ich habe eine Abstrakte Klasse AClass, jede konkrete Klasse soll sich jetzt entscheiden ob sie das Interface "IgnoreExceptions" oder das Interface "ReportExceptions" implementiert.

Gibt es da ein Trick einen Kompilerfehler zu generieren wenn beide oder keins der Interfaces implementiert wurden?

 

[Gonzo17]

Bin mir nicht sicher, ob dir das weiterhilft, aber vielleicht sowas? Eclipse: Eigene Compiler Fehler generieren und anzeigen mit Annotation Processors @ tutorials.de: Tutorials, Forum & Hilfe

 

[XHelp]

Ich denke nicht. Hört sich aber auch irgendwie komisch an. Was genau willst du denn erreichen?

 

[nocturne]

In einem Mehrschichtigen Framework soll der Client sich auf einen Server verbinden. Der Client soll entscheiden ob die SB auf die Konsole Loggen soll. Ebenso soll die SB entscheiden, unabhängig davon was der Client will, ob der Client die Exceptions, die währen der SB-Verarbeitung erhält übermittelt und dargestellt bekommen soll.

Üblicherweise soll die SB gezwungen werden sich zu entscheiden ob der Client den Fehler übermittelt bekommen soll, das soll aber nicht in den Konstruktor als Parameter aufgenommen werden (Die sessoins leben extrem kurz), sondern als Interface.
Hier die SB

package de.enexus.dbm;

import java.sql.Connection;
import java.sql.ResultSet;
import java.sql.Statement;

import org.postgresql.Driver;

import com.enexus.delphi.ActionSB;
import com.enexus.delphi.Loop;
import com.enexus.delphi.RecordAbsoluteValue;
import com.enexus.delphi.ReportExceptionsToClient;
import com.enexus.delphi.stream.records.StringConverterImpl;

public class Profiles extends ActionSB implements ReportExceptionsToClient {

	@Override
	public Loop runProcess() throws Exception {
		Driver d = new Driver();
		percent = 0;

		Connection c = d.connect(getString("databaseurl"), null);
		percent = 10;

		Statement stmt = c.createStatement();
		stmt.execute("SELECT profileid, name FROM profiles");
		percent = 20;

		final ResultSet rs = stmt.getResultSet();
		int i = 0;
		percent = 30;

		clear();
		percent = 40;

		while (rs.next()) 
			putAbsoluteValue(i++ + "", new RecordAbsoluteValue() {
				long id = rs.getInt(1);

				@StringConverterImpl.Length(32)
				String name = rs.getString(2);
			});
		
		percent = 100;
		return Loop.Terminate;
	}

	@Override
	public String getRequireKey() {
		if (!containsKey("databaseurl"))
			return "databaseurl";
		return null;
	}
}

 

[Antoras]

Wie entscheidet denn der Client / Server sich? Also anhand von welchen Kriterien macht er das was er macht? Das geschieht ja wohl nicht zufällig, sondern anhand von vordefinierten Kriterien.

Und genau dort ist der Punkt, an dem du ansetzt. Nachdem eine Entscheidung gefällt wurde wie die Software weiter verfährt wählt sie eine konkrete Klasse aus und injected sie dem System, mittels Dependency Injection. Der Client / Server kennt dabei nur das Interface und ruft dessen Methoden auf, sie müssen also gar nicht wissen was konkret passieren wird.

 

[nocturne]

Hab ich falsch beschrieben, es gibt keine entscheidung zur Laufzeit. Das Interface ist entscheidend.

 

[DerEisteeTrinker]

Wenn der Programmierer das falsche Interface benutzt, dann ist er selber schuld. Da würde ich im Vorfeld Vereinbarungen festlegen bzw. in den JavaDocs (die es hoffentlich gibt) erklären welches Interface wann zu benutzen ist.

 

[XHelp]

Ich würde es auch mit nur einem Interface machen und nur die Implementierung austauschen. Wenn der Benutzer die Log-nachrichten sehen will, dann zeigt die Implementierung das an. Wenn der Benutzer die nicht sehen will, dann laufen die ebens ins Nirvana

 

[fastjack]

Wie sieht es denn aus, wenn Du eine eigene Exceptions definierst, und denen einen Typen gibts, z.B. Warning, Error etc. Die ActionSB geben nach ihrer eigenen Entscheidung (je nach Schwere oder so) diese Exceptions zurück und der Client behandelt diese einfach entsprechend nach Warning/Error usw.

 

[nocturne]

@DerEisteeTrinker
Das ist genau der Ist-Stand.

@XHelp
Guter Ansatz ... die ActionSB leitet jedoch von LinkedHashMap ab (deswegen das clear() ab 40%).

@fastjack
Guter Ansatz, aber wie gehe ich sicher dass nicht eine RTE geworfen wird?


Ich dachte auch schon daran den ActionSB mit Generics auszustatten... da die generics nicht obligatorisch sind würden faule Programmierer sie einfach weg lassen.

public abstract class ActionSB<AB extends Throwable> extends AbsoluteValueTreeMap implements Runnable {
...
public abstract Loop runProcess() throws AB;
...
}

 

[DerEisteeTrinker]

Was ist an dem Ist-Zustand so schlimm? Ich persönlich mach mir mit sowas nicht selber Streß. Wenn der andere Programmierer zu bl*piep* ist, das Interface zu benutzen, dann kann ich das auch nicht ändern. Schließlich kann ich mich auch nicht um jeden umgefallenen Sack Reis in China kümmern.

 

[fastjack]

Wie sieht es denn aus, wenn Du dem Programmierer die Verantwortung über die Ausgabe der Exceptions völlig abnimmst und an zentraler Stelle einfach entscheidest, welche ActionSB Exceptions weiterleiten kann und welche nicht. Diese Entscheidung kommt in die Klasse, die die ActionSB's ausführt. Der Nachteil daran ist die Konfiguration der sache, Vorteil ist, der Programmierer kann nix vergessen.

 

[Wildcard]

Eine eigene Annotation scheint mir hier sinnvoller als ein marker Interface...