I'm reading through Head First Java and have a general question regarding how to think about objects.
In the begining of the book it mentions a story about two programmers, one using OO and another using procedural. They compete in writing a program that deals with shapes. The procedural programmer creates all the procedures to make the program while the OO guy makes a shape class and abstracts that functionality to specific shapes (square, circle, triangle, amoeba, etc.).
So now I'm on chapter 5, and am trying to think in terms of objects. This chapter starts off writting a 'battleship' type game but instead of sinking battleships you sink 'dotcoms.' It then asks, what objects should be in this program? It then procceds to state that there should be a game class(to run the game in) and a dotcom class. I thought there should be a gameboard class also but the text explains that the gameboard will be virtual, the dotcom class just needs to know its position. So I challenged myself to an exersize to do this samething with a simple tic-tac-toe game. I came up with the following classes:
So tell me, am I thinking in the right direction? I want to make sure I understand how objectst should be thought of.
One of the techniques that people often use in object oriented analysis and design is use cases. Associated with a use case are a number of scenarios, and a scenario consists of a few sentences that mention something that the user can do with the system.
One way to find out which classes are necessary in a program, is by looking at the use cases and scenarios, and noticing the nouns in the text. Those nouns often give you a clue of which classes you're going to need in your program. The mapping is ofcourse not always exactly as simple as that, but it's a starting point.
I think the single biggest mistake many people make early on is deciding that, for example, in a payroll program there should be a PayrollComputer class. The biggest mistake you can make is picking one big huge class that represents the whole system.
Aside from that, it's something you learn with practice. I think the classes you've chosen sound fine as a start except for that "game" class, which sounds too much like a PayrollComputer. Almost nobody gets this right off the top of their head: you pick some classes, write them down, think about how they interact, and then adjust that list based on what you learn. There are many different ways to explore design: Google "CRC cards" for a very common one that I like to use.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
To work out the difference of opinion on GameBoard, try making some CRC cards or communication diagrams on a napkin and see what GameBoard does. See if it turns out to be important or do nothing. You could probably make it go either way ... which do you like better?
BTW: We old guys nearly weep with joy when students want to know more about this than they're getting in class. Keep coming back! Hang out in the OO, UML, etc forum if this kind of thing grabs you.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Thanks for the helpful responses. I'm actually a graduating MIS student and very little time has been spent on the importance of proper object oriented analysis and design so I'm trying to supplement my knowledge. I'll be taking the second half of my SDLC class this semester which will focus on design and implementation so hopefully I'll get a better treatment on the subject then.
Sorry I mad you cry Stan
I do find the whole SDLC interesting and hope to find a job as a systems analyst once i graduate.