StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
7812205
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2011-10-18T18:56:15.160
FavoriteCount
0
LastActivityDate
2011-10-18T18:56:15.160
LastEditDate
LastEditorUserId
0
OwnerUserId
1001831
ParentId
3383605
PostTypeId
2
Score
0
ViewCount
0
LastEditorDisplayName
text
Body
The ultimate goal is to have an interface which each component agrees upon. So, if, for example, I was building a JavaScript site that was done -entirely- in an old-school MVC (non-Rails/PHP) implementation, and completely in AJAX, I would make sure that each of the components implemented the same interface for observing. In each model/view/controller, I could name my "subscribe" method something completely different. Or, I could implement a standard interface for each. So I can have a public ".Register(event_type, subscribing_class)" method implemented in EVERY single component which could be expected to be called. Likewise, I can have a public ".Update(event_type, data)" method implemented in EVERY single component which could be expected to be called. The .Register and .Update are the interface for my Observer communication. Inside of my classes, each might have a ".Subscribe(publisher, event_type, self_reference)" method. That method might just be: <pre><code>Class.Subscribe = function (publisher, event_type) { var self_reference = this; publisher.Register(event_type, self_reference); }; </code></pre> Each might have an internal .Notify method: <pre><code>Class.Notify = function (type, data) { var subscribers = this.subscribers[type], i = 0, l = subscribers.length; for (; i < l; i++) { subscribers[i].Update(type, data); } }; </code></pre> Because I've agreed that ALL of my communication interface is going to behave this way, it doesn't matter what my internals look like. My Model can continue to be oblivious to my View, and my View can continue to be oblivious to my Controller. The .Notify and .Subscribe don't need to be implemented that way - they aren't a part of the publicly-accessible interface. They could be anything I want. .Subscribe could take an ARRAY of publishers and push it through a for-loop, to subscribe to multiple points of data. Or take an array of { "pub" : x, "type" : y } object literals, and call the .Register method of each one, so that you can get ALL bootstrapping of that Class out of the way with one function call. Same thing goes with making an audio-player app. I don't care what public properties MusicPlayer shares. I know that it uses .Play(), .Pause(), .Stop(), .Load(track). If I make sure that I ONLY use the agreed-upon, public interface methods, the program is going to work. Why? Because the guy who works on MusicPlayer might change the internals of MusicPlayer. He might completely rewrite them. Maybe there's a ._precacheSong(track) method. But what if it gets replaced with ._cueTrack(track) down the road? You're just using some dude's widget, and one day your widget crashes, because you were extending it or implementing it based on non-interface methods or non-interface data, which happened to change as of v1.2.1 So even in Loose Languages, the Interface is important. They give you a map of how you can expect to call ANY component that is expected to have that functionality - and regardless of how the internals of that component work, the inputs and outputs will be the exact same (though more type/error-checking is needed on inputs). They allow you to "Duck-Type" really easily (take a list of different Class instances - fire off the same function call on each one, expecting each has the same method and takes the same data-format). Even better with JavaScript: My .Subscribe code might even be written only once, and then bound to anything that I want to "inherit" it. <pre><code>Interface.Subscribe = function (publisher, evt_type) { var self_ref = this; publisher.Register(evt_type, self_ref); }; Class_1.Subscribe = Interface.Subscribe.bind(Class_1); Class_2.Subscribe = Interface.Subscribe.bind(Class_2); Class_3.Subscribe = Some_Other_Interface.Subscribe.bind(Class_3); </code></pre> And I can do that freely, because I know that everything I want to subscribe to is going to have the same public-interface.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POProgram to an interface not an implementation in php
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USNorguard
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. This table or related slice is empty.
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.