ES accessor usage guidelines (Was: Map/Set.prototype.size)

Tab Atkins Jr. jackalmage at gmail.com
Tue Oct 16 14:36:22 PDT 2012


On Tue, Oct 16, 2012 at 2:24 PM, Allen Wirfs-Brock
<allen at wirfs-brock.com> wrote:
> On Oct 16, 2012, at 1:25 PM, Yehuda Katz wrote:
>> Agreed. For example:
>>
>> class Post {
>>
>> }
>>
>> class Comment {
>>
>> }
>>
>> Post.hasMany("comments");
>> Comment.belongsTo("post");
>>
>> let post = new Post()
>> let comment = new Comment();
>>
>> comment.post = post;
>> post.comments //=> [comment]
>
> A great example of where you should not use an accessor. As a rough
> guideline accessors (which are syntactically  models after state attributes)
> should be used to set/query  local characteristics of objects.  Methods
> should be use for complex computations and for establishing and accessing
> complex relationships among objects.  Why? Because experience with complex
> object models have shown that you have more
> understandable/extensible/maintainable systems when you are careful about
> where and how you expose coupling among objects.
>
> In this case, there is a bi-directional n-to-one relationship being
> maintained between objects. Such complex relationships are best modeled
> using methods because their require establishing and maintaining the
> relationship requires state changes in multiple objects. Expressing the
> operation as a method serves as a warning that something more complex than
> simply updating some local state is going on.
>
>
>> This is similar to certain DOM APIs, and my expectation of a hypothetical
>> version of Ember Data in ES6 would work. I don't think there is anything
>> wrong with using an accessor here.
>
> I don't think anybody hold the DOM up as a stelar example of Object-oriented
> design.
>
> You might not agree with the above guideline, or choose to follow it.
> That's fine.  But, what you you propose as an alternative.  What are your
> guidelines for choosing to use an accessor rather than a method?   If you
> consider you example to be a reflection of "good design" what are the
> specific design principles it is following.  Why is that an appropriate
> place to use an accessor.

I consider Yehuda's example to be a perfectly fine and completely
normal place to use an accessor.  *Accessing* the list of comments
attached to a post is conceptually a side-effect-free operation.
While it can change over time, it only does so due to obvious actions
- querying it twice, one immediately after the other, *will* give ===
results.

*Setting* the attribute may have side-effects, but reasonable ones
(setting/unsetting Comments.post or Post.comments on other objects).
This is a reasonable thing for a setter to do.

I don't see any reason to make these two into methods.

~TJ


More information about the es-discuss mailing list