Ankündigung

Einklappen
Keine Ankündigung bisher.

Umgang mit nicht Objekt und Klassenspezifische Methoden

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Umgang mit nicht Objekt und Klassenspezifische Methoden

    Im Laufe der Zeit kommen bei mir immer mehr Methoden zusammen, die ich ungern redundant in Klassen implementieren möchte, da diese nicht direkt bzw fest zugeordnet werden können. Ist an an so einer stelle statische Methoden zu definieren? Oder gibt es noch andere interessanteAnsätze. Dererlei Methoden können z.B. eigene Mathematische Funktionen sein, die die Entfernungsberechnung zweier Punkte usw.

    Legt man dann eine Klasse Mathe mit den Methoden berechne Entfernung an oder so?
    Kann es passieren, das auch zu viel Methoden in einer Klasse sind, Stichwort Speicher?

  • #2
    Dependency Injection, Vererbung, Traits.
    [I]You know, my wife sometimes looks at me strangely. „Duncan“, she says, „there's more to life than Solaris“. Frankly, it's like she speaks another language. I mean, the words make sense individually, but put them together and it's complete nonsense.[/I]

    Kommentar


    • #3
      Hab mich für DI erwärmt.

      Kommentar


      • #4
        In solchen Fällen ist es nicht verkehrt öffentliche Klasse bereitzustellen. Funktionen, sei es auch statische, die du nicht in einer Klasse benötigst, sollten dort auch nicht reingehören. Eine statische Funktion in einer Klasse hat für mich immer was mit der Aufgabe der Klasse zu tun. Hier bei kann es auch lediglich das Verarbeiten eines requests sein, die anschließend auch zum Klassen-Objekt führt oder die einfache Darstellung von Datensätze (die aber nicht verändert werden können!).

        Kommentar


        • #5
          Zitat von chorn Beitrag anzeigen
          Dependency Injection, Vererbung, Traits.
          Traits machen die Sache einfacher, mehr nicht soweit ich es in der Docu gelesen habe.
          Strengere regeln sind nicht falsch im Lernprozess.

          Di ist schon schön @CodeDesigner.

          Kommentar


          • #6
            In solchen Fällen ist es nicht verkehrt öffentliche Klasse bereitzustellen. Funktionen, sei es auch statische, die du nicht in einer Klasse benötigst, sollten dort auch nicht reingehören.
            Zu beachten ist hier nur, dass es innerhalb dieser Funktionen keine Abhängigkeiten außer weitere statische Funktionsaufrufe geben darf. Aus meiner Erfahrung weiß ich, dass man ein Set an Funktionen hat und für den selben Bereich benötigt man auf einmal etwas, dass z. B. eine Konfiguration oder externe Abhängigkeit besitzt - Dann lässt sich nicht mehr statisch abbilden.

            Kommentar


            • #7
              Zitat von CodeDesigner Beitrag anzeigen
              Kann es passieren, das auch zu viel Methoden in einer Klasse sind, Stichwort Speicher?
              Nein(*). Der ausführbare Code einer Klasse existiert nur ein einziges Mal und wird getrennt von den Daten verwaltet... erst wenn eine Klasse instanziiert wird, wird Speicher verbraucht, nämlich für die Daten die das Objekt belegt.

              (*) Code wird auch im Speicher untergebracht. In früheren Zeiten (aka 16-Bit OS, wie MS-DOS 6) musste man sich Gedanken um das Speichermodell machen, dort konnte gab es z.B. das Modell "Tiny", bei dem Code UND Daten in einem 64k Segment passen mussten (oh, und der Stack ebenfalls! Das konnte u.U. zu Laufzeitfehler führen, weil der Stack "in den Code" hineinwachsen und ihn überschreiben konnte). Größere Speichermodelle erlaubten, das Daten in einem 64k Segment untergebracht wurden und der Code in einem gesonderten 64k Segment... dieser ganze Segemntierungskram ist mit den 32-bit Betriebssystemen weggefallen, seitdem gibt es "flat memory", und Code kann theoretisch mehrere Gigabytes belegen...
              Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

              Kommentar

              Lädt...
              X