Patrick Haley

Greenhorn
+ Follow
since Sep 15, 2004
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Patrick Haley

While studying for the SCJP Exam, I read about this technique, which appears to be quite nifty, but I'm wondering what practical purpose it would serve.

Has anyone locally chained constructors in applied code and, if so, to what end?

Thanks.
18 years ago
Hello Dhananjay,

Thanks for responding.

I'm going to go ahead and finish the 1.4 test. Other posts that I have read indicate that preparation materials for SCJP 5.0 are somewhat scarce right now, and I don't want to wait until they are more readily available.

Thanks again for your input.
Hello all.

I've been studying for the SCJP 1.4 test, and I am eighty to ninet percent ready to take the test. (Truth be told, I could probably do some mocks and pass the test, but probably not with a high score.)

I see now that SCJP 5.0 is now available.

My question is this: would it be worth a little extra time to prepare for the 5.0 test now, or go ahead with the 1.4 test and worry about 5.0 later?

Because I've been focusing on 1.4 for the test, I'm not clear on how much change there has been for 5.0.

Thank you.

Originally posted by may tan:
i know i need to use the method pow() for multiplier.
But i'm not very sure what to be types inside..



You could use the Math.pow() method for this, but that's seems to complicate the issue, in my opinion. Because then you have to get around the messiness of getting numeric values you could multiply by the value returned by Math.pow().

You could create a method that converts the color band Strings into integers (i.e. "red" returns 2). You could put those returned values into a StringBuffer. For the multiplier band, you could add zeros to the StringBuffer based on the integer value (i.e. for 5 add five zeros).

Convert the StringBuffer to a String and you are done.

Certainly not the only way you could do it, but the simplest I can think of this late at night.
18 years ago
Depending on how big your project is (or how little really), don't get a case of paralysis by analysis. Afterall, you say your intent is to learn Java, not OO design.

Originally posted by Matt Fielder:
Overall, I know what the program will do at completion, but how do I segregate that off into smaller sections. I assume I will have one main larger section and the others will contain methods that the main will be able to call?



If you know what the program will do, then think of how your users will interact, which will give you a series of events, such as "customer orders product." Nouns suggest objects. In the example event, these could be "order" and "product".

Once you have some classes chosen, you should think of the characteristics that each would share, like order number, products ordered, etc; these become instance variables. Then you should think about the things the class needs to do, such as total the order, apply appropriate taxes, etc; these become your methods.

Then you write the pseudocode for your methods. Then write the real code.
19 years ago
I would do this:


[ November 14, 2004: Message edited by: Patrick Haley ]
19 years ago
The Trouble With Checked Exceptions:

1. Breaks encapsulation

2. Imposes On Client: Say you write a package full of classes that I am using in a piece of software, and your classes have checked exceptions in them. Me being the guru developer that I am ( ), I write very clean code, that will never generate those exceptions, but the compiler will still insist that I check them in a try {} catch {} sequence. The unecessary requirement wastes resources.

3. Versioning: say in that same package of classes you developed, you update the code, and in so doing, you need to throw an additional exception. My client software is going to break because it doesn't check for that new fangled exception. There is no contract for this in Java.

4. Scalability: in the small, trivial program examples shown in programming books, exception handling looks like a nice little way of handling errors, but when you try to scale it up to an n-tier system with dozens of objects throwing exceptions at my client software, it becomes a question of, "How many exceptions am I supposed to be checking now?"

5. Readability: try catch catch catch finally.
19 years ago
Try something in a piece of code that does double precision math with an integer.



Then read about conversions and promotions.
Conversions and Promotions
Especially Numeric Promotion.


[ November 08, 2004: Message edited by: Patrick Haley ]
19 years ago
Joel, I do the same thing, and I know the reason. Because in my first Java class, I was told to burn into my brain because it must never ever change.

So I burned it into my brain. So it can never be (String[] args).

Sometimes, when I'm feeling loopy, I'll change args to argh or argv.
[ November 07, 2004: Message edited by: Patrick Haley ]
19 years ago
a. Not so much. I could read it.

I might have called the final value holder *area* instead of *rad* because that is what you calculate.

b. Actually, your calculation is being done with a String object (inData) and a double (Math.PI).

Remember, you read the buffer into a String, and then you parse the int with the Integer.parseInt method. Changing inData to num in the line of code above will fix the problem.

c. Math.pow(num, 2) will square it for you, but you would be splitting hairs on this.

Keep coding!
19 years ago