On Tue, Oct 16, 2012 at 2:24 PM, Allen Wirfs-Brock <[email protected]> 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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
