opazke
-
Ime class je ponavadi bolj poimenljivo, ne kratice SR
-
Classi, ki implementirajo vmesnike ali, ki extendajo druge potem, metodam, ki implementirajo ali overridajo damo anotacijo @OverRide(metodi run, serialEvent)
-
konstruktor SR1:
- če je SerialPort port zaseden bi verjetno bilo smiselno zapreti program, skrtka nič ne narediš ko se zgodi PortInUseException
- če ne dobiš InputStreamport zaseden bi verjetno bilo smiselno zapreti program, skrtka nič ne narediš ko se zgodi IOException
- konstruktor je ponavadi namenjen, da classu podaš neke vrednosti za properties, ne pa da ima logiko kaj vse naredi
- tudi v konstruktorju da se sklicije na samega sebe, kot celotni class ni najboljša prakasa(serialPort.addEventListener(this))
-
tudi v konstruktorju odpreti Thread ni najboljša praksa
-
metoda disconnect bi lahko lovila IOException ne pa generalni Exception
-
metoda writeToPort ob IOException ne vemo nič kaj je šlo narobe
-
metoda initWriteToPort podobno kot konstrukor ne naredi nič ob IOException
-
metoda serialEvent zelo čudno uporabljen switch, case, break. Načeloma ima vsak case breake, razen če hočemo da za več enakih naredi isto komando
-
metoda updatePorts skrivanje spremenljivke portId, ki je že definirana na globalni ravni class-a, to ni najboljša praksa
-
metoda launchSR1 naredi instanco SR1 in potem se z spremenljivko reader nič ne zgodi. Tukaj bi bilo bolje konstruktor nekaj osnovnih init parametrov, potem pa na tej instanci kličemo recimo init metodo, ki proba odpreti port, strem, listner, Thread, ...
-
metoda run ima neskončni loop in potem še Thread sleep. Interface Runnable jedrugače namenjen
tole bolj kot psevdo koda:
public void startMyThread() throws InterruptedException {
Object requiredObject = new Object(); //Map/List/OwnClass
Thread myThread = new Thread(new MyRunnable(requiredObject), "SimpleReadThreadApp");
myThread.start();
System.out.println("doing");
}
class MyRunnable implements Runnable{
private final Object requiredInput;
public MyRunnable(Object requiredObject) {
this.requiredInput = requiredObject;
}
@Override
public void run() {
// do staff with requiredInput
// do business logic
}
}
Zaključek
- koncepti extend, implements, Override
- potrebno boljše handlanje Exception
- koncepti konstruktorja, privatni properties, privatne in public funkcije
- mešanje statičnih funkcij in public funkcij instance, potem v gui class-u
Drugače zanimivo, da si se tega lotil, ampak konceptualno mi je čudno zasnovano
Kako bi jaz zasnoval
GUI program je osnovni:
- inicializira swing zadeva: paneli, besedila, navodila ...
- naredi instanco SR1 z osnovnimi parametri
- na instanci naredi inicializacijo za čitanje na serijskem portu
- SR1 v svojim metodah meče exceptione, ki jih GUI lovi in se odloči kaj bo prikazal uporabniku
opazke
Ime class je ponavadi bolj poimenljivo, ne kratice SR
Classi, ki implementirajo vmesnike ali, ki extendajo druge potem, metodam, ki implementirajo ali overridajo damo anotacijo @OverRide(metodi run, serialEvent)
konstruktor SR1:
tudi v konstruktorju odpreti Thread ni najboljša praksa
metoda disconnect bi lahko lovila IOException ne pa generalni Exception
metoda writeToPort ob IOException ne vemo nič kaj je šlo narobe
metoda initWriteToPort podobno kot konstrukor ne naredi nič ob IOException
metoda serialEvent zelo čudno uporabljen switch, case, break. Načeloma ima vsak case breake, razen če hočemo da za več enakih naredi isto komando
metoda updatePorts skrivanje spremenljivke portId, ki je že definirana na globalni ravni class-a, to ni najboljša praksa
metoda launchSR1 naredi instanco SR1 in potem se z spremenljivko reader nič ne zgodi. Tukaj bi bilo bolje konstruktor nekaj osnovnih init parametrov, potem pa na tej instanci kličemo recimo init metodo, ki proba odpreti port, strem, listner, Thread, ...
metoda run ima neskončni loop in potem še Thread sleep. Interface Runnable jedrugače namenjen
tole bolj kot psevdo koda:
Zaključek
Drugače zanimivo, da si se tega lotil, ampak konceptualno mi je čudno zasnovano
Kako bi jaz zasnoval
GUI program je osnovni: