When designing a class, how do I know ...

[Jay Jones]

When designing a class, how do I know the following?
(1)What fields do I need?
Are there any systematic (scientific, disciplined) ways to figure that out as opposed to the intuitive ways used by those experienced programmers?
(2)Constructors are usually for initializing the fields in a class, but I've seen constructors do far more complicated things than that, such as opening up a database, performing animation, etc. How do I know what the constructors are supposed to do when designing my class?
(3)What parameters do I need for a method? Do I decide on this first before coding the method? Or do I code the method first and then come back to fill in the method signature?
Are there any books that deal with these topics?
I have been bugged by these questions for a long time. I appreciate if you programming gurus can share with us juniors how you overcome these hurdles.

[Cindy Glass]

Fields: You need what ever fields that are required to define the "state" of the object at any given time. To determine this you need to work out all of the things that the object has a "has a" relationship to. Typically during development you find that you have to add fields that didn't occur to you at the beginning.
Constructors:
You need to take in whatever is required to define the initial state of the object. If you are allowing the user of the class to influence the state of the object then you take in the parameters that will define that influence. If you are going to decide the state without the class user, then you don't take in any parameters.
Again, the purpose of a constructor is to create a new functioning instance of the object, so what is done in the constructor is completely defined by what the object IS.
Parameters:
About the same as constructors. You need to know what the method is going to DO and what you are going to allow the method user to influence by passing in parameters.
The bunkhouse at JavaRanch has a whole section on design issues here

[jason adam]

And to over-stress a point that Cindy touched on, be accepting of the idea that your classes attributes/behaviors and interfaces will most likely change, some will change a lot. It's all part of that nifty little thing called abstraction. Programming is as much a creative art as it is a procedural science, especially OOP.
Ok, I'm done with the soap-box
Jason

[William Barnes]

Are there any systematic (scientific, disciplined) ways ...

Don't think of youself as an engineer, you are an artist!

[Jay Jones]

Thank you gurus for the insight. I'll take it to heart in my struggle to be a good programmer.

[Michael Bruesch]

I've worked on my creativity so hard, I have it down to a science

[Jay Jones]

Michael, please share your wisdom traveling from Science --> Art --> Science.
I am still struggling at the first stage, while you have gone far enough and come back a wise man.
Down deep, I am not satisfied with the intuitive and artistic argument about programming. It could be that this argument is easy and less painful to make than going one level down to find out the rules and laws that underline our intuition.
A perfect example would be the Gang of Four's pursuit of design pattern. Before the publication of their book, most experienced programmers know by their intuition something like that exists, but they went a step further beyond. I think we all benefited greatly from their effort.

[Cindy Glass]

In a perfect world, all design should evolve from detailed requirements that should name what needs to be tracked from the end-users perspective. Then it is a matter of adding the fields that are required from a technical perspective until all of the fields to be tracked are identified.
The requirements should also describe the behaviors expected by the end user and additional behaviors will be added as needed to get the requirements met.
Of course the requirements are not going to be written in nice little modules that will conveniently map to classes. So, then comes the most difficult part. Organizing the fields and behaviors that you know you need into well defined classes with well designed relationships. This is where it gets more artistic.

[Michael Bruesch]

Actually, I'm not creative or artistic at all. I agree with what Cindy says, and always do (because she knows more than me), but I feel that I write some excellent code design-wise. I think you can go about design purely logically, its worked for me so far. However, you do have to be "inovative" in your logic as I like to look at it. Some may call this artistic or creative, and maybe I am artistic and just don't know it, but I always take a logical approach to my creativeness.
Did that make any sense at all?
------------------
Michael J Bruesch
Codito, ergo sum...
I code, therefore I am.
http://www.geocities.com/mjbruesch

[jason adam]

Makes total sense, Michael. Being creative/artistic does not imply that there is a lack or disregard for logic, procedure, etc. It simply means that not everything is going to follow some empirical standard, and that you are going to have to come up with some of this from your own intuition. If it doesn't work, scrap it and try something else. Heck, that's what science is all about!
I agree, when approaching the desinging aspects, you want to follow well-established patterns if they fit, or figure a way to slowly infuse your design with those patterns if it isn't readily apparent where they should go. Even XP has precision in their process.
And of course Cindy is right (imagine that ), the design of your classes is going to be based on the requirements. Don't go throwing stuff in there that isn't needed. But in the real world, you get these general statements from the user what is expected, and it's up to you to decipher what they really need and how to implement it.
I don't think the nature of software development would allow for any step-by-step approach to designing a class. Sure, you can come up with some high-level processes, but the environment and requirements change so often that you'd have to constantly come up with new formulae to fit the situation, which I personally don't see the benefit of.
Didn't know my artsy comment would raise such a ruckus
Jason

[Wilfried LAURENT]

Originally posted by Cindy Glass:
In a perfect world, all design should evolve from detailed requirements that should name what needs to be tracked from the end-users perspective.

In a perfect world, you would have only to identify and comment use-cases, then run a module on it and implementation would be done! But would it really be a perfect world?
W.