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!

Prasanna Raman

Ranch Hand
+ Follow
since Sep 05, 2010
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
5
Received in last 30 days
0
Total given
6
Given in last 30 days
1
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Prasanna Raman

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)


  • 3 days ago

    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
    1 week ago
    Thank you. Do you think using enum would be a good way to make that distinction?
    1 week ago

    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.
    1 week ago

    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?
    1 week ago

    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.
    1 week ago

    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..
    1 week ago

    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?
    1 week ago
    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!
    1 week ago
    Thank you. More than conventions, I'd like to understand how I can organise this into packages. Please suggest
    1 year ago
    Also, I have about 8 classes. I know leaving them all in the default package isn't good but is there a convention to naming packages for these types of apps?

    I have an Application class, 3 enums and 4 other classes (Joblet, PrintConfig, PrintJob and PrintConfigManager).
    1 year ago
    Because I am not reading cost from file today, I have an overloaded constructor in PrintConfig to let my main method create PrintConfig without cost. Is this ok or is there a better way?
    1 year ago
    Ok, thank you very much!
    1 year ago
    Thank you. I think I'm understanding this a little better now So, who would call the loadDefaultCosts method then?

    Would it be the Application class that reads from file?
    1 year ago
    I have the following. I think I'm confused about how PrintConfig should calculate cost. I have a circular dependency between cost methods of PrintConfig and PrintConfigs now

    PrintConfig:



    PrintConfigs:

    1 year ago