Applet-Programmierstil. Gut oder schlecht?

Status
Nicht offen für weitere Antworten.

msd

Mitglied
Hallo zusammen,

ich hab ein signiertes Applet programmiert und wollte von euch eure Meinung dazu wissen.
Ich bin nach der Idee "Hauptsache es Funktioniert" vorgegangen und habe mir nicht so viele Gedanken über
"guten" objektorientierten Programmierstil gemacht. Ich habe der Einfachheit halber ereignisgesteuert alles in einer Klasse realisiert.
Ist dieser Programmierstil für die Programmierung von Applets in Ordnung oder sollte man die Anwendung objektorientierter mit mehreren Klassen programmieren?
Wenn ja, würde mich vor allem interessieren was der Vorteil/Nachteil von mehreren Klassen im Vergleich zu meiner Lösung sein soll.

Das Applet leisten folgendes:
1. Daten per JDCB auf Oracle-Datenbank suchen und in Textfeldern anzeigen.
2. Abgerufene Daten auf Wechseldatenträger oder Festplatte speichern
3. Daten können per Hand in die Textfelder eingegeben und ebenfalls gespeichert werden.
4. Verzeichnis "Daten" inkl. Dateien kann auf einem Wechseldatenträger gelöscht werden.

Vielen herzlichen Dank
Gruß Mike


Code:
import java.awt.*;
import java.*;
import java.awt.event.*;
import java.io.*;
import java.util.*;
import java.security.Key;
import java.sql.*;
import java.awt.Font;
import java.net.URL;
import java.net.URLConnection;
import java.net.MalformedURLException;
import java.applet.*;
import javax.crypto.Cipher;
import javax.crypto.CipherInputStream;
import javax.crypto.spec.SecretKeySpec;
import javax.swing.*;
import javax.swing.border.Border;
import javax.swing.border.LineBorder;
import javax.swing.border.TitledBorder;
import javax.swing.filechooser.*;
import javax.swing.filechooser.FileFilter;
import javax.swing.text.*; 
import javax.swing.undo.*;
import javax.swing.event.*;
import sun.misc.BASE64Decoder;
import sun.misc.BASE64Encoder;

public class myApplet extends JApplet
{
		private static final long serialVersionUID = 1L;
	private JFrame frame;

	private JPanel jPanel1;
	
	private JTextField jTextField1;
	private JTextField jTextField2;
	private JTextField jTextField3;
	private JTextField jTextField4;
	private JTextField jTextField5;
	private JTextField jTextField6;
	private JTextField jTextField7;
	private JTextField jTextField8;
	private JTextField jTextField9;
	private JTextField jTextField10;
	private JTextField jTextField11;
	private JTextField jTextField12;

	private JLabel jLabel13;
	private JButton suchButton;
	private JButton speichernButton;
	private JButton neuButton;
	private JTextField eingabeFeld;
	
	private JMenuItem  mi0;//Neu
	private JMenuItem  mi1;//Öffnen
	private JMenuItem  mi2;//Suchen
	private JMenuItem  mi3;//Speichern unter...
	private JMenuItem  mi4;//Speichern auf SD
	private JMenuItem  mi5;//Beenden
	private JMenuItem  mi6;//Rückgängig
	private JMenuItem  mi7;//Wiederholen
	private JMenuItem  mi8;//Ausschneiden
	private JMenuItem  mi9;//Kopieren
	private JMenuItem  mi10;//Einfügen
	private JMenuItem  mi11;//Wechseldatenträger löschen
	private JMenuItem  mi12;//Hilfe
	private JMenuItem  mi13;//Info
	private JMenuItem  mi15;//Alles markieren
	private JMenuItem  mi16;//Löschen

	public void init() {
		initGUI();
	}
	
	public void start(){
		..
	}
	//Instanzierung der Componenten
	private void initGUI() throws Exception {
		..
	}
	
	//Methode erzeugt PopUp Menu beim Klick auf Textfelder mit Kopieren, Ausschneiden, Löschen
	private void pop(final JTextField t1) {
	..
	}
	
	//Methoder Liefert alle Wechseldatenträger des Clientrechners
	private Vector getDrives (Vector laufwerke){
	..
	}
	
	//Methode zum entschlüsseln der Oracle Zugangsdaten. Diese sind serverseitig hinterlegt.
  private byte[] decode( InputStream is, String pass ) throws Exception { 
	   ..
	} 
  	
  //Methode FileInputStream etc. zum Auslesen einer Datei und Anzeige in den Textfelder.
  private void readFile(File datei){
	..
	}
	
	//Methode FileOutputStream etc. zum Speichern des Inhalts der Textfelder
  private void writeFile (File datei){
		..
	}
		//Methode zum Suchen der Daten mit JDBC-Schema: getConnection, executeQuery etc. und Anzeige in den Textfeldern.
		//Liest config-File auf dem Webserver aus und ruft decode() auf, um Datenbankpasswörter zu entschlüsseln.
    private void doJDBC () {
   ..
	}     
	
	//Methoder zum Anzeigen aller Wechseldatenträger und Löschen des Verzeichnisses DATEN auf den Wechseldatenträgern
	//Ruft getDrives() auf und löscht Verzeichnis Daten rekursiv.
	private void doDeleteSD (){
	 .. 
	}

	//Methode zum Anzeigen von JFileChooser und Auslesen der ausgewählten Datei. Ruft readFile() auf.
	private void doOpenFile (){
		..
	}
	
	//Methode zum Anzeigen von JFileChooser und Speichern in eine Datei auf der Festplatte. Ruft writeFile() auf.
	private void doSaveAs (){
	..
	}
	
	//Methode zum Anzeigen aller Wechseldatenträger, anschliesssender Speichervorgang. Ruft getDrives(), writeFile() auf.
	private void doSaveUSB (){	
	..
	}
	
	//Methode zum Löschen der Textfelder
	private void doNew () {
	..
	}
	
	//Innere Klasse um Eingabe in die Textfelder zu begrenzen
	class JTextFieldLimit extends PlainDocument {
   ..
	}
	
	//ActionListener für die Componenten (JMenuItem) als innere Klasse 
	class MyActionListener implements ActionListener {
		public void actionPerformed(ActionEvent ae)
		{
			..
	}
	}
	
}
 

The_S

Top Contributor
Bei einem kleinen Applet bzw. einem kleinen privaten Projekt, kann man sicherlich auch mal das eine oder andere Auge zudrücken, wenn die OOP über Board geworfen wird. Aber generell sollte man OOP schon nutzen und verwenden - dafür gibts die ja.

Vorteile findest du z. B. hier http://www.wer-weiss-was.de/theme9/article2692226.html . Es wäre wohl übertrieben hier alle aufzulisten ;) .
 
G

Gast

Gast
Ich würde an deiner Stelle versuchen möglichst OO vorzugehen, bei jedem Projekt. Auch wenn es bei kleinen Projekten durchaus länger dauern kann als prozedurale Programmierung.
Grund: Du bekommst ein Gefühl für die OOP , und kannst, falls du ein mittelgroßes bis sehr großes projekt starten willst, gleich deine OO erfahrung ausnutzen!
auf der anderen Seite könntest du teile dieses Applets auch wieder in neuen Applets verwenden mit OOP. zB deine Speicherfunktion welche du Kapseln könntest.
 

stevieboy

Aktives Mitglied
Und noch ein Tip von mir: Deine 17 Menuitems & 12 Textfields solltest Du für bessere Lesbarkeit lieber direkt mit brauchbaren Namen versehen (wie alle anderen Variablen auch). Durch Code-Vervollständigung moderner IDEs ist eine kurze Schreibweise nicht mehr nötig und daher wirst Du es - gerade in umfangreicheren Projekten - zu schätzen wissen, wenn Du einer Variablen direkt ansehen kannst wofür sie steht.

Ansonsten schließe ich mich der allgemeinen Meinung an und plädiere für OOP auch im kleinsten Projekt. Dann hat man die nötige Übung und Denkstrukturen bereits,wenn ein großes Projekt ansteht.
 

EgonOlsen

Bekanntes Mitglied
Wildcard hat gesagt.:
Du darfst keine Klassen aus den sun.* Packages verwenden!
Stimmt natürlich im Prinzip, aber im Falle von BASE64 gibt es in Java leider nichts anderes. Der RFE ist ja auch erst 8 Jahre alt (Link), man scheint dort Zeit zu haben. D.h. man muss ihn selber bauen, irgendwas opensourciges nutzen oder eben sun.* nehmen. Das bleibt zwar gammel, aber diese Nutzung ist so weit verbreitet, dass SUN es sich gar nicht leisten kann, das zu ändern...sun.* hin oder her.
 

EgonOlsen

Bekanntes Mitglied
stevieboy hat gesagt.:
Ja, zum Beispiel. Wobei ich es eher selber bauen würde, als mir noch ein zusätzliches Jar nur dafür ans Bein zu binden, aber das ist Geschmackssache. Das eigentliche Problem ist, dass SUN diese Funktionalität nicht in Java direkt aufnimmt. Mit jeder neuen Version kommen die absurdesten Dinge hinzu und dieses Basic fehlt nach wie vor...verstehe ich nicht.
 

stevieboy

Aktives Mitglied
Ja, Du hast natürlich recht.

Aber ich wollte nur einmal wieder auf die Commons hinweisen, da viele Programmierer "sinnlos" Zeit damit verbringen Probleme zu lösen, die bereits verwendungsfähig gelöst sind.
 
Status
Nicht offen für weitere Antworten.
Ähnliche Java Themen

Ähnliche Java Themen

Neue Themen


Oben