Sichtbarkeit protected (Teil 7) - Objektorientierung: Kapselung/Vererbung/Polymorphie
In Teil 7 meines Kurses zu den drei Säulen der Objektorientierung führen wir einen neuen Sichtbarkeitsmodifizierer ein: protected. Damit können nur noch die Klasse selbst und ihre Subklassen Attribute oder Methoden sehen und sie nutzen. Eine wichtige Maßnahme zur Wahrung der Kapselung bei der Vererbung.
----
Deine Hausaufgabe:
Mache die Setter und fuelleAuf() in Getraenkeautomat protected
und die übrigen Methoden public.
Mache die Setter in Kaffeeautomat und Softdrinkautomat private
und die übrigen Methoden inkl. Konstruktoren public.
Mache die Konstruktoren von Kaffeeautomat und Softdrinkautomat public.
Verschiebe die Klasse Kantine in ein Unterpackage und stelle sicher,
dass die Setter an den Automaten nicht mehr aufgerufen werden können.
----
00:00 Einleitung
00:22 Bisheriger Stand
00:52 Problem: zu große Sichtbarkeit
01:50 private wird nicht vererbt
02:50 public macht die Kapselung kaputt
03:46 protected nur für Subklassen
04:58 package-private in Java
06:37 package-private vs. protected
07:09 private, package-private, protected
07:59 Zugriff aus anderem Package geht nicht
08:46 Vier Sichtbarkeitsmodifizierer in Java
09:04 Alles immer wenig sichtbar machen
10:13 public auf protected setzen
11:21 Sichtbarkeit ist individuell zu klären
12:23 Subklassen sollen Getter/Setter nutzen
12:57 package-private eher nicht nutzen
13:24 Sichtbarkeiten im Auto
14:43 Sichtbarkeiten im Motorrad
14:57 Autohaus anpassen
17:10 Allgemeines Vorgehen zur Sichtbarkeit
17:29 Setter durch Konstruktoraufruf ersetzen
18:40 Konstruktor in Fahrzeug protected
20:29 Fahrzeug alleine ist nicht nutzbar
21:17 Zusammenfassung
21:56 Hausaufgabe 07
Пікірлер: 4
Aber wenn man die Sub-Klassen auch im selben Package hat, wozu hat man denn überhaupt die Unterscheidung zw private-package und protected. Weil wir haben in unserem fall sogar extra die Klasse Autohaus in eine andere package verschieben müssen, um sie auszuschließen. Was für einen Mehrwert bringt dann die Wahl des protected gegenüber dem private-package?
@StefanMacke
Ай бұрын
Wenn andere Programme unsere Klassen erweitern wollen, werden sie vermulich nicht im gleichen Package liegen (können). Daher protected, damit alle Subklassen, egal in welchem Package sie liegen, auf die Member zugreifen können.
@thacreepwalk
Ай бұрын
@@StefanMackeJa ok, das macht Sinn. Vorausgesetzt man möchte, dass jemand die Klasse erweitert. Da ich eine Umschulung zum FIAE mache, habe ich leider sehr wenig praktische Erfahrung. Wir lernen hauptsächlich nur die Konzepte des Programmierens vorerst. Dann kommt es wohl doch öfters vor, dass Dritte eine Klasse von einem erweitertern?!? Weil, wenn man nach dem Prinzip geht, dass man möglichst wenig Sichtbarkeit zulässt, wäre demnach Private-Package bei eigenen Implementierungen besser. Oder vererbt man in eigene Sub-Klassen in dem man sie üblicherweise in andere Packages packt? 🤔
@StefanMacke
Ай бұрын
@@thacreepwalk Naja, man selbst erweitert vermutlich eher die eigenen Klassen ala jemand anderes. Aber dabei nutzt man normalerweise auch Packages zur Strukturierung.