Kirjandustüübid vs klassid TypeScriptis

Oma TypeScripti kõnelustel küsitakse minult sageli, kuidas kasutada klassikalise objektorienteeritud programmeerimise asemel sõnasõnalisi tüüpe ja funktsionaalseid stiile. Kas seda on isegi võimalik teha? Kas seda lahendust tasub uurida? Lühike vastus on kindlasti jah ja nii, TypeScriptis ei pea me kasutama OOP-i ja klasse, kui me seda otsustame, siis võime kasutada nn sõnasõnalisi tüüpe.

Siit saate teada, kuidas see töötab.

Klasside määramise asemel saame luua tüübi koos stringi diskrimineerijatega (diskrimineerivad liittüübid), näiteks nii:

tüüp XyzType = {liik: “x-liik”} | {lahke: “y-tüüpi} | {lahke: "z-lahke"}

Selgitan, kuidas neid sõnasõnalisi tüüpe programmis kasutada saab, kuid kõigepealt vaatame, kuidas seda toimiks OOP-is.

Ütleme nii, et tahaksime luua järgmise hierarhia.

Nagu ülaltoodud UML-klassi diagrammist näha, peame tutvustama viit klassi. Abstraktne põhiklass on üldisem (antud juhul „kuju”) ja ülejäänud neli klassi on konkreetsed klassid.

Siin on selle rakendamine TypeScriptis, kasutades OOP-stiili.

Nüüd on küsimus selles, kuidas me selle üle anname stringi-sõnasõnalisele funktsionaalsele lahendusele.

Lihtsalt loome diskrimineerivad ametiühingutüübid, et määratleda meie jaoks vajalik geneeriline tüüp.

Siit tuleb juurutamine:

Võrreldes OOP-lahendusega näib see olevat lahkem. Teos see on. Mida me siis võidame, mida kaotame selle lähenemise korral?

Kasum:

  • Tahte lühike esitus
  • Vähem sidumist koodi ja andmete vahel
  • Andmed on edastamiseks valmis (st saate JSON-i selle kinnitada, et failisüsteemi üle kanda või failisüsteemi kirjutada jne).

Kaotus:

  • Riigi juhtimine klassis
  • Andmete kapseldamine
  • Ühtne rakendamine
Funktsioon on lihtsalt erisuhe selle sisendi (te) ja vastava väljundi vahel.

Funktsionaalses programmeerimises eraldame andmed koodist selgelt, st pakume funktsioone, mis suudavad võtta mis tahes argumente, tegutseda nende põhjal ilma kõrvalmõjusid tekitamata ja tagastada tulemus nõutud funktsionaalsuse põhjal: Teisisõnu, funktsioon on lihtsalt erisuhe sisendi (te) ja vastava väljundi vahel.

OO programmeerimisel on mõtteviis siiski täiesti erinev, objektid on nagu pärismaailma objektid, kui soovite: Proovime modelleerida oma probleemivaldkonda objektide osas, mis sisaldavad andmeid (tähistab seda, mida objekt tunneb) atribuutide kujul või väljad, käitumine kui meetodid (mida nad saavad teha) ja ühendused (keda nad teavad). Tegeliku domeeni modelleerimine võiks selles osas olla lihtsam, kuid andmed on tihedamalt ühendatud klassi ja klassi hierarhiaga. Objektide rühma andmete esindamine võib vajada täiendavaid klassimääratlusi. Näiteks andmete edastamiseks peame sageli tutvustama DTO-sid (andmeedastusobjekte), et kaardistada objektid andmetele ja vastupidi.

Võib-olla mõnes teises postituses saan ma uurida nende kahe erineva paradigma plusse ja miinuseid. Kuid praegu pean lihtsalt rõhutama, et mõlemal lähenemisviisil on plussid ja miinused. Nagu teate, on JavaScript (ja selle alamkomplektina TypeScripti) mitme paradigma programmeerimiskeel, mis toetab nii funktsionaalseid kui ka objektorienteeritud stiile. Fakt on see, et kood, mille me loome, või koodid, mis juba päriselus on, koosnevad enamasti mõlemast. Seetõttu peaksime programmeerijatena olema teadlikud mõlema stiili plussidest ja miinustest ning vastavalt leidma oma probleemivaldkondadele sobiv lahendus.