In una strategia di fase di progettazione OOP,
Qualsiasi oggetto fisico / concettuale di un sistema può essere modellato (considerato) come oggetto computazionale nel programma progettato da OOP in base a due condizioni seguenti:
First case: That physical/conceptual object of a system must have it's local state and that state changes over time.
o
Second case: that physical/conceptual object of a system may or may not have it's local state but that same object must influence the state of other physical/conceptual object of a system through interactions.
Anche sopra due casi sono supportati qui , che dice: Viewing objects as finite state machines
Per illustrare sopra due casi, di seguito è riportato il diagramma object model e class diagram del gioco di lancio delle monete.
class Coin e class Player digita oggetti, hanno lo stato locale coinOption , come menzionato in primo caso . class CoinGame tipo oggetto non ha stato locale ma influenza lo stato di altri oggetti (di tipo Player e Coin ), come menzionato in secondo caso .
Comepersecondocaso,l'oggettotipoclassCoinGameinfluenzalostatodialtrioggettiditipoPlayereCoinattraversoleinterazionisotto,maclassCoinGametipooggettostessononhalocalestatosuproprio.
Quindi, class CoinGame non mantiene nessuno stato locale e ha composite relazione con Player e Coin , come da codice java sotto.
public class CoinGame {
Player[] players = new Player[2];
Coin theCoin = new Coin();
CoinGame(String player1Name, String player2Name){
players[0] = new Player(player1Name);
players[1] = new Player(player2Name);
}
.....
}
Questo è il codice completo in java. Sopra due casi sono validi, quando selezioni oggetti dal mondo reale. La mia comprensione è corretta?