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
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:
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: