@andie39: Also das erste Beispiel finde ich nicht klar und ich würde auch sagen das ist falsch. Erst einmal modelliert die Klasse `Employee` keinen Angestellten, denn dazu fehlen Eigenschaften die einen Angestellten ausmachen. Beispielsweise das Gehalt. Das was in `Employee` zusammengefasst wird, kann man vielleicht als `Person` bezeichnen.
Dann haben wir da Abkürzung (`emp_*`) in einem Namen und bei `Employee` ist dass dann auch noch die Abkürzung für die Klasse — was keinen Sinn macht, denn diese Information steht ja bereits im Klassennamen, die braucht man nicht noch mal wiederholen. Und bei Vererbung wird es dann komisch, weil die Methoden Abkürzungen enthalten die dann vielleicht gar nicht mehr zum Namen der abgeleiteten Klasse gehören.
Bleibt `data()`, was so gar kein guter Name für eine Methode ist, mal abgesehen davon, dass der Name supergenerisch ist. Und die Methode erfüllt die gleiche Aufgabe wie `Data.display()`, was sinnvoller benannt ist, und dann sollte das bei `Employee` bzw. `Person` vielleicht auch so heissen.
Bei `Data` ist der Name auch zu generisch. Wenn die erste Klasse `Person` heisst, würde man `Data` aber *nicht* `Employee` nennen wollen, denn ein `Employee` *ist* ja eine Person, das wäre also eine Vererbung und keine Komposition. Also bräuchte man einen Namen wo die *Bestandteile* Adresse, Gehalt, und Person tatsächlich sinnvoll sind. Vielleicht ein Arbeitsvertrag, also `EmploymentContract`.
In der zweiten Klasse ist dann `emp` wieder eine blöde Abkürzung. Insbesondere weil in Kontexten wo der Arbeitnehmer vorkommen kann, ja auch der Arbeitgeber eventuell irgend wo mal modelliert werden könnte. Und dann hat man lauter Code wo `emp`-Abkürzungen sind und darf dann jedes mal überlegen oder nachforschen ob da nun jeweils `employee` oder `employer` gemeint ist. Abk. s. i.d.R. doof.
Der Suffix `*_obj` macht in 99,99% der Fälle keinen Sinn, weil in Python *alles* was man an einen Namen binden kann, ein Objekt ist. Objekt und Wert sind in Python synonym.
Und ja ich weiss, dass das aus dem Internet ist und nicht von Dir, Du kannst da nichts für!
Code: Alles auswählen
class Person:
def __init__(self, name, age):
self.name = name
self.age = age
def display(self):
print("Name of Person:", self.name)
print("Age of Person:", self.age)
class EmploymentContract:
def __init__(self, employee, address, salary):
self.employee = employee
self.address = address
self.salary = salary
def display(self):
self.employee.display()
print("Address of Employee:", self.address)
print("Salary of Employee:", self.salary)
person = Person("Ronil", 20)
contract = EmploymentContract("Indore", 25_000, person)
contract.display()
Was man da inhaltlich noch anmerken könnte, wäre das `age` ungünstig ist. Da müsste man dann einmal im Jahr alle Daten durchgehen und das Alter um eins rauf setzen. Geburtsdatum macht da mehr Sinn. `age` kann man dann als `property()` anbieten, weil man das ja ausrechnen kann.
Beim zweiten Beispiel kann man die Namen der Argumente beim Aufruf auch weg lassen. Was mich bei dem Beispiel irritiert ist die leicht sinnlose Komplexität, denn die Plattform ändert sich nicht während der Laufzeit, und diese Entscheidung dann jedes mal beim Aufruf von `print()` zu treffen, macht überhaupt keinen Sinn.
Alle drei Klassen sind keine wirklichen Klassen. Die beiden ersten haben nicht einmal einen Zustand und bei ``print_to_file.print(…)`` sieht man an den Namen schon, dass da irgendwas faul ist. `print_to_file()` wäre schon ein sinnvoller Name für die Tätigkeit die da ausgeführt wird.
Aber erst einmal zu den ersten beiden ”Klassen” die gar keine Methoden enthalten sondern jeweils nur eine Funktion. Die kann man auch einfach als das schreiben, als Funktion:
Code: Alles auswählen
def _windows_save(document):
destination = Path.home() / "Documents" / "scan.txt"
print("Saving to: ", destination)
destination.write_text(document, encoding="utf-8")
def _linux_save(document):
destination = Path.home() / "scan.txt"
print("Saving to: ", destination)
destination.write_text(document, encoding="utf-8")
Dann kann man einfach aufgrund von `platform.system()` auswählen welche davon aufgerufen werden soll. Und das muss man auch nicht mit einer Klasse verkomplizieren, sondern kann da einfach *einmal* entscheiden welche der beiden Funktionen unter einem sinnvollen Namen verwendet wird:
Code: Alles auswählen
def _windows_save(document):
destination = Path.home() / "Documents" / "scan.txt"
print("Saving to: ", destination)
destination.write_text(document, encoding="utf-8")
def _linux_save(document):
destination = Path.home() / "scan.txt"
print("Saving to: ", destination)
destination.write_text(document, encoding="utf-8")
save = _linux_save if platform.system() == "linux" else _windows_save
save("Example text.")
Wobei man das noch weiter vereinfachen könnte, da die beiden Funktionen fast das gleiche machen und sich nur durch einen Teilpfad unterscheiden.