NYCPHP Meetup

[Brian O'Connor]

Last year I took our introduction to OOP (not called that, but that's what
it was), and they explained the difference between classes and objects quite
well.

Although some people consider them interchangeable terms, they're actually
different.

The analogy I like to use is that a class is like a blue print for a
building, and an object is a building that is created using that blue
print.  The class is a plan for how to make it, where as the object is the
result of that plan.

Hope that helps

- Brian O'Connor

On 6/14/07, Rob Marscher <rmarscher at beaffinitive.com> wrote:
>
> Hey David,
>
> A couple quick things I thought I'd point out:
>
> On Jun 13, 2007, at 11:09 AM, David Krings wrote:
> > Unlike objects, I have no idea what classes can do and are there
> > for, although I haven't really used either (I used a few objects,
> > such as the zip object).
>
> Classes are actually the way that you define objects.  So they're
> really the same thing and you'll often see the terms used
> interchangeably.  So somewhere out there (in this case, probably
> written in C and compiled into the zip extension), there is a class
> that defines the zip objects you've been using.  Here's a quick example:
>
> class ZipArchive
> {
>    protected $file;
>
>    public function open($filename)
>    {
>      echo "code to handle reading $file would go here";
>      return true;
>    }
>
>    // etc...
> }
>
> So that's the class... but as soon as you do this:
>
> $zip = new ZipArchive();
> $zip->open('somefile.zip');
>
> $zip is an object.  Does that make sense?  I'm sure the books will
> lay it all out, but just thought I'd clarify the class vs. object thing.
>
> On Jun 13, 2007, at 1:34 PM, David Krings wrote:
> > I am more interested in improving the maintainability of my code. I
> > often do not anticipate what I might want to do and when I add
> > functionality I often find myself creating code that is only
> > slightly different from existing code. I sometimes manage to
> > simplify and externalize into functions that can be included when
> > needed, but something tells me that there might be a better way.
>
> This process of simplifying and combining code to be reusable is
> called "refactoring" and it's one of the best skills a developer can
> possess.  Googling "refactoring php" will bring up a few articles.  I
> also saw that the June 2006 issue of php|a has an article on
> refactoring your procedural code (functions) into object-oriented
> code (classes/objects).  I haven't read it though so I can't comment
> on how good it is or easy to understand but here's a link to get it:
> http://www.phparch.com/issue.php?mid=82
>
>
> Later,
> Rob
>
>
>
>
> _______________________________________________
> New York PHP Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> NYPHPCon 2006 Presentations Online
> http://www.nyphpcon.com
>
> Show Your Participation in New York PHP
> http://www.nyphp.org/show_participation.php
>



-- 
Brian O'Connor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20070620/93cb56d5/attachment.html>