Object Oriented Programing VERY CONFUSING

Discussion in 'Mac Programming' started by seriypshick, Aug 29, 2005.

  1. seriypshick macrumors member


    Apr 4, 2005
    Today, I started learning Objective-C. I think it's very confusing.
    Anyways here are my questions:

    What are instance variables? Does it have another name "properties"?

    methods = functions? Did I get this right?

    Is there a difference between class and object? Or....

    What is a class? class - collection of methods(functions), right?

    What is an object then? object - copy of class, right?

    What's the difference between instance and object?

    What's a parent class? (Totally confused with this one.)

    @interface, @implementation - do these have some special meaning? How are they different.

    P.S. English is my third language. Maybe that's the reason why I don't get this stuff. Also, I know some C.
  2. superbovine macrumors 68030


    Nov 7, 2003
  3. plinden macrumors 68040


    Apr 8, 2004
    You should invest in a general object oriented book (ie. not related to any particular language)

    You could call them that, but the proper term is instance variables.

    The proper term for a function that's part of a class is "method".

    An object is a concrete instance of a class. Example - "mammal" is a class, "Simba" from "The Lion King" is an instance of "mammal" (actually an instance of "lion" but that comes later)

    A class is more than just a collection of mehods and variables. It should provide a complete description of an object. i.e everything needed to create a concrete instance of the class.

    No, an object is a concrete instance of an class. Like "Simba" is a "lion" and is a concrete instance. But "lion" doesn't have an existence in itself. You can point at "Simba" and say, "that's a lion", but the object itself is "Simba"

    Well, you normally don't use instance on its own. Object = "instance of class"

    Referring back to my "mammal" example above - "mammal" is the parent "cat" which is the parent of "lion", "tiger", "leopard" etc.

    An interface provides a description of what a class should do. For instance, I work with email software. I might have an interface Mailbox which provides the definition of what a Mailbox should be, but until I have an implementation of Mailbox, I can't do anything with it. So I write two implementations, PopMailbox and ImapMailbox. These classes "implement" the methods defined in the interface. Now, I can pass instances of PopMailbox and ImapMailbox throughout my code as Mailboxes and don't have to worry elsewhere in the code what exactly the type of Mailbox I'm working with, since the underlying implementation handles the differences.
  4. Linkjeniero macrumors 6502

    Jan 6, 2005
    I can't answer everything because I don't know Objective-C, but I do know OO programming, so I know the general stuff (I won't answer in the order you asked to make it more undestandable ):

    A class is a "kind" of object, something that identifies an object; therefore, objects are instances of a class. A class is NOT a set of methods; it has methods, but it's defined by its contents.
    For example, think of cars: Car would be the class, and any car you see in the street, an object, instance of the Car class. In Java:
    class Car { //this is the class definition
    String brand; //these are the attributes
    String model;
    int year;

    Car (String b, String m, int y) { //this is the class constructor. If you haven't seen this in Objective-C, then don't worry about it

    boolean old() { //this is a method
    if (this.year<2005) return TRUE;
    else return FALSE;

    Methods are like functions, except they apply to a single object (instance of its class). For instance, imagine that you have a the Car class has the old() method, that returns TRUE if the year was made before 2005:

    Car my_ferrari= new Car("Ferrari","Testarrosa",1999); //this creates an instance of the Car class and stores it in the my_ferrary variable

    boolean isItOld?= my_ferrari.old(); //this evaluates the old() method in my_ferrari, and returns the boolean FALSE

    Parent classes come from inheritance. In OO, classes can be "child" of others, meaning that they inherit all their properties, and then some more. For instance:

    Class CityCar extends Car {
    int length;

    CityCar (String b, String m, int y, int l) {
    super.brand=b; super.model=m; super.year=y; //not sure about this notation

    boolean isSmall() {
    if (length<4) return TRUE; //I think in meters :p
    else return FALSE;

    In the example, the class CityCar inherits all of Car attributes and methods, and then adds more. A CityCar is a Car, but not the other way around; the same way a Mini would be a city car, but the Ferrari isn't a CityCar:
    CityCar my_mini= new CityCar("Austin","Mini",2000,3.5);
    boolean b= my_mini.old(); //this is correct, because the Mini is a Car
    boolean c= my_ferrari.isSmall(); //this is incorrect, because the Ferrari is not a CityCar

    An interface is simply a class that has no defined methods, therefor is only useful to be inherited (an empty shell, so to speak).

    I hope this made thigs a little clearer, though I doubt it... post your thoughts
  5. crees! macrumors 68000


    Jun 14, 2003
    Your best bet is to do a lot of reading or take a class at a local school or college.
  6. seriypshick thread starter macrumors member


    Apr 4, 2005
    Thanks, Everyone. I think I got it now.

    Just want to double check on theese:
    Class - Where you define methods variables, or something like blueprint for objects.
    Object = Instance of class(or copy of class) + you can send variable to objects like we do w/functions. The diference is syntax.
    function(varable1, variable2);
    [objectName getVariableX: variable1]
    [objectName getVariableY: variable2]
    Did I get it right?
  7. HiRez macrumors 603


    Jan 6, 2004
    Western US
  8. HiRez macrumors 603


    Jan 6, 2004
    Western US
    Yes, a blueprint is a good way to think of what a class is. It's a template from which you create usable objects, but you generally don't use the blueprint itself. Each instance you make from the class definition has its own, independent variables.
    That's pretty much it, but when you call a method, you call the method on one particular object. Other objects of the same type will have the same method, but only the one in the object you specified gets called, and anything that happens there only affects that object (unless you tell it to do otherwise in your code).

    If you are using Objective-C, "getter" methods that return values of instance variables are usually the same as the varaible itself (the method named "blob" would return the value of the variable blob), and "setter" methods usually take the form "setBlob", with that capitalization. If you're using Cocoa, it's very important to adhere to this syntax exactly. You generally use the prefix "get" only when you need multiple return values and choose to set them directly into the variables passed into the method. For instance, to get RGB color components from an NSColor object, the method is:
    - (void)getRed:(float *)red green:(float *)green blue:(float *)blue alpha:(float *)alpha
    and you would call it like:
    float red, green, blue, alpha;
    NSColor myColor = [NSColor purpleColor];
    [myColor getRed:&red green:&green blue:&blue alpha:&alpha];
  9. caveman_uk Guest


    Feb 17, 2003
    Hitchin, Herts, UK
    If you're looking for a book...and I think you might need one. I'd recommend this one
  10. seriypshick thread starter macrumors member


    Apr 4, 2005
    Thanks, everyone. I think I pretty much got it now.

    Yes, that's the one that I'm using.
  11. whooleytoo macrumors 604


    Aug 2, 2002
    Cork, Ireland.
    Others have answered your questions above, I'll just add on my bit of advice here. Don't get too hung up on the terminology, it's far more important to understand the concepts and the reasons behind OOP.

    Perhaps its easiest if you take an example: let's say you are writing a new address book. You probably will create a new class called "Person" (or 'PersonalDetails' or...), with member variables (name, address, phone number etc), plus methods to set and retrieve these variables (name, getName etc.) plus perhaps to write them to disk/read from disk.

    Now, you have effectively created a new 'data type' called Person, which also includes (encapsulates) the code to manage that data. This "encapsulation" is one of the key advantages of OOP. What if you wanted to change the phone number variable to store numbers in international format, you probably just need to change the phoneNumber, setPhoneNumber methods. If you weren't using OOP/classes, you'd probably need to scour your entire project and change every single function that references the phone number variable.

    Every time you create a Person object (or "instance of the Person class"), then each object has its own member data/variables.

    Parent Classes
    You also asked about parent classes. Let's imagine you wanted your address book to contain more detailed info, such as job titles & project info for each of your work buddies, and instant messaging addresses and photos for your other friends.

    You could create two new classes from scratch Colleague and Friend, but that would be a bit wasteful - both would be almost identical (both have names, addresses, phone numbers etc.), so you're doing the same work twice.

    Instead, what you would do is subclass Person twice. When you create the Colleague class, you specify it's a subclass of Person. It then gains (inherits) all the member data and methods from Person, so you just need to add in the bits that are specific to Colleague (i.e the member variables for job title, project info and the methods to get/fetch them). Likewise, with Friend.

    In that case, Person is the parent class (or "superclass") of Colleague and Friend; and Colleague and Friend are the child classes (or "subclasses") of Person. (I wish I hadn't used people as my example, it's just getting confusing now! :D)

    Functions / Methods

    Some important points about functions & methods.

    Functions in C (or C++ or Objective C) take the following form;

    draw(myWindow) ;


    error = draw(myWindow) ;

    or if it has several parameters:

    error = draw(myWindow, size, position) ;

    However, C doesn't have the concept of methods, while the syntax of C++ and Objective C methods are quite different.

    In C++, the syntax for methods is similar to functions:

    myWindow->draw() ;

    and if it had several parameters:

    myWindow->draw(size,position) ;

    In Objective C, the syntax for methods is radically different:

    [myWindow draw] ;

    and if it had several parameters, it might be:

    [myWindow drawWithSize: size atPosition: position] ;

    Don't forget, even when writing an OO program in C++ or Objective C, you still can call C (non OOP) functions. For instance, up until recently, most of QuickTime functionality was available as a huge number of loose functions, rather than as a collection of classes as it is in Tiger. So, an Objective C, QuickTime program would have been a mixture of lots of Objective C method calls and QuickTime function calls with their different syntax.
  12. VanMac macrumors 6502a


    May 26, 2005
    Rampaging Tokyo
    For OO concepts, get a book.

    Grady Booch wrote an awesome one. Has some smalltalk and C++ examples, but focuses more on the concepts of OO rather then programming.

    Here is link to book.

    The will give you a great understanding of OOA/OOD. You can then get books specific to the language you want to program in. I would recommend Java, as it is Object Oriented, easier then C++, and an abundance of resources.

    Most of all, have fun, and enjoy your learning.
  13. devman macrumors 65816


    Apr 19, 2004
    I'd say at the level your questions are, get yourself a copy of David Taylor's excellent "Object Technology: A Manager's Guide." Get the 2nd Edition. This book is widely viewed as the classic introduction. From there you could go onto some of the other books people here have referenced.

Share This Page