-----------------------------------

jonos

Sun Mar 21, 2004 12:00 am


OOP

-----------------------------------

I've heard this quite often, and I've heared of OOT and about Java being object oriented and same with c++. can anyone clarify what this means? I've read some stuff on other pages, but it doesn't make a lot of sense.


-----------------------------------

Dan

Sun Mar 21, 2004 12:05 am



-----------------------------------

OOP = clases

OOP = object oriented progaming

java has to be OOP, c++ can be and c can not. turing has classes but the way they do it is a bit odd.


-----------------------------------

jonos

Sun Mar 21, 2004 12:08 am



-----------------------------------

ahh, what are classes?


-----------------------------------

Dan

Sun Mar 21, 2004 12:15 am



-----------------------------------

kind of hard to explaine off the top of my head and at 12 at nigth.

may be this page can help:

http://java.sun.com/docs/books/tutorial/java/concepts/


-----------------------------------

wtd

Sun Mar 21, 2004 12:44 am



-----------------------------------

Classes are a sort of blueprint for objects.  They provide the two pieces of information about objects that are critical to object-oriented programming.

What does an object have.

What can an object do.

Object-oriented programming is more a way of thinking than a language extension.  You can write object-oriented assembly code if you really want to.

It's a way of thinking where you think about the things you're manipulating in your program and organize the rest of the program around it.  You then make these things into nice little packages with a consistent interface.  Someone using the objects shouldn't have to know anything about how that little package does anything in order to use it.

Let's say you want a program that has people with names (pretty basic people) who can say hello to each other.

#include 
#include 

class person
{
   // These are things no one else
   // can touch directly.  They're in
   // the "box".
   private:
      std::string name;

   // Things the outside world can
   // interact with.
   public:
      // A construct which accepts
      // a string.  The string initializes
      // the name, but in the interface
      // we don't care about the name
      // of the parameter.
      person(std::string);

      // Since our name is hidden away
      // we need an "accessor" to get
      // to it, preventing direct access. 
      std::string get_name() const;

      // We give ourperson the ability
      // to say hello to another person.
      void say_hello_to(const person&) const;

      // You'll notice the use of "const".
      // This can be used by any action
      // that doesn't change the inner state
      // of our object.

      // Overload the  $name};
	
	bless $self, $class
}

sub name
{
	my $self = shift;
	
	return $self->{"name"}
}

sub say_hello_to {
	my $self = shift;
	my $p    = shift;
	
	print "Hi, ${$p->name}! My name is ${$self->name}\n"
}

package main;

my $bob  = Person->new("Bob");
my $john = Person->new("John");

$bob->say_hello_to($john);
$john->say_hello_to($bob);


-----------------------------------

wtd

Sun Mar 21, 2004 1:19 am



-----------------------------------

Object-oriented programming is more a way of thinking than a language extension.  You can write object-oriented assembly code if you really want to.


nah, you couldn't... because assembly is all direct memory and register access and manipulation. ;)
the language needs to provide the tools for it, because it is more than just a way of thinking. it includes some concepts that you can't do without the propper language constructs.

Well, you can do it, you just can't necessarily enforce it.  My final for my assembly course in college was all object-oriented (using MASM 6.15).  :-)