Class Design - Project 1

Way to many classes in my opinion.

In this case; Is a wall an object in itself or is it part of a room? Is N, E, S, W, classes or are they part of the room?

What does your app do? Does it make a maze or does a separate class do it?

No idea what the RoomBuilder class is suppose to do.

Now this is just an opinion, and there are many other ways to do it.

Is your design wrong? That all depends. Is it over complicated, yes. Can you do what you need to do using, yes.

theTroll

I don't think that's way too many. It's maybe too many. Once again though: (for a beginner) make it work, then make it readable, then make it flexible, then make it performant.

Mine is currently running around 300 without the code to actually generate the mazes. Though line count will vary from person to person based on verbosity and design and amount of spacing.

I'm at the beginning of chapter 14. So I still have these last two chapters(14 & 15) to read before I begin the project.

But I am wondering ahead of time. What thoughts do you guys go through when you begin a project? How do you look at what you are about to do with a program and decide whether you'll need a class, or a class and some objects, or what-have you?
I'm asking because even though I'm not ready to start the project yet(I think I have a critical 2 chapters I must read first) I am wondering how to begin it.
I believe there was an idea about how to know if you need objects or something to that extent.
Was it something like; Nouns are objects and verbs are methods, and maybe adjectives were properties?

Well I might need to repost this into a thread of it's own under the project forum for more input but this thread got me started thinking along those lines of preparation.

Quote:

Original post by foolios What thoughts do you guys go through when you begin a project?

Generally I spend some dead time (commuting, shower, that time where you're waiting to go to sleep, waiting for food to cook, etc) and ponder the problem at hand. I'll run different vague approaches in my head until I feel good about the problem and how I'll approach it.

Different people work differently though. Some people do better with writing things out, some people do well with flowchart sort of things. Some people do better just knocking out code and 'evolving' it into the end product.

Quote:

How do you look at what you are about to do with a program and decide whether you'll need a class, or a class and some objects, or what-have you?

These days, it's not that fine grained. There are patterns that I've implemented before and large blocks of problems will be judged on how they vary from that base pattern. I don't particularly think, "oh I'm going to need about... 5 classes for this problem." I think "oh, this is that pattern where there's nodes connected by paths, how is this particular problem unique?" Once started, there will be more thought on the actual class layout.

Quote:

Was it something like; Nouns are objects and verbs are methods, and maybe adjectives were properties?

Yes, something like that. It's good enough to go on to start. Program design is something that is very dependent on experience; knowing what works, what doesn't and why.