Matroids Matheplanet Forum Index
Moderiert von matph
Informatik » Programmieren » Java: Lese- und Schreibzugriff auf Klassen
Autor
Universität/Hochschule Java: Lese- und Schreibzugriff auf Klassen
curious_mind
Aktiv Letzter Besuch: im letzten Quartal
Dabei seit: 10.11.2012
Mitteilungen: 482
  Themenstart: 2021-05-07

Matheplanet neueFrage = new Matheplanet(); Hier die Aufgabe: Soweit habe ich folgende Idee: \sourceon Java public class Personalverwaltung { class Mitarbeiter { int budget; } class Chef { private String naechsterTermin; public void setNaechsterTermin(String termin) { naechsterTermin = termin; } public String getNaechsterTermin() { return naechsterTermin; } } class ChefSekretaerin { } } \sourceoff Also meine Idee war, naechsterTermin private zu deklarieren und dann Setter- und Getter-Methoden zu nutzen. Jetzt ist mir aber nicht klar, wie ich die Setter-Methode nur der Chefsekretaerin geben kann, ohne es auch der Mitarbeiterin zu geben. Vielleicht funktioniert das so doch nicht...? Habt ihr nen Tipp für mich?


   Profil
Scynja
Aktiv Letzter Besuch: im letzten Monat
Dabei seit: 23.02.2011
Mitteilungen: 415
Wohnort: Deutschland
  Beitrag No.1, eingetragen 2021-05-07

Hallo, du kannst beispielsweise den setter package-private machen und den Mitarbeiter aus dem chef-package ziehen. Oder du implementierst ein Rechte- / Rollensystem.


   Profil
curious_mind
Aktiv Letzter Besuch: im letzten Quartal
Dabei seit: 10.11.2012
Mitteilungen: 482
  Beitrag No.2, vom Themenstarter, eingetragen 2021-05-08

Ich seh da keine Packages. Meinst du die Klassen? Und ich bin nicht sicher von der Aufgabenstellung her, ob vorgesehen ist, dass wir die Klassen verschachteln, das wäre sonst meine Idee gewesen.


   Profil
DerEinfaeltige
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 11.02.2015
Mitteilungen: 2969
  Beitrag No.3, eingetragen 2021-05-08

Packages sind durch die Ordnerstruktur vorgegeben. Die Klassen kann (sollte) man ja auf mehrere Dateien verteilen. Legt man Chef und Sekretärin ins gleiche Package (in den gleichen Unterordner), die Mitarbeiter jedoch in einen anderen, so können Chef und Sekretärin auf package-private Dinge (ohne expliziten Zugriffsmodifizierer) zugreifen, die Mitarbeiter hingegen nicht. Das Implementieren von Rollen würde mir allerdings eher zusagen.


   Profil
DerEinfaeltige
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 11.02.2015
Mitteilungen: 2969
  Beitrag No.4, eingetragen 2021-05-08

Zur Verdeutlichung: Im Ordner Personalverwaltung gibt es zwei Unterordner: 1. Teppichbodenabteilung enthält die Klassen a) Chef.java b) ChefSekretaerin.java 2. Grossraumbuero enthält die Klasse c) Mitarbeiter.java Codes: \sourceon Java \numberson package Personalverwaltung.Teppichbodenabteilung; public class Chef { private String naechsterTermin; // Geht niemanden etwas an void setNaechsterTermin(String termin){ // Geht nur die Teppichbodenabteilung etwas an naechsterTermin=termin; } public String getNaechsterTermin(){ // Geht jeden etwas an return naechsterTermin; } } \sourceoff \sourceon Java \numberson package Personalverwaltung.Teppichbodenabteilung; public class ChefSekretaerin { Chef chef; public void setTermin(String termin){ chef.setNaechsterTermin(termin); // Funktioniert, da im gleichen Package! } } \sourceoff \sourceon Java \numberson package Personalverwaltung.GrossraumBuero; import Personalverwaltung.Teppichbodenabteilung.Chef; public class Mitarbeiter { Chef chef; public void setTermin(String termin){ chef.setNaechsterTermin(termin); // setNaechsterTermin is not visible! Error! } } \sourceoff


   Profil
curious_mind
Aktiv Letzter Besuch: im letzten Quartal
Dabei seit: 10.11.2012
Mitteilungen: 482
  Beitrag No.5, vom Themenstarter, eingetragen 2021-05-08

Bevor ich auf deine Posts eingehe, hier wie ich es gemacht hatte: In der Main.java: \sourceon Java package KE2.EA3; public class Main { public static void main(String[] args) { ChefSekretaerin chsek = new ChefSekretaerin(); Chef cheffi = new Chef(); Chef.Mitarbeiter mit = new Chef.Mitarbeiter(); // funktioniert nicht!? chsek.nexterm = cheffi.getNaechsterTermin(); System.out.println(chsek.nexterm); cheffi.setNaechsterTermin("17.1.71"); chsek.nexterm = cheffi.getNaechsterTermin(); System.out.println(chsek.nexterm); // ---hier weiterüberlegen, wie man differenziert, wer "setNaechsterTermin" // eigentlich aufruft. Oben steht einfach nur "cheffi.set...", aber woher weiß ich, // dass die ChefSekr. das aufruft? } } \sourceoff In der Personalverwaltung.java: \sourceon Java package KE2.EA3; class Chef { private String naechsterTermin; Chef(){ naechsterTermin = "01.01.2000"; } void setNaechsterTermin(String termin) { naechsterTermin = termin; } public String getNaechsterTermin() { return naechsterTermin; } class Mitarbeiter { int budget; } } class ChefSekretaerin { String nexterm; } \sourceoff Ich dachte, wegen dem hier \quoteon(2021-05-03 09:34 - DerEinfaeltige in Beitrag No. 4 [edit: anderer Thread])
Modifier Class Package Subclass World
public Y Y Y Y
protected Y Y Y N
no modifier Y Y N N
private Y N N N
\quoteoff dass man das Problem über eine Unterklasse lösen kann. Dann war in der Main aber mein Problem, dass ich nicht so recht wusste, WER eigentlich setNaechsterTermin aufruft (siehe meine Kommentierung als Notiz an mich selbst als ich vom Rechner weg musste) bzw. besser gesagt: wie ich eigentlich bestimme, dass die ChefSekretaerin den Termin ändert. -- Jetzt, in der Gegenwart lese ich deine Posts und sehe, du hast für die ChefSekretaerin eine eigene Setter-Methode geschrieben. DANN wird natürlich ersichtlich, wer da was aufruft. Das müsste dann ja über sowas wie \sourceon Java ChefSekretaerin chsek = new ChefSekretaerin(); chsek.setTermin("bla") \sourceoff gehen. Trotzdem noch mal zur Klarheit: Du hast die ChefSekretaerin jetzt so implementiert, dass sie als Attribut/Variable ein Chef chef Objekt erstellt und dieses dann ändert. Das muss aber nicht dasselbe Chef-Objekt sein, dass vielleicht eine andere ChefSekretaerin (ein anderes Sekretaerin-Objekt) erstellt. Eigentlich - von der Logik her - sollte es ja nur einen Chef geben, dessen Termin die Sekretaerin(nen) verändern dürfen oder? Also von der Logik her, müsste Chef doch besser statisch implementiert werden, oder?



   Profil
Scynja
Aktiv Letzter Besuch: im letzten Monat
Dabei seit: 23.02.2011
Mitteilungen: 415
Wohnort: Deutschland
  Beitrag No.6, eingetragen 2021-05-09

\quoteon(2021-05-08 21:16 - curious_mind in Beitrag No. 5) Eigentlich - von der Logik her - sollte es ja nur einen Chef geben, dessen Termin die Sekretaerin(nen) verändern dürfen oder? Also von der Logik her, müsste Chef doch besser statisch implementiert werden, oder? \quoteoff Lies dir mal bitte die Aufgabenstellung durch. Bezüglich der Unterklassen: Ich denke, dass DerEinfältige hier von Vererbung und nicht von inneren Klassen redet. Ich sehe auf die Schnelle keine sinnvolle Möglichkeit, wie man den Sachverhalt über Vererbung geschickt abbilden könnte.


   Profil
DerEinfaeltige
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 11.02.2015
Mitteilungen: 2969
  Beitrag No.7, eingetragen 2021-05-09

Obige Tabelle ist nicht von mir. Die ist nur aus einer Dokumentation kopiert. Eine "Subclass" ist eine Tochterklasse (Erbe), keine Nested Class! \sourceon Java \numberson // Datei AbteilungsLeiter.java public class AbteilungsLeiter extends Chef{ // Ich bin eine Subclass von Chef // Ich kann auf package-private Attribute von Chef nicht zugreifen, obwohl ich selbst ein Chef bin! } \sourceoff Wenn man verhindern will, dass eine Sekretaerin einem anderen Chef zugewiesen wird, dann könnte man das Attribut "chef" einfach final (sprich: immutable) machen. Der Chef muss dann spätestens mit dem Konstruktor gesetzt werden. Zum ersten geposteten Code: \sourceon Java \numberson public class Main { public static void main(String[] args) { ChefSekretaerin chsek = new ChefSekretaerin(); Chef cheffi = new Chef(); // Chef.Mitarbeiter mit = new Chef.Mitarbeiter(); // funktioniert nicht!? // Die Klasse Chef enthält keine Methode "Mitarbeiter()", die man aufrufen könnte. // Möglich wären: Chef.Mitarbeiter cheffisBotenjunge = cheffi.new Mitarbeiter(); Chef.Mitarbeiter unbekannterLakai = new Chef().new Mitarbeiter(); } } \sourceoff


   Profil
curious_mind
Aktiv Letzter Besuch: im letzten Quartal
Dabei seit: 10.11.2012
Mitteilungen: 482
  Beitrag No.8, vom Themenstarter, eingetragen 2021-05-09

\quoteon Eine "Subclass" ist eine Tochterklasse (Erbe), keine Nested Class! \quoteoff Achso! Ups.. 😄 Also nach dem Lesen Eurer Hinweise, habe ich es jetzt so: \sourceon Java package Personalverwaltung.Mitarbeiter class Mitarbeiter { int budget; public int getBudget(){ return budget; } // Teilaufgabe b) } package Personalverwaltung.Chefetage class Chef { private String naechsterTermin; // setNaechsterTermin ist ohne Modifizierer, also package-private void setNaechsterTermin(String termin) { naechsterTermin = termin; } public String getNaechsterTermin() { return naechsterTermin; } } class ChefSekretaerin { Chef chef; void setChefTermin(String t) { chef.setNaechsterTermin(t); } } \sourceoff (De facto würde ich das nicht in einer Datei so schreiben, schon klar) Ich denke, das müsste nun stimmen. Kommen wir zur Teilaufgabe b) Mein Antwortversuch ist: Zum Lesen der Budgets: s.o. die public int getBudget Methode in der class Mitarbeiter. Zur Frage, wieso ein Zugriffsmodifikator jetzt nicht ausreicht: Wenn, dann müsste man eine Setter-Methode mit "public" verwenden, damit die Chefetage (aus dem anderen Paket) darauf zugreifen kann, um die Budgets zu ändern. Dann wäre wg. public aber auch ein Zugriff über andere Mitarbeiter-Objekte möglich. Zur Frage, wie man das anders lösen könnte: Das ist eine sehr gute Frage! 😃 ...Vielleicht ein spezieller "private" Konstruktor für Mitarbeiter-Objekte in der Chef class, die ein "final" Budget festlegen und nur Chefs können Mitarbeiter anlegen, und bei Änderung des Budgets wird einfach ein neuer Mitarbeiter erstellt? Hm, aber dann hätte ich das Problem nur auf die Mitarbeiter-Objekte verschoben, oder? Hm.


   Profil
DerEinfaeltige
Senior Letzter Besuch: in der letzten Woche
Dabei seit: 11.02.2015
Mitteilungen: 2969
  Beitrag No.9, eingetragen 2021-05-09

Statt immer neue Mitarbeiter zu erstellen, wenn man ihr Budget ändern will (klingt irgendwie absurd und ist auch nicht sinnvoll, da die Mitarbeiterklasse ja beliebig viele sonstige Informationen enthalten wird), könnte man einfach das Budget in eine Klasse auslagern, von der der Mitarbeiter nur eine Referenz besitzt, die er nicht verändern und in der er nur den Getter aufrufen kann. Wie das konkret funktionieren könnte, wurde ja bereits am Beispiel des Chefs und seiner Termine demonstriert. Alternativ könnte man in die Budget-Klasse andere beliebige Sicherheitsmechanismen einbauen.


   Profil
curious_mind
Aktiv Letzter Besuch: im letzten Quartal
Dabei seit: 10.11.2012
Mitteilungen: 482
  Beitrag No.10, vom Themenstarter, eingetragen 2021-05-10

So? \sourceon Java package Personalverwaltung.Mitarbeiter class Mitarbeiter { Mitarbeiterbudget mitbud; int getLohn() { return Personalverwaltung.Chefetage.mitbud.getBudget(); // <-------- ! } } package Personalverwaltung.Chefetage class Chef { private String naechsterTermin; // setNaechsterTermin ist ohne Modifizierer, also package-private void setNaechsterTermin(String termin) { naechsterTermin = termin; } public String getNaechsterTermin() { return naechsterTermin; } void setLohn(int l, Mitarbeiterbudget m){ // <-------- ! m.setBudget(l); } } class ChefSekretaerin { Chef chef; void setChefTermin(String t) { chef.setNaechsterTermin(t); } } class Mitarbeiterbudget { // <-------- ! int budget; void setBudget(int Lohn){ budget = Lohn; } public int getBudget(){ return budget; } } \sourceoff


   Profil
curious_mind hat die Antworten auf ihre/seine Frage gesehen.

Wechsel in ein anderes Forum:
 Suchen    
 
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters, all the rest © 2001-2021 by Matroids Matheplanet
This web site was originally made with PHP-Nuke, a former web portal system written in PHP that seems no longer to be maintained nor supported. PHP-Nuke is Free Software released under the GNU/GPL license.
Ich distanziere mich von rechtswidrigen oder anstößigen Inhalten, die sich trotz aufmerksamer Prüfung hinter hier verwendeten Links verbergen mögen.
Lesen Sie die Nutzungsbedingungen, die Distanzierung, die Datenschutzerklärung und das Impressum.
[Seitenanfang]