Ist es empfehlenswert, einen verwandten Satz von Eigenschaften in eine eigene Struktur / Klasse zu packen?

Schreiben eines Benutzerobjekts in Swift, obwohl sich meine Frage auf eine stark typisierte Sprache bezieht. Ein Benutzer kann eine Reihe von Links haben (FacebookProfile, InstagramProfile usw.). Ein paar Fragen dazu.

Ist es empfehlenswert, Links in ein eigenes Objekt zu verpacken?

    struct User {
       var firstName: string
       var lastName: string
       var email: string
       var links: Links
    }}

    struct Links {
       var facebook: string
       var instagram: string
       var twitter: string 
    }}

Oder sollten sie locker sein? Ich weiß, dass beide Wege technisch in Ordnung sind, frage mich aber, ob es im Allgemeinen einen empfohlenen Ansatz gibt - insbesondere für die Lesbarkeit.

struct User { 
   var firstName: string
   var lastName: string
   var email: string
   var facebookLink: string
   var twitterLink: string
   var instagramLink: string
}

Sollten Links in einem solchen Szenario eine Sammlung / Liste sein? Ich dachte, es sollte keine Liste sein, da eine feste Anzahl von Linkoptionen verfügbar ist und keine wachsende Anzahl. Ist mein Denken richtig?
Ist es empfehlenswert, meine Netzwerkmethoden wie getUsers, getUser, updateUser im User-Objekt zu platzieren?

Ich weiß, dass dies subjektiv sein kann, aber ich versuche zu verstehen, was die beste Vorgehensweise in ähnlichen Situationen ist. Würde mich über Hinweise freuen.

— Prabhu
quelle

Antworten:

Sie werden entweder brauchen

Null einer Sache,
eins von einer Sache, oder
eine beliebige Anzahl der Sache.

Ich bin schockiert, dass Ihr Design vorhersagt, dass die Anzahl der benötigten Links immer drei sein wird und dass Sie wissen, wie sie für immer heißen.

Was ich predige, nennt man die Null-Eins-Unendlichkeitsregel . Es mag zunächst nicht offensichtlich sein, aber es sagt mir, dass Ihr Design nicht zukunftstolerant ist.

Ich würde mich anders fühlen, wenn diese Links etwas Besonderes für sie wären. Eine besondere Sache, die ich beim Zugriff auf einen Facebook-Link anders mache, als bei einem Twitter-Link. Das würde sie zu verschiedenen Dingen machen. Dies ist in diesem Code jedoch nicht angegeben.

Deshalb stört mich die E-Mail-Zeichenfolge nicht. Ich weiß, dass das anders verwendet wird als die Links.

Bis ich einen Grund sehe, diese Links anders zu verwenden, bin ich auf der Seite einer Linksammlung.

— candied_orange
quelle

FacebookProfile, InstagramProfile, ...Ich denke, OP hat die Frage bereits beantwortet. Die Sprache sagt uns, dass Benutzer möglicherweise kein oder mehrere Profile in Bezug auf soziale Netzwerke haben. Aber der Programmierer in ihm hat dieses Element zu bloßen Links gemacht. Warum nicht eine Sammlung von Profiles? Ich stimmte CandiedOrange zu. Sie gehen zu viel von der Zukunft aus. Möglicherweise werden neue soziale Netzwerke angezeigt. Tatsächliche könnten verschwinden. Benutzer können von einem Netzwerk in ein anderes wechseln.

— Laiv

Dies ist eine Vermutung. Angenommen, Sie möchten diese Profile für soziale Anmeldungen verwenden. Mit dem Komponentenprofil müssen wir beginnen. Wo können Informationen zur Authentifizierung und zur aktuellen Sitzung mit diesen Profilen gekapselt werden? Dies kann als YAGNI oder Überentwicklung angesehen werden, ist aber nichts wert, darüber nachzudenken, ob diese Funktionen angefordert werden könnten oder ob sie für unsere Anwendung von Nutzen sein könnten. Wenn nicht, verwerfen Sie sie einfach.

— Laiv

@ Prabhu hängt davon ab, warum Sie es einschränken. Ich vermute, nur so viele passen in die GUI. Welches ist in Ordnung. Beschränken Sie die Datenstruktur jedoch nicht aufgrund der grafischen Benutzeroberfläche. GUIs ändern sich aus einer Laune heraus. Datenstrukturen sind teuer in der Änderung. Es lohnt sich wirklich, sie gleich beim ersten Mal richtig zu machen.

— candied_orange

Das ist der Punkt. Nehmen Sie einfach die Strukturen an, die zukünftige Änderungen weniger schmerzhaft machen. Nicht mehr und nicht weniger. Wir, Candied und ich sagen dies, weil wir (ich glaube) oft ähnlichen Situationen ausgesetzt waren und wir mögliche Merkmale vorhersehen, die sich ändern oder weiterentwickeln können. Letztendlich sind Sie dem Projekt und seiner Zukunftsperspektive näher.

— Laiv

@Prabhu: Beachten Sie, dass Sie eine Frage zu bewährten Verfahren gestellt haben und nicht, ob dies der präziseste Ansatz für Ihr spezifisches Szenario ist. Ich bin normalerweise auf der Seite der Vermeidung von Überentwicklung, aber die Kosten für zukünftige Wartungsarbeiten (Hinzufügen / Entfernen von Links, Aktualisieren der Entitätsklassendefinitionen, ...) überwiegen bei weitem die Kosten für die Implementierung einer Sammlung von Links. Wenn Sie Ihre Spalten genannt link1, link2, link3würde die Notwendigkeit für eine Sammlung hat mehr offensichtlich. Die Tatsache, dass Sie den Spalten einen aussagekräftigeren Namen gegeben haben, ändert jedoch nichts an der Tatsache, dass es sich um eine Sammlung sich wiederholender Daten handelt.

— Flater

Sie stehen kurz davor, in die Falle "Ich sehe eine technische Möglichkeit" zu geraten.

Nur weil Sie ein gemeinsames Merkmal zwischen Elementen sehen, bedeutet dies nicht, dass es sinnvoll ist, eine Aggregation auf sie anzuwenden. Die Aggregation sollte etwas bedeuten. Nicht auf technischer Ebene, sondern in Ihrer Problemdomäne.

Sie sind alle Links in Ordnung, aber bedeutet das im Kontext einer Benutzerklasse etwas? Nein. Es ist genauso bedeutungslos wie eine Untergruppe mit Klassen mit den Namen "Strings" und "Numbers".

Das Problem mit dieser Art von Dingen ist, dass es Ihr Modell verwischt. Es zwingt den Codeleser, das Bedeutungsvolle vom Bedeutungslosen zu trennen, bevor er die Domäne vollständig versteht.

Niemand spricht jemals über die Links eines Benutzers. Es wäre anders, wenn Sie Ihre Aggregation SocialNetworkIds aufrufen würden. Da dies tatsächlich etwas bedeuten würde, wäre es eher eine echte Eigenschaft des Benutzers als eine willkürliche technische Sammlung.

— Martin Maat
quelle

Was genau mein Zweifel war, veranlasste mich, diese Frage zu stellen. Die einzige Beziehung zwischen den verschiedenen Links besteht darin, dass sie möglicherweise zusammen in der Benutzeroberfläche angezeigt werden. In diesem Fall würden Sie also vorschlagen, sie NICHT in ein separates Objektrecht einzufügen, sondern sie direkt unter dem Benutzerobjekt zu belassen?

— Prabhu

Ich denke nicht, dass es in diesem Fall hilfreich wäre. Sie haben noch kein Problem, das das Hinzufügen einer Komplexitätsebene rechtfertigt. Wenn Sie viel mehr Eigenschaften hätten, hätte sich der Gruppierungsaufwand möglicherweise verbessert (mit passenden Namen für die Gruppen). Es ist jedoch schwer zu sagen, was ohne Kontext angemessen ist. Unter dem Strich sollte es die Dinge einfacher machen. Zu verstehen und / oder mit dem nächsten Schritt im Entwicklungsprozess fortzufahren.

— Martin Maat

Ich in der Regel wie Over-Engineering zu vermeiden, aber ich frage mich: würden Sie das gleiche gesagt haben, wenn OP hatte seine Felder genannt link1, link2, link3? Das Design einer Datenstruktur ist unabhängig vom Namen der Felder, daher ist mein Beispiel funktional äquivalent. Es geht um Zukunftssicherheit. YAGNI würde im Allgemeinen gelten, aber wenn überhaupt, haben sich soziale Medien als anfällig für virale Popularität und Veränderungen erwiesen. Es erscheint wünschenswert, eine Neuentwicklung für jede neue beliebte Social-Media-Site zu vermeiden. Andernfalls riskieren Sie, in das Feld "Was ist noch ein Feld?" Zu fallen. Falle, die enorme Schulden schaffen kann.

— Flater

Im Allgemeinen halte ich es für sinnvoll, die Links für sich zu haben, structwenn Sie wahrscheinlich ähnliche Vorgänge auf jeden von ihnen anwenden, und insbesondere, wenn Sie immer dieselben Vorgänge für alle ausführen. Wenn sie in Ihrer Bewerbung für nicht verwandte Zwecke bestimmt sind, würde ich sie trennen. Wenn sie beispielsweise die Homepage des Benutzers, die Website der Krankenkasse und ein Link zu ihrer bevorzugten Nachrichtenseite wären, würde ich sie wahrscheinlich nicht zusammenfassen, da sie nicht miteinander verbunden zu sein scheinen. Bei drei Social-Media-Websites scheinen sie in einer App ähnlich behandelt zu werden und sollten daher wahrscheinlich in Gruppen zusammengefasst werden. Ich würde einen aussagekräftigeren Namen verwenden als Linksallerdings. (Welche Art von Links? Zu welchem Zweck in Ihrer App?)

Ich stimme Ihrem Gedanken zu # 2 zu. Wie oben erwähnt, wäre eine Liste oder eine andere Sammlung eine gute Wahl, wenn die Anzahl wachsen oder variabel werden sollte, jedoch nicht für das von Ihnen beschriebene Szenario.

Ich würde keine Netzwerkmethoden in die Objekte einfügen, die die vom Netzwerk abgerufenen Daten enthalten. Woher die Daten stammen und wie sie zu erhalten sind, spielt für den Hauptzweck einer Klasse normalerweise keine Rolle. Was ist, wenn Sie in Zukunft Daten von der Festplatte abrufen möchten? Oder möchten Sie, dass der Benutzer es eingibt? Gehen Sie diesen Weg weit genug und eine einfache UserKlasse muss über Code verfügen, um alle möglichen Methoden zur Dateneingabe und zum Abrufen zu handhaben. Lassen Sie einfach eine UserKlasse die Daten halten und pflegen, während sie sich im Speicher befinden. Alles andere kann von geeigneteren Klassen erledigt werden.

— user1118321
quelle