|
|
Ranch Hand Scavenger Hunt
Greenhorn Scavenger Hunt
Junilu Lacar wrote:
Campbell Ritchie wrote:Which distinction? Are you at a stage of design advanced enough that you can consider such implementation details?
I think OP is simply doing what he knows. Design is not an easy thing and when you don't have a lot of experience doing it, breaking things down from large-grained ideas to incrementally smaller ideas can be a daunting task. From the perspective of someone who does have the experience, we can recognize that OP has skipped a few steps. But OP doesn't know what he doesn't know, so there's no way for him to recognize this.
Put all those detailed concerns aside for now, OP, and keep your focus on the behaviors.
Step 1: Identify behavior you want (generate a payslip) DONE
Step 2: Identify information you'll need to produce those behaviors (Maybe DONE)
Step 3: Start detailing out the procedure(s) for producing the behavior (not done)
Step 4: Organize steps and information into classes, methods, attributes (not done)
Step 5: ... (finish the above steps first before we move on)
Campbell Ritchie wrote:They were just ideas for you to consider. Do you have a money class? Do you need one? How are you calculating pay? Does a pay class calculate pay and a payslip simply display it? Or do you want something different? “Reording pay rates” means my C key is misbehaving. Where are you going to record pay rates? Is it an attribute of the employee? Do all employees of a particular grade or job have the same pay rate?
Campbell Ritchie wrote:What classes are you using for money, etc? If you are paying monthly, how are you recording the pay to date? Why have you got payslip and not Pay? How are you reording pay rates? How are you distinguishing salaried people from hourly paid people (wages)?
Junilu Lacar wrote:
Prasanna Raman wrote:I am trying to practice some OOP with a simple problem. Trying to generate payslips given an employee and their annual income.
The classes I could think of are:
So rather than starting with the classes, which I think is like building a barn before you have any idea of what you're going to keep in the barn, I'd start with the behaviors I want the program to exhibit. From what you wrote, these are the minimum:
1. Generate payslips
2. Remember an employee's income (plus any other relevant information)
Now that I have an inkling of what the program must be able to do, I can start digging into these in more detail and start experimenting with ideas on how to organize these behaviors and what should be responsible for doing what.
Junilu Lacar wrote:Here are some tips:
1. You're never going to get it right the first time.
2. OOP is about behaviors and assigning of responsibilities around those behaviors.
3. A good OOP design should be easy to change. If it's hard to change, then something's wrong.
4. Because of all of the above, don't try to model the whole thing up front because then you'll get a LOT wrong instead of just a little bit. Start out simple, understand the behaviors and responsibilities you're assigning, and then refactor when things seem harder to change than they should be when you try to add more behavior.
You're already setting yourself up for failure by trying to come up with more classes before you've even written any code and tried it out.
Another word of advice: instead of trying to learn patterns, learn how to recognize smells first and then how to refactor those smells away. Patterns will be easier to learn if you learn about smells and refactoring first.
Campbell Ritchie wrote:What classes are you using for money, etc? If you are paying monthly, how are you recording the pay to date? Why have you got payslip and not Pay? How are you reording pay rates? How are you distinguishing salaried people from hourly paid people (wages)?
So, who would call the loadDefaultCosts method then?
Number Posts (451/100)
Number Threads Started (58/100)