class Person { constructor (first, last) { this.first = first; this.last = last; } fullName () { return `${this.first} ${this.last}`; }};

class PersonView { constructor (person) { this.model = person; } // ... redraw () { document .querySelector(`person-${person.id}`) .text(person.fullName()) }}

varje gång vi uppdaterar personklassen måste vi komma ihåg att rita om vyn:

const currentUser = new Person('Reginald', 'Braithwaite');const currentUserView = new PersonView(currentUser);currentUserView.redraw();currentUser.first = 'Ragnvald';currentUserView.redraw();

Varför spelar det någon roll?

Tja, om du inte kan kontrollera var vissa ansvarsområden hanteras kan du inte riktigt organisera ditt program. Underklasser, metoder, mixins och dekoratörer är tekniker: vad de möjliggör är att välja vilken kod som är ansvarig för vilken funktionalitet.

och det är det hela med programmering: organisera funktionaliteten. Direktåtkomst tillåter dig inte att organisera funktionaliteten i samband med att få och ställa in egenskaper, det tvingar koden att göra att få och ställa in att också vara ansvarig för allt annat som är förknippat med att få och ställa in.

hämta och ställ in

det tog inte lång tid för JavaScript-biblioteksförfattare att ta reda på hur man gör det här med hjälp av en get och set metod. Avskalad till det väsentliga för illustrativa ändamål, vi kunde skriva detta:

class Model { constructor () { this.listeners = new Set(); } get (property) { this.notifyAll('get', property, this); return this; } set (property, value) { this.notifyAll('set', property, value); return this = value; } addListener (listener) { this.listeners.add(listener); } deleteListener (listener) { this.listeners.delete(listener); } notifyAll (message, ...args) { for (let listener of this.listeners) { listener.notify(this, message, ...args); } }}class Person extends Model { constructor (first, last) { super(); this.set('first', first); this.set('last', last); } fullName () { return `${this.get('first')} ${this.get('last')}`; }};class View { constructor (model) { this.model = model; model.addListener(this); }}class PersonView extends View { // ... notify(notifier, method, ...args) { if (notifier === this.model && method === 'set') this.redraw(); } redraw () { document .querySelector(`person-${this.model.id}`) .text(this.model.fullName()) }}

vår nya Model superclass hanterar manuellt tillåter objekt att lyssna på get och set metoder på en modell. Om de kallas, meddelas ”lyssnare”via .notifyAll – metoden. Vi använder det för att haPersonView lyssna på dessPerson och ring sin egen.redraw metod när en egenskap ställs in via.set metod.

så vi kan skriva:

const currentUser = new Person('Reginald', 'Braithwaite');const currentUserView = new PersonView(currentUser);currentUser.set('first', 'Ragnvald');

och vi behöver inte ringa currentUserView.redraw(), eftersom meddelandet inbyggt i .set gör det för oss.

Vi kan göra andra saker med .get och .set, förstås. Nu när de är metoder kan vi dekorera dem med loggning eller validering om vi väljer. Metoder gör vår kod flexibel och öppen för förlängning. Till exempel kan vi använda en ES.senare dekoratör för att lägga till loggningsråd till .set:

const after = (behaviour, ...methodNames) => (clazz) => { for (let methodName of methodNames) { const method = clazz.prototype; Object.defineProperty(clazz.prototype, methodName, { value: function (...args) { const returnValue = method.apply(this, args); behaviour.apply(this, args); return returnValue; }, writable: true }); } return clazz; }function LogSetter (model, property, value) { console.log(`Setting ${property} of ${model.fullName()} to ${value}`);}@after(LogSetter, 'set')class Person extends Model { constructor (first, last) { super(); this.set('first', first); this.set('last', last); } fullName () { return `${this.get('first')} ${this.get('last')}`; }};

medan vi inte kan göra något liknande med direkt tillgång till egendom. Att förmedla fastighetsåtkomst med metoder är mer flexibelt än direkt åtkomst till fastigheter, och detta gör att vi kan organisera vårt program och distribuera ansvaret ordentligt.

notera: alla ES.senare klass dekoratörer kan användas i vanilj ES 6 kod som vanliga funktioner. Istället för @after(LogSetter, 'set') class Person extends Model {...}, skriv helt enkelt const Person = after(LogSetter, 'set')(class Person extends Model {...})

getters och setters i javascript

problemet med getters och setters var väl förstått, och förvaltarna bakom javascript: s utveckling svarade genom att införa ett speciellt sätt att göra direkt tillgång till egendom till en slags metod. Så här skriver vi vårPerson klass med ”getters” och ” setters:”

class Model { constructor () { this.listeners = new Set(); } addListener (listener) { this.listeners.add(listener); } deleteListener (listener) { this.listeners.delete(listener); } notifyAll (message, ...args) { for (let listener of this.listeners) { listener.notify(this, message, ...args); } }}const _first = Symbol('first'), _last = Symbol('last');class Person extends Model { constructor (first, last) { super(); this.first = first; this.last = last; } get first () { this.notifyAll('get', 'first', this); return this; } set first (value) { this.notifyAll('set', 'first', value); return this = value; } get last () { this.notifyAll('get', 'last', this); return this; } set last (value) { this.notifyAll('set', 'last', value); return this = value; } fullName () { return `${this.first} ${this.last}`; }};

När vi inleder en metod med nyckelordet get definierar vi en getter, en metod som kommer att kallas när kod försöker läsa från egenskapen. Och när vi förord en metod med set, vi definierar en setter, en metod som kommer att kallas när koden försöker skriva till egenskapen.

Getters och setters behöver faktiskt inte läsa eller skriva några egenskaper, de kan göra någonting. Men i den här uppsatsen talar vi om att använda dem för att förmedla tillgång till egendom. Med getters och setters kan vi skriva:

const currentUser = new Person('Reginald', 'Braithwaite');const currentUserView = new PersonView(currentUser);currentUser.first = 'Ragnvald';

och allt fungerar fortfarande precis som om vi hade skrivit currentUser.set('first', 'Ragnvald') med .set-stilkod.

Getters och setters tillåter oss att ha semantiken att använda metoder, men syntaxen för direktåtkomst.

en efterkombinator som kan hantera getters och setters

Getters och setters verkar vid första anblicken vara en magisk kombination av bekant syntax och kraftfull förmåga att meta-program. En getter eller setter är dock inte en metod i vanlig mening. Så vi kan inte dekorera en setter med exakt samma kod som vi skulle använda för att dekorera en vanlig metod.

med.set – metoden kunde vi direkt komma åtModel.prototype.set och linda in den i en annan funktion. Så fungerar våra dekoratörer. Men det finns ingen Person.prototype.first metod. Istället finns det en egenskapsbeskrivare som vi bara kan introspektera med Object.getOwnPropertyDescriptor() och uppdatera med Object.defineProperty().

av denna anledning fungerar inte Na-dekoratörenafter dekoratör som anges ovan för getters och setters.2 Vi skulle behöva använda en typ av dekoratör för metoder, en annan för getters och en tredje för setters. Det låter inte som kul, så låt oss ändra vårafter combinator så att du kan använda en enda funktion med metoder, getters och setters:

function getPropertyDescriptor (obj, property) { if (obj == null) return null; const descriptor = Object.getOwnPropertyDescriptor(obj, property); if (obj.hasOwnProperty(property)) return Object.getOwnPropertyDescriptor(obj, property); else return getPropertyDescriptor(Object.getPrototypeOf(obj), property);};const after = (behaviour, ...methodNames) => (clazz) => { for (let methodNameExpr of methodNames) { const = methodNameExpr.match(/^(?:(get|set) )(.+)$/); const descriptor = getPropertyDescriptor(clazz.prototype, methodName); if (accessor == null) { const method = clazz.prototype; descriptor.value = function (...args) { const returnValue = method.apply(this, args); behaviour.apply(this, args); return returnValue; }; descriptor.writable = true; } else if (accessor === "get") { const method = descriptor.get; descriptor.get = function (...args) { const returnValue = method.apply(this, args); behaviour.apply(this, args); return returnValue; }; descriptor.configurable = true; } else if (accessor === "set") { const method = descriptor.set; descriptor.set = function (...args) { const returnValue = method.apply(this, args); behaviour.apply(this, args); return returnValue; }; descriptor.configurable = true; } Object.defineProperty(clazz.prototype, methodName, descriptor); } return clazz; }

Nu kan vi skriva:

const notify = (name) => function (...args) { this.notifyAll(name, ...args); };@after(notify('set'), 'set first', 'set last')@after(notify('get'), 'get first', 'get last')class Person extends Model { constructor (first, last) { super(); this.first = first; this.last = last; } get first () { return this; } set first (value) { return this = value; } get last () { return this; } set last (value) { return this = value; } fullName () { return `${this.first} ${this.last}`; }};

Vi har nu frikopplat koden för att meddela lyssnare från koden för att få och ställa in värden. Vilket framkallar en enkel fråga: om koden som spårar lyssnare redan är avkopplad i Model, varför ska inte koden för att utlösa aviseringar vara i samma enhet?

det finns några sätt att göra det. Vi använder en universell mixin istället för att fylla den logiken i en superklass:

const Notifier = mixin({ init () { this.listeners = new Set(); }, addListener (listener) { this.listeners.add(listener); }, deleteListener (listener) { this.listeners.delete(listener); }, notifyAll (message, ...args) { for (let listener of this.listeners) { listener.notify(this, message, ...args); } }}, { notify (name) { return function (...args) { this.notifyAll(name, ...args); } }});

detta tillåter oss att skriva:

@Notifier@after(Notifier.notify('set'), 'set first', 'set last')@after(Notifier.notify('get'), 'get first', 'get last')class Person { constructor (first, last) { this.init(); this.first = first; this.last = last; } get first () { return this; } set first (value) { return this = value; } get last () { return this; } set last (value) { return this = value; } fullName () { return `${this.first} ${this.last}`; }};

vad har vi gjort? Vi har införlivat getters och setters i vår kod, samtidigt som vi behåller möjligheten att dekorera dem med extra funktionalitet som om de var vanliga metoder.

det är en vinst för att sönderdela kod. Och det pekar på något att tänka på: när allt du har är metoder, uppmuntras du att göra tunga superklasser. Därför tvingar så många ramar dig att utöka sina specialklasser som Model eller View.

men när du hittar ett sätt att använda mixins och dekorera metoder kan du sönderdela saker i mindre bitar och applicera dem där de behövs. Detta leder i riktning mot att använda samlingar av bibliotek istället för en tungviktsram.

sammanfattning

Getters och setters tillåter oss att behålla den äldre stilen för att skriva kod som verkar direkt komma åt egenskaper, samtidigt som vi faktiskt förmedlar den åtkomsten med metoder. Med omsorg kan vi uppdatera vårt verktyg så att vi kan dekorera våra getters och setters, fördela ansvaret som vi tycker är lämpligt och befria oss från beroende av tungviktiga basklasser.

(diskutera på Hacker News)

Post Scriptum

detta inlägg använder lyssna på egendom setters som en ursäkt för att diskutera getter och setter mekanismer, och sätt att dekorera dem så att vi kan organisera kod kring oro.

naturligtvis är förökningsändringar genom uttrycklig anmälan inte det enda sättet att organisera kod som behöver hantera beroenden på databyte. Det är utanför ramen för detta inlägg att diskutera de många alternativen, men läsarna har föreslagit att utforska objekt.observera och arbeta med oföränderliga data.

en sak till

Rubyists hånar på:

get first () { return this;}set first (value) { return this = value;}get last () { return this;}set last (value) { return this = value;}

function attrAccessor (...propertyNames) { return function (clazzOrObject) { const target = clazzOrObject.prototype || clazzOrObject; for (let propertyName of propertyNames) { Object.defineProperty(target, propertyName, { get: function () { if (this.attributes) return this.attributes; }, set: function (value) { if (this.attributes == undefined) this.attributes = new Map(); return this.attributes = value; }, configurable: true, enumerable: true }) } return clazzOrObject; }}

@Notifier@attrAccessor('first', 'last')@after(Notifier.notify('set'), 'set first', 'set last')@after(Notifier.notify('get'), 'get first', 'get last')class Person { constructor (first, last) { this.init(); this.first = first; this.last = last; } fullName () { return `${this.first} ${this.last}`; }};