Besoin de conseils sur la conception de la classe

Question

Je suis censé écrire un système de réservation de cinéma simple, qui permet à un client de faire des réservations pour des films. Le cinéma se compose de différents théâtres, avec différentes places, prix et horaires de cinéma. L'utilisateur doit pouvoir entrer son nom et d'autres informations d'identification, puis effectuer des réservations pour 1 film ou plus. Une fois la réservation terminée, le système doit générer un reçu, indiquant son nom, le (s) film (s), le (s) horaire (s) et le numéro de réservation.

J'ai essayé de suivre les principes OOP au mieux de mes capacités actuelles.

Les classes I ont mis en place serait la suivante:

• CinemaBooking -> entrypoint dans programm
• Chambre -> reçoit sa taille assise par [suite] [col]
• Film - > a movietitle, shwotime, la salle et un prix.
• client -> qui devraient stocker toute information d'utilisateur comme le nom, l'email et téléphone et générer
  numéro de réservation

Je suis un peu incertain sur l'endroit où placer l'utilisateur-i/o dans ce cas: Shoud il rester dans CinemaBooking, ou devrais-je générer une classe séparée qui ne fait que l'E/S? Ou devrais-je simplement déplacer tout le matériel d'E/S vers une autre classe (par exemple la classe client)?

Answer 1

Il y a beaucoup de conseils à donner, je donnerai seulement le plus important. Tout d'abord, l'idée principale de la POO était de s'adapter au monde réel, il est donc préférable de rendre vos classes aussi proches que possible des objets réels. Créer une classe Réservation qui sera juste l'équivalent d'un billet, pas un point d'entrée pour un programme. C'est à dire. il contiendra des informations sur l'utilisateur, le théâtre, le siège et le coût. Créer une classe Théâtre qui contiendra le nombre de sièges (pas de rangées x cols - certains sièges peuvent être réservés, d'autres peuvent être cassés, et certains théâtres n'ont tout simplement pas de structure au carré). Sinon, comme un théâtre peut avoir plusieurs salles, vous pouvez créer une salle de classe, qui aura des «sièges» de propriété, puis ajouter des salles au théâtre. Créer aussi classe Movie. Les films et les salles se réfèreront les uns aux autres: le film contiendra la liste des théâtres dans lesquels il est présenté, et le cinéma aura la liste des films qu'il montre. Ensuite, créez une classe Seance, qui contiendra l'heure et le film. Créer un client de classe uniquement dans le cas où vous travaillerez avec ce client plus tard et que vous souhaitez sauvegarder ses attributs (nom, historique des réservations, etc.). Sinon, cela n'a aucun sens de créer une classe de plus. Ceci est votre modèle. Les cours peuvent très légèrement, mais si vous avez une idée de base, ce ne sera pas un problème. Deuxièmement, créez une classe BookingSystem qui résumera les fonctionnalités de toutes les classes précédentes. Ce sera une implémentation de Facade design pattern, et cela simplifie vraiment l'accès à votre sous-système de réservation. Troisièmement, créez une classe distincte pour le travail d'E/S. Jamais ne met les E/S au service des classes du modèle. Imaginez que votre système de réservation de cinéma fasse partie d'un autre système doté de ses propres E/S - vous devrez redessiner tout votre code pour recevoir des données de couches supérieures. Donc, faites juste une classe séparée pour l'entrée de l'utilisateur et la sortie du programme. Et ce sera votre voir.

Enfin, créez la classe de programme principale. Vous pouvez donner le même nom au programme lui-même de quelque chose comme ça. Celui-ci contrôlera simplement le flux du programme de la vue aux modèles et retour. Donc, cette partie est appelée contrôleur, et l'idée générale est connue comme Model-View-Controller pattern.

Answer 2

Écrire des méthodes toString() sur toutes les classes. Inquiétude à propos de l'E/S plus tard. Obtenez les bonnes relations d'abord. Les E/S sont le moindre de vos soucis.

Answer 3

Chaque fois que je fais la classe, il a la suite en elle: -

1. Toutes les variables d'instance comme privées.

2. Implémenter des getters et des setters.

3. Implémente la méthode toString().

Si vous utilisez Eclipse, cela vous aidera à implémenter ces méthodes automatiquement. Il suffit d'écrire les variables d'instance, faites un clic droit dans l'éditeur -> Source -> Générer des getters et des setters.

Answer 4

En fait, le ticket ne contiendra pas d'informations sur le siège ou le coût du poste. Il contiendra références à d'autres objets: Utilisateur, Théâtre, Siège.

Vous aurez besoin d'une classe de type "manager" o0ne qui contiendra le reste du programme: BookingApp qui a un main() pourrait l'être. Je suis d'accord ne vous inquiétez pas tellement à propos de l'interface pour le moment - mais ne pas imprimer sur le terminal à partir de classes de domaine. Utilisez toString() pour tester le contenu de l'objet, mais la méthode main() doit appeler getters sur les autres classes et créer la sortie. Très mauvaise idée et la forme d'avoir des classes de domaine écrit directement dans l'interface utilisateur. Ainsi, vous avez le théâtre, l'utilisateur, le siège, le billet, le prix. Considérez les dépendances. Le siège est lié au théâtre et le prix est basé sur le théâtre et le siège, je suppose. Commencez par les choses, et tracer des lignes entre elles pour montrer comment elles vont communiquer ou se référencer mutuellement. Par exemple, si vous avez un utilisateur, retrouvez tous vos billets - à partir du siège de recherche de billets et du théâtre de recherche de sièges. Ensuite, ajoutez les attributs (private comme dit JavaGeek). Commencez petit. Peut-être juste des théâtres et des sièges. Mettez ça au travail puis ajoutez le prochain cours. Ajoutez à votre conception de manière incrémentielle et itérative. N'essayez pas d'écrire et de compiler le tout à la fois. Je suggère le livre Java Design de Peter Coad (très bon marché et très bon) comme une bonne introduction à la conception de Java.