Thread: Two Questions about Classes: I need some advice.

  1. #1
    Set Apart -- jrahhali's Avatar
    Join Date
    Nov 2002

    Two Questions about Classes: I need some advice.

    I'm doing an assignment in Java that calculates the commission for a salesperson. It's very simple, and could be coded all in the main method, but because I want to get more comforatble working with classes and objects, I made a SalesPerson class and a Calculator class. I have two questions.

    Question 1. I have no need to instantiate multiple objects for these classes. The Calculator class only serves to provide 2 methods and some variables, and I don't need to keep track of multiple sales people. Because I don't need more than one instance of these classes, I was thinking about making them contain all static methods and variables. Is it OK to have a class when you don't intend to instantiate it at all?

    Question 2. The SalesPerson class only contains variables and no methods (name, commission, totalPay). The only reason I made it into it's own class was to separate functionality. I know in C++ there is the structure data type. I would have used a structure, but Java doesn't have it. Again, I could just put these variables in my main method, but my intention was to separate out the functionality. Is it OK to have a class that contains no methods just for the purpose of making your code 'cleaner' (or the other way around: having a class that contains just methods)?

    Clear the mines from our Shazbot!
    Get the enemy Shazbot!

  2. #2
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    The edge of the known universe
    Try some variations, and see for yourself what the relative merits of each approach are.

    It's all very well reading "do it this way", but until you've tried it yourself, you'll just be in the same "what do I do now" boat as now, when it comes to making design decisions.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  3. #3
    Set Apart -- jrahhali's Avatar
    Join Date
    Nov 2002
    I have tried it both ways. Sorry, I may not have been clear enough with my questions.

    What I am looking for I guess, is advice on what is considered best practice.
    Clear the mines from our Shazbot!
    Get the enemy Shazbot!

  4. #4
    Registered User
    Join Date
    Dec 2006
    Best practice is to not use statics, and just instantiate your class once. Statics are, in some ways, like globals. They couple different instances of the class together, which is usually undesirable.

    A good way to think about this is to think, what would be easier if I want to make the code support 10 sales people later? One of the major strengths of OOP is scalability. Good OOP code should be easily scalable.

    Classes without methods are fine. Usually we use structs for those, but in C++, the only difference between structs and classes is the default access. You should still use structs though, because when an experienced programmer sees "struct", s/he automatically assumes it to be conceptually a collection of values, which makes the code easier to understand. It is, in a sense, documentation.

  5. #5
    and the hat of copycat stevesmithx's Avatar
    Join Date
    Sep 2007
    That depends on nature of the class "Calculator".

    Will it be an "utility" class like "java.util.Collections"?
    If so, yes, otherwise you probably want to rethink this approach.
    Not everything that can be counted counts, and not everything that counts can be counted
    - Albert Einstein.

    No programming language is perfect. There is not even a single best language; there are only languages well suited or perhaps poorly suited for particular purposes.
    - Herbert Mayer

  6. #6
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    A big problem with static methods is testability. Any code that uses statics has a hard dependency on them that you can't break (without jumping through classloader hoops). So if the functionality in Calculator is something that you might ever want to stub out, you must not use statics. If, on the other hand, it's just basic functions, like java.lang.Math's members, that's fine.

    Static final fields are fine; they're constants.

    Static non-final fields, on the other hand, are very bad, from an understandability perspective as well as a testing perspective. They introduce global state, which is hard to model and control.

    Regarding SalesPerson, that sounds fine. Given that this is Java, I'd hide the fields behind accessors to lay the base for encapsulation. But until your program grows, it's unlikely that there's code that should be a proper method in SalesPerson.

    However, the combination of the two questions is a bit suspicious. It sounds like you have one class (Calculator) that contains logic, and one that contains only data. It sounds procedural, not object-oriented. That may be fine for simple examples, since they are often not big enough to warrant the kind of structure that object-oriented programming is for, but it's something to keep in mind.
    All the buzzt!

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. some advice on what classes to take
    By ilikeapplepie in forum C++ Programming
    Replies: 6
    Last Post: 01-01-2011, 06:30 AM
  2. Questions on Classes
    By nosfearatu in forum C++ Programming
    Replies: 1
    Last Post: 03-23-2010, 03:52 AM
  3. Replies: 5
    Last Post: 11-12-2009, 05:32 AM
  4. Classes advice needed
    By DanFraser in forum C# Programming
    Replies: 5
    Last Post: 12-05-2007, 05:30 AM
  5. questions / advice
    By Shadow in forum C Programming
    Replies: 3
    Last Post: 09-24-2001, 08:14 AM