Results 1 to 4 of 4
  1. #1
    _argus is offline Member
    Join Date
    Mar 2013
    Rep Power

    Default Help with Java theory / Good programming...

    I'm hoping someone can help me understand a little more about good programming practices in Java. I am new to Java and programming in general. I find myself constantly trying to change or redo my programs altogether in an effort to follow better OOP techniques. But, in the end, I am not satisfied and I'm realizing that I really don't know what makes good code. I'll use a specific program as an example.

    I'm writing a simple physics calculator for simple projectile motion. The program will ask a user for initial velocity and the angle at which the projectile is fired. The program will then output to the screen: maximum height, time in the air, and distance traveled. I also have it display the x and y coordinates of the projectile for every 1second change in time.

    First Attempt:
    I write a program with a single class. Inside this class will be a few different methods as follows:

    Method1: Get's user input while making sure it is valid.
    Method2: Calculates x and y components, total time, distance traveled etc...
    Method3: Displays all the information to the user

    Second Attempt:
    I write a program with 4 different classes and use constructors.

    Class1: Get's user input while making sure it is valid.
    Class2: Calculates x and y components, total time, distance traveled etc...
    Class3: Displays the information to the user
    Class4: Contains "main" method which simply calls the other constructors like: new Class1();new Class2();new Class3()

    This seems nicer. But, if I make my variables private then I have to use a ton of "getters" and "setters" for use between my Calculate and Display classes. This seems tedious and maybe unnecessary?;

    Third Attempt:
    So I read some more on Java and learn a little about the keyword Static. Seems great, so I'll try to use it in my program, specifically in the Calculate class. Might make it easier to pass things between Calculate and Display classes. Well, awesome, now I have made just about every variable and method in my Calculate class Static. This can't be good. I've gone static crazy.

    I guess my questions are: Which attempt is best? Or, are they all horrible tries? Should all variables in classes be private always? And can someone give a good example of when to use "Static" for variables or methods?

    Thank you to anyone who reads this and responds! It ended up being a longer post than I originally had in mind. Sorry for that!

  2. #2
    jim829 is offline Senior Member
    Join Date
    Jan 2013
    Northern Virginia, United States
    Rep Power

    Default Re: Help with Java theory / Good programming...

    Definitely my opinion. Others may disagree.

    Stay away from static variables. Static methods are fine and should be preferred if at all possible if they don't rely on any particular instance variable.

    I would recommend you get in the practice of using getters and setters. They help preserve encapsulation and hide implementation details. The also facilitate applying constraints to the variables. Here is an example.

    Suppose you want to assign a variable a value than can't be negative. If you just let someone assign it without a setter, they can violate that condition. Then you need to verify the value of the variable every time you use it. But if you only set it via a setter, you can enforce the invariants there and then not have to worry about it later.

    Static variables are not unique to a particular instance of a class. So all instances of a class share the Class' static variables. A common use might be to calculate how many objects have been created. A static variable count could be used in the classes constructor. Of course, decrementing count when the object goes away is a little trickier but you get the idea.

    You should check out The Java™ Tutorials.

    Last edited by jim829; 03-01-2013 at 10:27 PM. Reason: Added disclaimer
    The JavaTM Tutorials | SSCCE | Java Naming Conventions
    Poor planning on your part does not constitute an emergency on my part

  3. #3
    AndrewM16921 is offline Senior Member
    Join Date
    Jan 2009
    CA, USA
    Rep Power

    Default Re: Help with Java theory / Good programming...

    Fair warning: this reply is entirely opinion.

    For the example you gave, I actually like the first attempt better. It really depends on how complex your program is. For something that simple, I find a single class is just fine. But, as a general rule of thumb for larger systems, each class should have one thing that is knows how to handle. This doesn't mean it only knows how to do one calculation necessarily, but it handles one set of closely related functionality. And as such, that class and only that class (or in some cases, a small group of classes) should perform operations pertinent to that functionality.

    As for static... Anything declared "static" is said to belong to the class, as opposed to belonging to the object. Mostly, I use static fields for things I know there will only ever be one of. For example, if there is a directory where I store all of my config files for a program, I might make a String holding its path static so that it can be accessed anywhere (if public/final) and any time as necessary. Then, I would use static methods for anything that isn't dependent on an object necessarily. One example might be loading a resource from the disk. I would use a static method that takes a string or file as a parameter, and then returns the resource it loaded in. This doesn't depend on the object whatsoever, and may have applications to be used anywhere without the need to pass an object with a non-static method around all the time. And finally, a static field is also designed for all objects of a particular class to use. That is, you can think of it as a "shared" resource between all of those objects, no matter how many there are. You definitely don't want to make everything static, though.

    As for your third attempt: starting in main is by definition "static." So, the fact that everything ended up being static in such a simple program is not really a surprise, unless you were to create an object to handle everything.

    I feel like the use of static fields and methods becomes much more apparent as you delve into larger software systems.
    Last edited by AndrewM16921; 03-01-2013 at 10:17 PM.

  4. #4
    Tolls is offline Moderator
    Join Date
    Apr 2009
    Rep Power

    Default Re: Help with Java theory / Good programming...

    If you're aiming for OO then look at your problem.

    The base thing is a to me that says you should have a Projectile class that understands the physics.
    It would have a constructor that takes a velocity and angle.
    No need for setters here, since you don't want to actually change those values. That's the job of the Projectile itself.
    In order to handle that it will have a launch() or calculate() or whatever method that does the job of setting all its internal values...including an array of coordinates for each second of flight. Provide getters for these. You could simply provide getters and no launch() method, and have the getters calculate the values on the fly. Doesn't really matter.

    Now, you need something to handle IO.
    If this is a GUI, say Swing, then you'll have a screen for getting the values from the user, and another for displaying the result.
    If it's a Scanner then I suppose a similar split might help keep things tidy, though simply breaking it up into methods might be sufficient.
    Please do not ask for code as refusal often offends.

    ** This space for rent **

Similar Threads

  1. good programming practise
    By shruti7 in forum New To Java
    Replies: 10
    Last Post: 01-24-2013, 10:35 AM
  2. Good Practice Programming Websites?
    By littlebirdpoo in forum New To Java
    Replies: 1
    Last Post: 02-18-2012, 02:58 PM
  3. Replies: 1
    Last Post: 08-07-2007, 05:19 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts