Java: verantwoordelijkheid klasse of GUI?

Pagina: 1
Acties:

Onderwerpen

Vraag


Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Ik ben bezig met een simpele opdracht in Java waarbij een telefoonteller gemaakt wordt. In de uitwerking staat dat de klasse de totale kosten bijhoudt. Klassendiagram van de uitwerking:

Telefoonteller
int gebeldeMinuten
double totaleKosten
double basistarief
double perMinuut

int getGebeldeMinuten()
double getTotaleKosten()
double bel (int)

GUI:
Afbeeldingslocatie: http://i64.tinypic.com/98arur.jpg

Mijn oplossing was deze:
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
package oefeningen;

/*
 * deze klasse houdt de gesprekskosten bij
 */

public class Telefoonteller {
  private int aantalMinuten = 0;
  private double kosten = 0.0;
  private static double basistarief = 0.40;
  private static double perMinuut = 0.25;
  
  /*
   * maakt een instantie aan dat bij de gegeven aantal minuten de totale kosten berekent
   */
  
  public Telefoonteller(int aantalMinuten){   
    this.aantalMinuten = aantalMinuten;
    this.kosten = basistarief + (aantalMinuten * perMinuut);
  }
  
  public int getAantalMinuten(){
    return aantalMinuten;
  }
  
  public double getKosten(){
    return kosten;
  }
}


Ik laat de verantwoordelijkheid voor het bijhouden van de totale kosten en de totaal gebelde minuten bij de GUI. Op het moment dat er een aantal minuten ingevoerd wordt, maakt mijn GUI een nieuwe instantie van de klasse Telefoonteller aan. In hoeverre is mijn oplossing verkeerd?

Beste antwoord (via Verwijderd op 04-05-2016 10:10)


  • Invisible_man
  • Registratie: Juni 2006
  • Laatst online: 21:04
Het idee van object georiënteerd programmeren is onder andere dat je functionaliteit plaats in het object wat er verantwoordelijk voor is. In jouw geval laat je nu de GUI dus de oude stand ophalen, ophogen en weer terugplaatsen. Het zou zijn dat je een methode in je class maakt die zelf de nieuwe minuten bij de stand optelt. Hoef je in je GUI niet eerst de oude waarde te hebben en kan je in je class eventueel nog wat dataverificatie of andere zaken ermee doen. Denk bijvoorbeeld aan niet alleen een totaalminutenteller ophogen, maar ook een minutenteller van de vandaag gebelde minuten. Twee tellers die je dan in één keer kan ophogen zonder dag je GUI daar lastig mee gevallen hoeft te worden.

Lastige is dat bij dit soort simpele opdrachten het voordeel van deze manier van werken vaak niet echt duidelijk wordt. Maar als je programma's veel groter worden kan dit de structuur van je programma wel veel eenvoudiger maken. Denk bijvoorbeeld aan het kunnen hergebruiken van deze klasse voor diverse interfaces, een GUI, een command line en een webinterface bijvoorbeeld. Door dit soort dataverwerking niet in de interfaces te doen, maar in de klasses wordt alles simpeler en hergebruik je meer code.

Alle reacties


Acties:
  • +1 Henk 'm!

  • Hydra
  • Registratie: September 2000
  • Laatst online: 21-08 17:09
Het gaat een beetje tegen de basisprincipes van MVC in. Je model is verantwoordelijk voor het bijhouden van de data, niet je GUI. Je controller acteert op UI events en past de data aan. Je model stuurt een event dat de data veranderd is, en je view redrawed zichzelf omdat het model aangepast is. De logica van het ophogen van het bedrag hoort in het model te zitten.

Daarnaast snap ik je datamodel niet helemaal. Ik zou verwachten dat je een lijst "gesprekken" hebt met elk een duur. Dus als je een nieuw gesprek toevoegt voeg je een nieuw object aan de lijst toe. De totale kosten zijn dan de som van de kosten die elk "Gesprek" object uit kan rekenen.

Tenslotte: ik vemoed dat de static vars bedoeld zijn als constanten. Als dit het geval is, missen ze nog 't 'final' keyword. Dit zorgt ervoor dat de waarde niet gewijzigd kan worden.

https://niels.nu


Acties:
  • Beste antwoord
  • +2 Henk 'm!

  • Invisible_man
  • Registratie: Juni 2006
  • Laatst online: 21:04
Het idee van object georiënteerd programmeren is onder andere dat je functionaliteit plaats in het object wat er verantwoordelijk voor is. In jouw geval laat je nu de GUI dus de oude stand ophalen, ophogen en weer terugplaatsen. Het zou zijn dat je een methode in je class maakt die zelf de nieuwe minuten bij de stand optelt. Hoef je in je GUI niet eerst de oude waarde te hebben en kan je in je class eventueel nog wat dataverificatie of andere zaken ermee doen. Denk bijvoorbeeld aan niet alleen een totaalminutenteller ophogen, maar ook een minutenteller van de vandaag gebelde minuten. Twee tellers die je dan in één keer kan ophogen zonder dag je GUI daar lastig mee gevallen hoeft te worden.

Lastige is dat bij dit soort simpele opdrachten het voordeel van deze manier van werken vaak niet echt duidelijk wordt. Maar als je programma's veel groter worden kan dit de structuur van je programma wel veel eenvoudiger maken. Denk bijvoorbeeld aan het kunnen hergebruiken van deze klasse voor diverse interfaces, een GUI, een command line en een webinterface bijvoorbeeld. Door dit soort dataverwerking niet in de interfaces te doen, maar in de klasses wordt alles simpeler en hergebruik je meer code.

Acties:
  • 0 Henk 'm!

Verwijderd

Topicstarter
Jullie antwoorden zijn duidelijk, bedankt! Volgens het boek is de reden van niet final maken, dat de tarieven nog gewijzigd kunnen worden zoals dat ook bij een echte provider gebeurt. Ik had deze attributen ook eerst static en final gemaakt;-) Op naar de volgende oefening.