Learning OOP Design

I've read Head First Java, and I understand how OOP works. Here's my problem: I'm a PHP programmer, and while I've used OOP in PHP, I'm having trouble figuring out what should be an开发者_开发百科 object and what methods to give it.

For example, let's say I have a app that allows people to log in and edit a document. Why should the document be an object if there will ever only be one instance? Should I give the deleteDocument() method to the document object or the admin object? The document is the one being deleted, but the admin is the one performing the action.

So my real question is, coming from a procedural background, how do I figure out what should be objects and what should have what methods?

Well in your example, I'm not sure why in your design there's only one document, but it should still be an object in case at a later point you want more than one.

As far as the delete function, there's really no straightforward answer; you're likely to find arguments on both sides. Myself, I would put the lower level delete functionality (things like deleting database entries) inside the document class, but any other functionality may go in the parent. If all documents are owned by an admin, the admin should have a DeleteDocument which calls delete on the document, and also removes all associations from the database.

In general, coming from procedural, if you ever find yourself passing around a big array of state variables or declaring lots of globals, then turn that related functionality into a class. Try to keep the functionality that an object contains as closely related as possible, or you may find your classes bloating way out of control.

There's no answer that always holds. If you're interested in object-oriented design, I recommend this book.

As for your question of how to figure out what should be objects and what methods they should have, a good heuristic is to ask yourself if having some ability is essential to being some thing. Here's an example I remember from my OOP class... You're keeping track of people and pets in an application. Should the person class have a getPets() method? Well, is having a pet essential to being a person? No. A better solution might be to have a separate relationship class representing the pet ownership.

It'll depend to some degree on your choice of language. Java is a "pure OO" language, meaning that everything has to be packaged up in classes, like it or not. C++ is "impure" - you could decide that your document will just be a bunch of global variables if you want.

Even in C++, though, you will often package things in classes even though there will only be one instance. That's because a class is more than just a way of packaging arbitrary stuff together - it's an abstraction mechanism. By grouping related things together and giving the groups names, you make your code more readable and maintainable - re-usability is a major benefit, but not the only reason to use a class.

I would check out How do you design object oriented projects. The accepted answer is a good one.

The steps that I use for initial design (getting to a class diagram), are:

Requirements gathering. Talk to the client and factor out the use cases to define what functionality the software should have.

Compose a narrative of the individual use cases.

Go through the narrative and highlight nouns (person, place, thing), as candidate classes and verbs (actions), as methods / behaviors.

Discard duplicate nouns and factor out common functionality.

Create a class diagram. If you're a Java developer, NetBeans 6.7 from Sun has a UML module that allows for diagramming as well as round-trip engineering and it's FREE. Eclipse (an open source Java IDE), also has a modeling framework, but I have no experience with it. You may also want to try out ArgoUML, an open source tool.

Apply OOD principles to organize your classes (factor out common functionality, build hierarchies, etc.)

So my real question is, coming from a procedural background, how do I figure out what should be objects and what should have what methods?

Having gained some understanding of the mechanics of OOP from Head First Java, I'd recommend that you now look into a few of the principles of good OO design. There is a lot of material out there on the web, good and bad, but if you enjoyed Head First Java then I recommend you pick up a copy of the excellent Head First OO Analysis & Design. It'll answer a lot of your questions and contains some excellent examples of scenarios like the ones you touch on here.

After you've tackled that, you might want to look at the SOLID principles, and then (as someone else here has already recommended) some common OO design patterns.

'Document' is a special type of object - an entity. The fact that it may be persisted or removed from storage is a separate concern, that should be handled by some other class in what some call the "data access layer". Your business classes (hope you have some) will use the entity, dal and other classes to perform your business functions.

It goes well beyond that, with the introduction of interfaces and generics.

DeleteDocument should go to the admin object.

You use it because it's less faffing - and better Intellisense, more flexible, etc. Also, it's got threading benefits.