If you are wondering if OOP is right for a given problem, it probably isn't. Search the internets for "stop writing classes" for a great talk and many blog posts about the abuse of classes in python.
That being said, sometimes it really *is* the best approach, especially if: 1. You need many objects that track the state of ongoing operations. 2. The objects fall nicely into a small number of mostly-but-not-completely identical categories. 3. The objects live for more than a single operation, and do more than a single task, related to one "thing". 4. You've already implemented it using a functional/procedural approach, and the approach is clumsy enough to justify rewriting. I build this thing: https://github.com/isaacs/fstream to create pipeable wrappers for every kind of file system thing that I care about (file, directory, link, and symlink). Then, the dir stream can be piped to another dir, and it'll copy all the properties and contents over. I write that primarily because I needed the functionality for https://github.com/isaacs/node-tar. A tar.Pack object is like a fstream.DirWriter, but instead of writing to a filesystem, it is also a readable stream that emits tar data for each file you add to it. The tar.Entry objects are a bit like the file objects in fstream, so you can pipe a tar.Parse object to a fstream.DirWriter to unpack it, and that's exactly what the tar.Extract object does. (It inherits from fstream.DirWriter, and has-a tar.Parse object.) Then, to do ignore file handling, I extended fstream.DirReader to https://github.com/isaacs/fstream-ignore, and overwrote a few methods so that it'll filter its contents appropriately. Then I extended Ignore to https://github.com/isaacs/fstream-npm, which has all the semantics about what should be included in an npm package (renaming everything to "package/...", excluding symbolic links, responding to ignore files, etc.) So, the latest npm release now can do new Packer(packagedir).pipe(tar.Pack()).pipe(zlib.Gzip()).pipe(fs.createWriteStream("package.tgz")). These objects can all be mixed and matched, don't need to know about one another, and only overwrite the parent functionality that's relevant to their specific case. (Proof of the rule that there is no such thing as mistake-free software, I fucked up and named the start function "_read" because I thought it should be private. So now my classes all have to overwrite the "_read" method, which is a violation of my rule that _-prepended properties and methods are private. I should have corrected it the first time I saw that I was accessing that property, but meh. Discipline is hard.) My approach is to never start with OOP. First do it just functionally. If that works, then great. If that's kind of terrible and frustrating because the problem set matches the list above, and you can clearly see the OO hierarchy that would make it cleaner, then go with OOP. Doing it procedurally at first guarantees that you actually understand the problem well enough to design the correct class hierarchy. Too many mistakes with OOP happen because people rush off to design a pretty family tree, without actually understanding which parts they should be abstracting in which ways. On Thu, Mar 29, 2012 at 09:35, Douglas Martin <[email protected]> wrote: > I also have a blog post on using OO within Javascipt you might check out. > > http://blog.dougamartin.com/2012/01/oo-with-comb-and-nodejs.html > > > On Thursday, March 29, 2012 4:53:10 AM UTC-5, Chirag A wrote: >> >> can anyone pls suggest a NodeJS sample application which implements or >> uses OOP fundamentals. >> >> Thank You > > -- > Job Board: http://jobs.nodejs.org/ > Posting guidelines: > https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines > You received this message because you are subscribed to the Google > Groups "nodejs" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/nodejs?hl=en?hl=en -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
