This week's book giveaways are in the Jython/Python and Object-Oriented programming forums.
We're giving away four copies each of Machine Learning for Business: Using Amazon SageMaker and Jupyter and Object Design Style Guide and have the authors on-line!
See this thread and this one for details.
Win a copy of Machine Learning for Business: Using Amazon SageMaker and JupyterE this week in the Jython/Python forum
or Object Design Style Guide in the Object-Oriented programming forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Paul Clapham
  • Jeanne Boyarsky
  • Knute Snortum
Sheriffs:
  • Liutauras Vilda
  • Tim Cooke
  • Junilu Lacar
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Joe Ess
  • salvin francis
  • fred rosenberger

Employee pay - OOP design

 
Ranch Hand
Posts: 470
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:

Employee (to contain basic details like name, age, income etc.)
Payslip (to contain the values for income, tax etc.)
some util class that can contain the logic to compute tax, net amount etc.

My aim is to make this as OO as possible and hopefully even learn using some patterns if possible here, however I am unable to come up with any more classes than the above for now.

Any ideas to get me thinking along the right lines would be greatly appreciated!
 
Marshal
Posts: 67533
257
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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)?
 
Sheriff
Posts: 14764
245
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Junilu Lacar
Sheriff
Posts: 14764
245
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.
 
Prasanna Raman
Ranch Hand
Posts: 470
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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)?



Maybe I can have an enum for distinguishing salaried from hourly?

For money, I am just using BigDecimal.

Should payTo date be an attribute in the pay slip?

So should I have both pay and pay slip? I thought pay was diverse as an attribute of employee.

Can you please explain what reording pay rates means?
 
Prasanna Raman
Ranch Hand
Posts: 470
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.



Thank you Junilu. My thoughts are along the same lines. I am only to hoping to start small and then maybe refactor a few times thereby accidentally identifying some smells and end up using patterns..
 
Prasanna Raman
Ranch Hand
Posts: 470
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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.



These behaviours are what I started thinking of, and then came up with the above classes to cover these. But I'm not sure how else I can break it up.
 
Junilu Lacar
Sheriff
Posts: 14764
245
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Prasanna Raman wrote:These behaviours are what I started thinking of, and then came up with the above classes to cover these. But I'm not sure how else I can break it up.


Those are just initial, large grained ideas for behaviors. From here, I still would hold off from trying to identify classes yet. That's like jumping from step 1 to step 5 without going through the learnings you get from doing steps 2-4 first.

So, starting with a payslip, I'd like to identify the information I need to print/display. Again, I'm thinking about what would eventually be encapsulated in an object but I'm not worried about what object that is yet. I have to get a better idea of what bits and pieces (attributes and methods) I'm trying to organize first before I start worrying about the buckets (classes/objects) I'm going to put them in.

I do the same for information I need to remember about an employee.

Sure, this probably suggests that I'll have a Payslip class and an Employee class but I keep those thoughts in the back of my mind for now.
 
Prasanna Raman
Ranch Hand
Posts: 470
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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)?



Hello Campbell, could you please elaborate on these?
 
Campbell Ritchie
Marshal
Posts: 67533
257
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Prasanna Raman
Ranch Hand
Posts: 470
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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?



Thank you.


Maybe I can have an enum for distinguishing salaried from hourly? Would that be ok?

For money, I am just using BigDecimal. Do I need a separate class?

Should payTo date be an attribute in the pay slip?

Will having a Pay and payslip class make it easier to modify later? Unable to come up too many scenarios.
 
Campbell Ritchie
Marshal
Posts: 67533
257
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Those things are all for you to decide. Maybe pay to date is an attribute of the employee object instead. You will have to decide.
I think yes, BigDecimal will do nicely for money.
 
Prasanna Raman
Ranch Hand
Posts: 470
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you. Do you think using enum would be a good way to make that distinction?
 
Campbell Ritchie
Marshal
Posts: 67533
257
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Which distinction? Are you at a stage of design advanced enough that you can consider such implementation details?
 
Junilu Lacar
Sheriff
Posts: 14764
245
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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
Marshal
Posts: 67533
257
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:. . . simply doing what he knows. Design is not an easy thing . . .

Aaaaaaaaaaaaaaaaaaaah! Thank you.
 
Prasanna Raman
Ranch Hand
Posts: 470
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

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)



Thank you Campbell and Junilu. I think I need the following based on my understanding so far:

1) A way/thing to record employee name and annual salary
2) A way /thing to record pay rates
3) A way to calculate the pay based on pay rates
4) A way/thing to generate and display the payslip
5) A way to keep track of monthly vs other durations for payslip
6) A way to record if an employee is salaried vs hourly (MAYBE, but I don't know how to design so that it can be optional)

Are the above sufficient?

Now that I have the above, I am thinking the below classes (or should I still not think in terms of classes?):

1) Employee - to record employee information
2) Not sure how to record pay rates
3) Maybe a Pay class to record the pay information
4) A payslip class to print or generate
 
Junilu Lacar
Sheriff
Posts: 14764
245
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Prasanna Raman wrote:Are the above sufficient?


I don't think we would be the right ones to say whether or not those are sufficient. Does that look more or less complete to you? If it's everything you think is essential to support the functionality you want to develop then it's probably good enough for now.

Now that I have the above, I am thinking the below classes (or should I still not think in terms of classes?):

1) Employee - to record employee information
2) Not sure how to record pay rates
3) Maybe a Pay class to record the pay information
4) A payslip class to print or generate


It's fine to think about classes but look at the steps I laid out before. After you identify what information you need to support functionality, you would start laying out the steps, the series of actions and maybe interactions that need to happen to perform the task. Once you have a good idea of what those are, then you can start experimenting with how you would assign those actions and the responsibility of managing the information that supports those actions.
 
Junilu Lacar
Sheriff
Posts: 14764
245
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Prasanna Raman wrote:Are the above sufficient?


I don't think we would be the right ones to say whether or not those are sufficient. Does that look more or less complete to you? If it's everything you think is essential to support the functionality you want to develop then it's probably good enough for now.

Now that I have the above, I am thinking the below classes (or should I still not think in terms of classes?):

1) Employee - to record employee information
2) Not sure how to record pay rates
3) Maybe a Pay class to record the pay information
4) A payslip class to print or generate


It's fine to think about classes but look at the steps I laid out before. After you identify what information you need to support functionality, you would start laying out the steps, the series of actions and maybe interactions that need to happen to perform the task. Once you have a good idea of what those are, then you can start experimenting with how you would assign those actions and the responsibility of managing the information that supports those actions.
 
Prasanna Raman
Ranch Hand
Posts: 470
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am stuck on the step of storing tax information. What data structure etc.?

Obviously, income tax is in slabs, so I need to be able to store like the following:

$0-$5k - $1000
$5001 - $40k - $1000 + $0.05 for every $1 over $5k
and so on.

What's the best way to store this information?

I am thinking of the following classes:

  • Employee (to store basic employee info)
  • Tax (to store tax related info)
  • Pay (to store pay related info)
  • Payslip (will take an employee and a pay object and generate a payslip)


  •  
    catch it before it slithers away! Oh wait, it's a tiny ad:
    Sauce Labs - World's Largest Continuous Testing Cloud for Websites and Mobile Apps
    https://coderanch.com/t/722574/Sauce-Labs-World-Largest-Continuous
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!