1.5 KiB
-
En interface som alla typer av instruktioner kan ha gemensam borde inte vara helt fel. Vilket i sin tur betyder en klass för varje instruktion där ett instruktions interface implementeras.
-
Man ärver lämplig collection, ex arraylist. Detta är kass design, då komposition är tydligare.
-
"Program" och självaste "datorn" borde vara olika paket, paketet "program" rör program som skall köra på datorn, "datorn" har de klasser som är datorn som t.ex. memory och programCounter osv.
-
Varje instruktion skulle kunna representeras som ett kommando, och datorn skulle utföra dessa kommandon utan att behöva veta exakt vad varje instruktion innebär. På så sätt separeras ansvar, och det blir enklare att lägga till eller ändra instruktioner i framtiden.
-
Designmönstret Template Method kan vara användbart för att undvika duplicerad kod i likartade klasser, särskilt för de instruktionsklasser som ingår i programmet (t.ex. Copy, JumpEq, Mul, Add, Print, Halt). Eftersom dessa instruktionsklasser kan ha vissa gemensamma delar i hur de utför sin uppgift, kan ett template method-mönster användas för att abstrahera och återanvända gemensam kod.
-
För att hantera olika sorters operander på ett enhetligt sätt med hjälp av Strategy-mönstret i en datormodell skulle man kunna implementera olika strategier för hur operander ska hanteras. Operander kan vara antingen konstanter eller adresser, och olika instruktioner kräver olika typer av operander.
-
Additionen bör nog utföras i LongWord.