StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
1343881
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
5
CommunityOwnedDate
CreationDate
2009-08-27T21:40:08.210
FavoriteCount
0
LastActivityDate
2017-03-31T13:49:13.437
LastEditDate
2017-03-31T13:49:13.437
LastEditorUserId
42223
OwnerUserId
8815
ParentId
1343619
PostTypeId
2
Score
77
ViewCount
0
LastEditorDisplayName
text
Body
OOP is not only about how a single class looks and operates. It's also about how instances of one or more classes work together. That's why you see so many examples based on "Cars" and "People" because they actually do a really good job of illustrating this principle. In my opinion, the most important lessons in OOP are encapsulation and polymorphism. Encapsulation: Coupling data and the logic which acts on that data together in a concise, logical manner Polymorphism: The ability for one object to look-like and/or behave-like another. A good real-world example of this would be something like a directory iterator. Where is this directory? Maybe it's a local folder, maybe it's remote like an FTP server. Who knows! Here's a basic class tree that demonstrates encapsulation: <pre><code><?php interface DirectoryIteratorInterface { /** * @return \Traversable|array */ public function listDirs(); } abstract class AbstractDirectoryIterator implements DirectoryIteratorInterface { protected $root; public function __construct($root) { $this->root = $root; } } class LocalDirectoryIterator extends AbstractDirectoryIterator { public function listDirs() { // logic to get the current directory nodes and return them } } class FtpDirectoryIterator extends AbstractDirectoryIterator { public function listDirs() { // logic to get the current directory nodes and return them } } </code></pre> Each class/object is responsible for its own method of retrieving a directory listing. The data (variables) are coupled to the logic (class functions i.e, methods) that use the data. But the story is not over - remember how I said OOP is about how instances of classes work together, and not any single class or object? Ok, so let's do something with this data - print it to the screen? Sure. But how? HTML? Plain-text? RSS? Let's address that. <pre><code><?php interface DirectoryRendererInterface { public function render(); } abstract class AbstractDirectoryRenderer implements DirectoryRendererInterface { protected $iterator; public function __construct(DirectoryIteratorInterface $iterator) { $this->iterator = $iterator; } public function render() { $dirs = $this->iterator->listDirs(); foreach ($dirs as $dir) { $this->renderDirectory($dir); } } abstract protected function renderDirectory($directory); } class PlainTextDirectoryRenderer extends AbstractDirectoryRenderer { protected function renderDirectory($directory) { echo $directory, "\n"; } } class HtmlDirectoryRenderer extends AbstractDirectoryRenderer { protected function renderDirectory($directory) { echo $directory, " "; } } </code></pre> Ok, now we have a couple class trees for traversing and rendering directory lists. How do we use them? <pre><code>// Print a remote directory as HTML $data = new HtmlDirectoryRenderer( new FtpDirectoryIterator('ftp://example.com/path') ); $data->render(); // Print a local directory a plain text $data = new PlainTextDirectoryRenderer( new LocalDirectoryIterator('/home/pbailey') ); $data->render(); </code></pre> Now, I know what you're thinking, "But Peter, I don't need these big class trees to do this!" but if you think that then you're missing the point, much like I suspect you have been with the "Car" and "People" examples. Don't focus on the minutiae of the example - instead try to understand what's happening here. We've created two class trees where one (<code>*DirectoryRenderer</code>) uses the other (<code>*DirectoryIterator</code>) in an expected way - this is often referred to as a contract. An instance of <code>*DirectoryRenderer</code> doesn't care which type of instance of <code>*DirectoryIterator</code> it receives, nor do instances of <code>*DirectoryIterator</code> care about how they're being rendered. Why? Because we've designed them that way. They just plug into each other and work. This is OOP in action.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POPHP: Real world OOP example
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. USdreftymac
UserOwnerUserId
1. USPeter Bailey
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POPHP: Real world OOP example
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
3. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTAcceptedByOriginator
CommentsPostId

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.