I can give a few somewhat sporadic but I think well founded thoughts for those introducing themselves to object oriented methodology.
Objects represent anything that is generally shared between instances of the application execution, or multiple times within it, but where the instances have something that sets them apart between each other. If all object instances are the same, it is not necessary to have a class, though you may use what I would call a “pseudo class” with static properties, which are really the same for all instances and thus not truly to be thought of as a class of objects.
Objects can be used to compartmentalise your applications, if there are several variants or extensions of object classes, consider extending them. The comparmentalisation makes it possible to have a main outline of the application where different functionality is encapsulated in the different objects. This is very useful when working in a team, since it is sufficient to have this shared outline and interfaces, to be able to distribute work on different objects to different people.
A good practice for a beginner would be to use objects for pages, and then extend their classes for other page variants. That gives practical experience in how you can make use of objects to share and compartmentalise implementation.
You will soon find that some objects are separate from pages, suppose that you have a marketing application or at least marketing functionality and some kind of cart. The cart is a separate kind of object from the application’s pages. So you’d reasonably create a separate cart class. The cart may be made a separate compartment of your program, for example a separate file which you simply include. It needs certain functionality; add, remove, update. This translates into the properties which a cart object has.
The more and clearer your underlying understanding for computer technology and its implications are, the easier you will be able to translate that into object oriented programming methodology and vice versa the latter into these uses.
Don’t put too much into memorising things as someone else has suggested, I’m not even sure off hand if variables or constants that are part of a class are conventionally called properties or attributes. Does it even matter in practice? Roughly I see all member of a class as properties of its objects, including methods. Terminological specificity is certainly relevant so don’t take this a neglecting that, but if you are learning about particular development techniques it is often sufficient to know that something can be done, rather than dedicate time memorising what it is named or what its syntax is. The use of $this and other language constructs and -functions are something you will simply work in, it is related to scope, you should definitely know what scope is.
I will leave the book recommending to others for this subject.
I added a related post here; http://www.sitepoint.com/forums/showpost.php?p=4754651&postcount=4