Page 1 of 1

Really Basic OOA&D Question

Posted: Mon Sep 10, 2007 6:03 am
by Theory?
I've been searching all over the place for, at bare minimum, an article that attempts to teach OOA&D with a focus on web-oriented programming. I've read a few things on the subject in general, but gearing it towards desktop applications seems a bit more robust and out of scope when trying to apply it to more simplistic web-based applications (I use the term simplistic lightly). I remember coming across an article somewhere that detailed a separation of class-types in terms of classes that do things (actor classes?) and classes that have things done to them (????). What that led me to understand was, in a simple example, if I had a news engine, I would have a class responsible for creating new news items and associating comments with the appropriate items. Then, I would have a separate class that represents a generic post and a generic comment. The problem here is I fumble up on the execution. I don't know if that's the right way of thinking...and if it is, how I go about setting that up. If anyone could give a basic explanation or link to an article/site that does, it would be greatly appreciated.

I'm sure this is a really newbie question, I'm just really having a hard time wrapping my head around it.

Posted: Mon Sep 10, 2007 7:31 am
by superdezign
The actor - object approach to design doesn't so much represent the actor as an object (though it can, it doesn't have to) as the actors are the actual users.

A good way to learn about good OOD is to study into things that focus on Java as they are usually more generic and can give you more of a simplistic view. There are a few approaches, like CRC cards where you write a class and it's methods but they all have to fit on one card or the class is too big, etc. That gets you to abstract, simplify, separate, and think ahead for extensions and such. Also, if you think in terms of real life objects, THEN break those down into more focused objects that would make up that larger object, you can keep your program organized. OOP is popular because it helps us model real-world problems with objects, so that's what you should be doing.

As for your example, a news post would be an object which would do a few things. It'd have it's id given to it upon creation (via a controller, URL, etc.) and use that id to get it's content from the database. This would mean that it'd also need a reference to a database object. After it uses it's database object to get it's content, then it'd use it's id to create a list of comments that are associated with that id. In programming (especially web programming), you hit a dilemma of "proper" OOP versus "efficient" OOP. When creating all of the comments, would you want to give each comment a reference to the database object and let them handle getting their information themselves, or run one query in the news post object and create the comments from that? You could always find a middle ground between them where you use the news post object to get only the ids of the associated comments, and then let the comments handle themselves from there, which would be the closest to "proper" OOP that you could get, in my opinion.

The good thing about OOP is that there isn't one way to go about things. You don't *have* to do the same things that everyone else does. As long as it's comfortable and organized, it should be good. The purpose was to help us program, not force us to think alike. :P

Posted: Mon Sep 10, 2007 1:04 pm
by Christopher
Programming is a craft. It can be explained to an extent but you need to actually do it to learn it. You wouldn't expect any of us to be able to tell you how to be an electrician or airline pilot in a few paragraphs. It takes years to become proficient and then the knowledge keep building.

My advice is to be open to the best practices that you read even though they may seem counter to what makes sense to you right now. Then start solving problem with code. When you have questions on what the best solution to a problem is -- post the code on places like this forum and get input. Then code some more.

Posted: Mon Sep 10, 2007 11:25 pm
by Theory?
superdezign wrote:The actor - object approach to design doesn't so much represent the actor as an object (though it can, it doesn't have to) as the actors are the actual users.

A good way to learn about good OOD is to study into things that focus on Java as they are usually more generic and can give you more of a simplistic view. There are a few approaches, like CRC cards where you write a class and it's methods but they all have to fit on one card or the class is too big, etc. That gets you to abstract, simplify, separate, and think ahead for extensions and such. Also, if you think in terms of real life objects, THEN break those down into more focused objects that would make up that larger object, you can keep your program organized. OOP is popular because it helps us model real-world problems with objects, so that's what you should be doing.

As for your example, a news post would be an object which would do a few things. It'd have it's id given to it upon creation (via a controller, URL, etc.) and use that id to get it's content from the database. This would mean that it'd also need a reference to a database object. After it uses it's database object to get it's content, then it'd use it's id to create a list of comments that are associated with that id. In programming (especially web programming), you hit a dilemma of "proper" OOP versus "efficient" OOP. When creating all of the comments, would you want to give each comment a reference to the database object and let them handle getting their information themselves, or run one query in the news post object and create the comments from that? You could always find a middle ground between them where you use the news post object to get only the ids of the associated comments, and then let the comments handle themselves from there, which would be the closest to "proper" OOP that you could get, in my opinion.

The good thing about OOP is that there isn't one way to go about things. You don't *have* to do the same things that everyone else does. As long as it's comfortable and organized, it should be good. The purpose was to help us program, not force us to think alike. :P
That was actually very concise. Thank you very much. :)