Concerning the 'O' in OOP.

[Yonzie]

I recently started a Java class that's supposed to introduce us to OOP. Programming in Java is reasonably simple as I've messed quite a bit with PHP (JavaDoc is nice but I'd kill for php-style docs), but the 'object' thing is a bit of a problem.
I know the nonclamenture and I've read the (excellent) explanation on wikipedia (http://en.wikipedia.org/wiki/Object-oriented_programming) which unfortunately didn't really teach me anything new.
The teacher is an old hippie and extremely soft so I can't get anything definite out of him...

Basically, what I need is a "Best practices in OOP" book or similar.

In PHP, I learned to use functions, and methods can be used in much the same way, but this isn't really very object-oriented, right?
foo = multiplyByFive(2); // foo = 10

I guess the "proper" OOP way would be something like this:
foo = new Multiplication(2); // object = 2
foo.multiplyBy(5); // object multiplied by 5 (=10)
result = foo.getValue(); // returns value

I could also make the multiplyBy method return a value directly, and not bother with the object except as a variable, but I guess that's not exactly the right way to do it?
It seems so much simpler though...
Someone please set me straight

[rollercoaster375]

I'd do it: (Pardon my lack of Java skill)


foo = new Integer (2);
foo.alter(Math::multiply, 5);
result = foo.getValue();


Where Math::multiply is a constant or a function, depending on what is allowed in Java.

[Yonzie]

What I'm looking for is more general, to what extent I should be focused on objects.
The project we're working on takes a message, converts it to binary, adds error correction, sends it through a "channel" (with errors) and then returns it to text at the end (hopefully the same as was input).
At first, I have a message object. Should I convert the object to binary and then output it (to the encoder), or should i only output the binary value, and not alter the object? When I add the error correction, should it mutate the object or just output the change? That sort of thing ;-)

[Kraetos]

I'm in the EXACT same boat you are: know PHP, learning Java/OOP.

And yes, the way I've been thinking about it is a Java object class is roughly analogous to a PHP function.

[euain]

How about thinking of the object as a some real-world thing that you are modelling. It has a state and certain operations that you can perform on it (encapsulation).

So you have a class "Number".. you want to do certain operations on it, multiply, divide and query its state - getValue(), etc..

How about something like:

public class Number
{
private int theValue;
public Number(int anInitialValue) {theValue = anInitialValue;}
public void multiply(int aFactor){theValue *= aFactor;}
public int getValue(return theValue);
}


And so on..

[thuh Freak]

There are several opinions regarding how OO to be. Some argue that almost everything should be objects, and some think the trade-off should result in maximizing performance (or maximizing re-usability, or ...).

First: An object is not the same thing as a function. A function, aka method, message, procedure, subroutine, (its called different things in diff languages) ..., is a block of named code that is discretely call-able. An object is a run-time instance of a class. A class provides a means of organizing a collection of related functionality (ie, functions), and member variables (i'll ignore shared functions and shared variables for now). A "Dog" class might include the functions "fetch," "bark," "pissOnCarpet". It might contain member variables such as "hairColor," "dateOfBirth," "owner." Fetch, bark and pissOnCarpet would be a series of computer commands which simulate their real-world equivalents via manipulation of variables and providing a UI to the customer. The member variables like hairColor and dateOfBirth represent details that are specific to the instance object. The impl of fetch would probably query the DOB, if the dog is 15yo, it probably won't be so quick to do any fetching; I don't own a dog, but I imagine pups are more likely to piss everywhere compared to a mid-aged dog. There is a bit more to OO, but thats a quick intro.

How much of the project you want to OO and which parts specifically, depend on your individual situation. Yonzie, it sounds like you have a message that needs has operations performed on it, and then it goes over a channel. Since those are the main details I picked out, I imagine at a minimum, your professor is going to want a message class, a convertToBinary class, and a channel class; but convToBin might just as easily be a function of the message (arguments can be made either way). With OO, any piece can be an object, and can accomplish whatever the goal, and deciding depends on what your goal is.

If you want a head-start on some advanced OO ideas, look at the wiki on "Design Patterns." Its a book by the "Gang of Four" which has some very popular and well known strategies for organizing code in an OO fashion. Most of those are overkill for an intro project, but you'll probably impress your teacher if you use those properly.

[Kickaha]

Wow, I'd say:

foo = 5 * 2;

[chucker]

Wow, I'd say:

foo = 5 * 2;

Bingo. Creating functions for this, let alone classes and methods, has more tradeoffs in complexity than advantages (if any).

[thuh Freak]

Wow, I'd say:

foo = 5 * 2;

Too many magick numbers. Better do this:

const int five = 5, two = 2;
int foo = five * two;

[Kickaha]

From my perspective, as someone who mixes OO, functional, procedural, and declarative languages as I need to...

In traditional procedural programming, there is an emphasis on the functions. They are how you do things, after all, and are what all of the early research was on. (Early being the 50s and 60s.) In the 70s, some clever folks decided to flip it around and see what happened when you made the *data* the primary focus. Those are objects.

In procedural programming, you have a suite of functions that do things, and they take data. As you need more things to do, you just keep adding more functions. You can have a gazillion of them, and that's fine - there are only a limited number of data types they can work on, and they are usually designed to work on as many data types as possible. So... many functions, limited data types. Those limited data types are generally the most primitive and common ones, like integers, floats, characters, etc.

Object oriented programming starts with data, and you define the actions that you can perform on that data. Those are your methods. The focus, however, is on the data, so whenever you need to do something new, the tendency is to make a new data type, then define the things you can do on it. Now, for any given data type you might come up, there tends to be a relatively small number of things you can do with it.

So if you step back and think about it, consider an integer. Think about all the possible things you could do with it. The number is *HUGE*. If you were to try and write an Integer class, you'd be adding things on to it for ages, and never really getting it done. ("Real artists ship.")

That's a pretty big hint that this is a case where you should ditch the object-oriented approach, and go for the straight procedural.

[Partial]

What is confusing you about "Object". Is it that all things descend from object and that an object can be made into anything?

Or is it the fact that Object is essentially an abstract data type that is throwing you off.

In my opinion, Java is really, really nice because everything descends from object.

So you could do something like this.

Say you have a Complex Number class.

So, Complex c = new Complex();

c = (Object) c;

If you're having trouble grasping the concept of an Abstract Data Type, maybe try thinking of it this way:

Complex c = new Complex();

c has private data, public data, methods, etc. Think of it as a blob of memory at first, that is kind of how my teacher taught it and he was excellent.

Then, you can call methods using the dot operating.

Take a container for example, we'll call it collection.

Collection c = new Collection();

c.add ( argument );
c.remove() // returns whatever type of "object" (not necessarily an instance of object, but returns whatever is in the container)
c.find(argument);
etc.

Sorry if this is terrible vague. I'm not a teacher, just trying to help.

Some excellent notes from my java class can be read Here. (http://www.uwplatt.edu/csse/Courses/prev/f06/cs243/)

They're available in word documents and they do a much better job explaining the concepts than I do. The first couple "days" of notes are not too helpful because they cover the very, very basic stuff. Once you get into the Date class stuff you start hitting the real meat and potatoes.

[rollercoaster375]

Bingo. Creating functions for this, let alone classes and methods, has more tradeoffs in complexity than advantages (if any).

Well, I was assuming we were attempting to use that as an example. In reality (I should certainly hope) we all know that we shouldn't be using wrapper classes for numbers.

[Ryan]

We just started object-oriented stuff in my computer science class (he doesn't call it that, but it's what it seems to be) and it took me a bit to wrap my head around it, but now it really makes sense.

He's having us write a program that takes a data file with all the current standings in the NCAA and then sorts, modifies and prints it, using objects and procedures.

Or, I'm completely off-base. Which is equally likely. :p

[Kickaha]

roller: Never underestimate the zeal of a student in applying a new concept.

My favorite example is a Hello World that diligently, accurately, and correctly applies design patterns.

It's 37 pages long.

[Dave]

roller: Never underestimate the zeal of a student in applying a new concept.

My favorite example is a Hello World that diligently, accurately, and correctly applies design patterns.

It's 37 pages long.

May I see the source for that? :lol:

(Seriously, I'm curious)

[Kickaha]

I ran across it on slashdot about three years ago. My google fu is weak today, but maybe that will get you enough to get going... :)