Lange Variablennamen oder Klasse

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Lange Variablennamen oder Klasse

    Aber was ist besserer Stil?​ 2
    1.  
      privacy.hideContentInAppSwitcher (1) 50%
    2.  
      privacy.hideContent.inAppSwitcher (1) 50%
    3.  
      privacy.hideContent.appSwitcher (0) 0%
    Hallo zusammen,

    ich bin ja noch absoluter Anfänger und habe noch so meine Problemchen was einen guten Stil angeht.

    Ich kann jetzt entweder eine Klasse mit Properties mit langen Namen erstellen. z.B.
    • privacy.hideContentInAppSwitcher
    • privacy.hideContentAgainstScreenshot
    • privacy.hideContentAgainstScreenrecording
    • privacy.hideContentDuringInactivity
    oder eine Klasse HideContent einziehen
    • privacy.hideContent.inAppSwitcher
    • privacy.hideContent.againstScreenshot
    • privacy.hideContent.againstScreenrecording
    • privacy.hideContent.duringInactivity
    dann könnte ich die Variablennamen evtl. sogar noch einkürzen

    • privacy.hideContent.appSwitcher
    • privacy.hideContent.screenshot
    • privacy.hideContent.screenrecording
    • privacy.hideContent.inactivity

    Die zusätzliche Klasse HideContent bringt mir außer der, wie ich finde, besseren Lesbarkeit keine Vorteile, im Gegenteil ist es mehr Aufwand weil ich das Ganze auch noch Codeble brauche
  • So ganz verstehe ich Deine Frage nicht: Der Zweck einer Klasse ist doch nicht, Property-Namen sprechend zu machen...

    Stellen Instanzen der Klasse HideContent irgendwelche Objekte mit eigenen Zuständen und Methoden dar? Wie Du schreibst ja nicht, also wozu dann eine Klasse dafür?

    Methodennamen sollten beschreiben, was deren Funktion ist. "inAppSwitcher" macht das nicht und scheidet daher aus. Schau mal hier.

    Somit bleibt meiner Meinung nach - aus beiden Gründen - nur Option #1.

    Mattes
    Diese Seite bleibt aus technischen Gründen unbedruckt.
  • OK, dann frag ich mal anders.
    Ich erstelle eine Konfiguration die mehrere Teilbereiche umfassen soll.
    + Configuration
    + AccessProtection
    - unlockCode
    - maximumUnlockCodeAge
    - ...
    + Privacy
    - hideContentInAppSwitcher
    - privacy.hideContentAgainstScreenshot
    + DisplayOptions
    ...

    Auch wenn die Klassen keine Funktion sondern ausschließlich Properties zur Verfügung stellen ist es doch übersichtlicher, als wenn ich alle Properties ohne hierarchische Struktur in einer Klasse ablegen würde.

    Ist das gedanklich falsch? Soll ich flach alle Properties in eine Klasse legen?
  • also ich lege properties eigentlich immer als key-value pairs ab. Bevorzugt in JSON Arrays oder Objekten da diese so schön universell einsetzbar sind aber ich bin auch mehr im web Bereich unterwegs.

    eine Klasse zu machen die keine Funktion sondern nur Daten enthält finde ich immer komisch, wobei Entitäten ja im Prinzip auch nichts anderes sind und da stehen heutzutage ja alle drauf
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Hallo,

    Interessante Frage. Wie dieser kurze Thread schon zeigt, gibt es dazu sicherlich viele unterschiedliche Meinungen/Vorlieben und kein "richtig" oder "falsch". Ich selbst habe in der Vergangenheit unterschiedliche Ansätze genutzt und sehe sowohl beim "flat" als auch beim "nested" Ansatz je Vor- und Nachteile. Mittlerweile lasse ich mich häufig einfach von meiner Intuition leiten, allen voran mit einem objektorientierten Fokus. Das heißt die primäre Frage für mich ist: macht es einen semantischen Sinn, mehrere Properties / Funktionen in einer Unterklasse gruppieren? Stehen diese Properties in einer solch abgekapselten Beziehung? Das "nett aussehen" allein sollte nicht der ausschlaggebende Grund sein.

    Da du von Konfigurationen als Use Case sprichst, teile ich einfach mal einen Code-Ausschnitt eines kleinen SwiftUI-Packages von mir, welches Balkendiagramme (etc.) erstellt. Über ein Konfigurationsstruct lässt sich das Aussehen und Verhalten einstellen. In diesem Fall habe ich zusätzliche, verschachtelte Structs genutzt, welche die Properties gruppiert. Dazu gab es zwei Gründe:

    a) Die Konfigurationseigenschaften lassen sich gut gruppieren, diese Gruppen stehen einer semantisch/logischen Beziehung. So gibt es die BarConfiguration, welche das Aussehen der Balken des Diagramms beschreibt, die LayoutConfiguration, welche Eigenschaften bzgl. des Chart-Koordinatensystems etc. enthält, und die SelectionConfiguration, welche beschreibt, wie das Diagram auf Interaktion reagiert.

    b) Diese Abkapslung bietet zudem den Vorteil, dass man "partielle Presets" anlegen kann. Wenn man sehr viele Konfigurationswerte hat, ist es als Developer sehr unangenehm, wenn man sich entscheiden muss zwischen "Komplett Default Style" und "Komplett Custom Style", bei welchem man alle Werte mühselig angeben muss. Was, wenn man den Bar-Style (=BarConfiguration) beim default belassen möchte, aber einen eigenen Layout-Stil definieren möchte? Als Lösung habe ich für jedes abgekapselte Struct ein static .defaultConfiguration, sodass man für jede Gruppe einzeln entscheiden kann.

    Am Ende ergibt sich also ein Syntax wie z.B. myConfiguration.selection.useHapticFeedback, was meiner Meinung nach lesbar ist und semantisch Sinn ergibt. Ich bin aktuell mit meiner Lösung relativ zufrieden, bin aber auch immer wieder auf neue Inputs und Ideen gespannt! :)

    Quellcode

    1. @available(iOS 15.0, *)
    2. extension BarChart {
    3. /// Struct to define the bar chart's visual characteristics
    4. public struct Configuration {
    5. // MARK: - Bar and Segment Styling
    6. public var bar: BarConfiguration
    7. public struct BarConfiguration {
    8. /// The minimum spacing between two different bar items
    9. public let minBarSpacing: CGFloat
    10. /// The maximum thickness of a single bar item
    11. public let maxBarThickness: CGFloat
    12. /// The corner radius of the bar items
    13. public let barCornerRadius: CGFloat
    14. /// The minimum segment size. It is recommended to set it to `2 * barCornerRadius`
    15. public let minSegmentSize: CGFloat
    16. public static let defaultConfiguration = BarConfiguration(
    17. minBarSpacing: 2,
    18. maxBarThickness: 10,
    19. barCornerRadius: 1.5,
    20. minSegmentSize: 4
    21. )
    22. }
    23. // MARK: - Layout and Grid Styling
    24. public var layout: LayoutConfiguration
    25. public struct LayoutConfiguration {
    26. /// The minimum value the chart height should represent at 100%
    27. public let minChartValue: Decimal
    28. /// Whether to show a grid in the background
    29. public let showBackgroundGrid: Bool
    30. /// The minimum grid step as value. A multiple (>1) will be used as spacing between two grid lines.
    31. public let minGridSpacingValue: Decimal
    32. /// The maximum number of grid lines that should be displayed
    33. public let maxNumberOfGridLines: Int
    34. /// The edge at which the y axis is displayed, i.e. leading or trailing edge
    35. public let yAxisPosition: HorizontalEdge
    36. public static let defaultConfiguration = LayoutConfiguration(
    37. minChartValue: 0,
    38. showBackgroundGrid: true,
    39. minGridSpacingValue: 25,
    40. maxNumberOfGridLines: 3,
    41. yAxisPosition: .leading
    42. )
    43. }
    44. // MARK: - Selection Configuration
    45. public var selection: SelectionConfiguration
    46. public struct SelectionConfiguration {
    47. /// Whether the user can select bar items with tap / drag gestures
    48. public let canSelectBarItems: Bool
    49. /// Whether the last selection should be preserved after ending a drag gesture
    50. public let preserveSelection: Bool
    51. /// Whether the tap / drag gestures should give haptic feedback to the user
    52. public let useHapticFeedback: Bool
    53. public static let defaultConfiguration = SelectionConfiguration(
    54. canSelectBarItems: true,
    55. preserveSelection: true,
    56. useHapticFeedback: true
    57. )
    58. }
    59. // MARK: Preset Configurations
    60. public static let defaultConfiguration = Configuration(
    61. bar: .defaultConfiguration,
    62. layout: .defaultConfiguration,
    63. selection: .defaultConfiguration
    64. )
    65. }
    66. }
    Alles anzeigen
  • Aber genau so etwas könntest du genauso leicht mit JSON oder XML abbilden und brauchst dafür keine Klasse und must nicht irgendwelche Objects Mappen. Und leichter zu lesen und zu warten wäre es auch noch weil du einfach neue key/values added kannst ohne dafür code zu ändern (Wenn der Code der das benutzt schlau genug ist natürlich nur)
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Ich habe es für mich im Sinne der Semantik nun so angelegt:

    Quellcode

    1. Configuration
    2. Configuration.accessProtection
    3. Configuration.accessProtection.unlockCode.value
    4. Configuration.accessProtection.unlockCode.age.minimumDays
    5. Configuration.accessProtection.unlockCode.age.maximumDays
    6. Configuration.accessProtection.unlockCode.history.length
    7. Configuration.accessProtection.unlockCode.history.entries
    8. Configuration.accessProtection.autoLock.afterSecondsInBackground
    9. Configuration.accessProtection.autolock.afterSecondsOfInactivity
    10. Configuration.accessProtection.biometric.isUsed
    11. Configuration.accessProtection.biometric.enterUnlockCodeToRemember
    12. Configuration.privacy
    13. Configuration.privacy.maskFieldsWithSensitiveData
    14. Configuration.privacy.hideContent.inAppSwitcher
    15. Configuration.privacy.hideContent.onScreenshots
    16. Configuration.Privacy.hideContent.onScreenrecordings
    17. Configuration.privacy.hideContent.afterSecondsOfInactivity
    18. Configuration.privacy.hideContent.atDegreeTilt
    19. Configuration.privacy.clearClipboardAfterSeconds
    20. ...
    Alles anzeigen
    Habt Ihr noch Verbesserungsvorschläge?