Jordan D. Williams

Ranch Hand
+ Follow
since Jan 03, 2012
Jordan D. likes ...
Android Eclipse IDE Firefox Browser
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
12
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jordan D. Williams

Hello everyone...

I am going through the Java Tutorials and I was reading about Generics and I felt like my brain was going to melt! ... It seems like one of the most complicated things I have seen in Java. For all the seasoned developers out there, what was the most difficult part of Java for you to master? Why was it challenging? Do you have any tips for people on how to learn it better/easier?

Thanks for all you comments!
8 years ago

Rob Spoor wrote:I prefer the solution that uses a proper layout manager



What do you mean by that? (A beginner Java guy here...)

Thank you.
8 years ago

Junilu Lacar wrote:
It's like when you were born, you took on some of your father's characteristics but that didn't create another "instance" of your father in you. In a sense, you "are" your father but at the same time you are "your father's child". Maybe it's better to say "You are of your father." Another analogy: you know how sometimes people will say "You laugh just like your father." or "You do this just like your father." It's kind of like that with object inheritance. Whatever the parent is programmed to do, so shall the child do it as well. Only as the programmer, you can chose to make the child either do something exactly like it's parent, in which case you'd just call/invoke the inherited method or you can make the child do that thing slightly differently than its parent, in which case you'd override the method and program some new logic.



That, good sir, is probably the best explanation of Inheritance I will ever read! Awesome! You have a gift for these things - explaining things in a way people understand. Well... At least I get it when you explain things.

Thanks so much for that very, very clear analogy.
8 years ago
Very, very interesting! Thanks so much!

I haven't really had a chance to dive into this as I have not been home, but I had a quick question about the tests that you coded...

Do both EquationTest and QuadraticEquationTest run simultaneously? In other words QuadraticEquationTest extends EquationTest, but the entirety of EquationTest also gets executed when you run the QuadraticEquationTest?

That question probably stems from my little understanding of inheritance. When you instantiate a class that extends a parent class, I guess the parent class also gets instantiated?

Basically you have this:

so that when you run this:

creates a QuadraticEquation object and runs the test on THAT type of object?

NOTE: I have not gotten to the Inheritance part of the Java Tutorials so I am a little hazy on that still. I also have zero understanding of how abstract classes and methods work, so I will have to read up on that too before I can fully understand what is going on in the above code. One step at a time though.

Thanks.
8 years ago

Junilu Lacar wrote:
Inappropriate Coupling - TMI (too much intimacy)
When a class knows too much about other class(es), it creates unnecessary coupling. Why would an Equation care about how its coefficients are obtained? Your implementations of Equation know too much about this detail -- they are coupled too tightly with GetCoeff. This is where my niggle about private constructors without factory methods comes into play. The thing that clued me in to this smell was that the method name getValues in the Equation interface did not logically match the method's return type. It felt to me like the method wanted to be named something like buildEquation or createEquation with a variable length list of coefficients appropriate for the type of equation passed into it.



Hello there Junilu,

I have been trying to figure out to accomplish what you suggested, but so far I got nothing... I think I just really like my CoefficientGetter (refactored from GetCoeffs) class and I don't want to get rid of it. The main reason why is that my program is designed to be "localized" (It was realy just me playing around with properties files and it sort of stayed that way) so adding strings that will appear on the screen is sort of a pain now. The other thing I like about that class is that I just have to pass an int to the getCoefficients (refactored from CoeffGetter) method and it takes as many as needed, without me having to change anything after, if I want to add more equation types. Is there any other way by which to get rid of that TMI between the Equation implementations and Coefficientgetter?

I should probably say that I was guided by Winston Gutkowsky and his suggestion in this thread. He hasn't had a chance to take a look at the final implementations so there is a good chance I might have misinterpreted something that he said/suggested.

Ahh... I feel like the answer is right in front of me, but I just can't see it! I know what you are saying needs to happen... The Equation implementation should not interact with the user directly. What I don't understand is why is it so hard for me to figure out how to accomplish that!?

Thanks for your help!
8 years ago

Junilu Lacar wrote:
Yes, absolutely. Now I hope you have been test-driven infected. It's a great way to program. I'm confident that you're ready for the material in "Growing Object-Oriented Software, Guided by Tests" now.



Well sir this is in a huge part thanks to you!

Thank you so much for showing me this. I actually learned a whole lot! And it was a good introduction to JUnit and unit testing in general. I obviously am just scratching the surface of learning how to design tests and the like, but I think it's a great start. I will definitely be reading that book you suggested. Before this I had to run the whole program from the beginning to test it and see if it was doing what I wanted it to do. Now, it just takes a click of a button! Can it get much better than that?

Thanks so much again! Now I will be working on refactoring the Equation Solver program to remove the TMI and hopefully implement a couple of more equation types.

8 years ago
Well I guess for not using an IDE it wasn't that bad. I just forgot to return any of the functions. Forgot to declare some of the variables, and learned that I must have the * sign to do multiplication. Otherwise the compiler thinks I a trying to call a function that does not exist.

So here is my second try. This time with Eclipse and even tested with JUnit so I know it all works . The only question now is if this is what you had in mind as a solution.

Exercise 1:

Previously, I had int totalSum = 0; outside of the total(int n) method and you said I don't need it. Is this what you meant or is there a way in which I can eliminate it entirely?

Challenge 1:

Challenge 2:

AccumulatorChallenge2.class:

AccumulaotrChallenge2Test.class:
8 years ago

Junilu Lacar[b wrote:Exercise 1. Assigning values and using the for-loop (10 points)[/b]

Instructions: Given the JUnit test below, write the code that would make it pass. Use what you learned about assigning values and the for-loop in your solution.

Challenge 1 - Extra credit (2 points)
Modify AccumulatorTest so that instead of using a hard-coded value for the expected result, you will use an established formula to double check the brute-force calculations made by your Accumulator.

Challenge 2 - Extra credit (4 points)
Add a test to AccumulatorTest that will require you to implement an overloaded version of total() that takes an array of integers as its parameter. The result should be the sum of all the integers in the array. Your solution should include the code in Accumulator that will make the test pass.



I have chosen to accept this challenge. Now let's see if I can handle it.

I believe this is the code that will pass the tests in Excercise 1:

I am currently at a computer that does not have JDk installed so I wasn't able to test this to see if it will even compile, but hopefully I got it right. Also, for those that are unaware, I do not know how to use JUnit or Test Driven Development (TDD), thus this being a "challenge" for me.

Excercise 1:


Challenge 1:
My guess is that both the Accumulator() calss and the AccumulatorTest() class will need to bechanged in order to successfully complete this challenge. Here is my try...



Alternatively, it could be that I don't have to change the Accumulator() class. If that's the case then maybe the AccumulatorTest() class should look like this:


Challenge 2:

Theis is the code I believe I should have for the AccumulatorTest() class:


And this is the code I believe I need to have in order to make the above AccumulatorTest() test pass:


Well... This is what I came up with. Hopefully I got at least part of it right. Any comments will be appreciated.
8 years ago
Hi there Junilu.

I will be posting my solution after I get some sleep... I thought I was going to do it today, but time did not permit.

Thanks for the challenge!
8 years ago
Wow! Every day I post/read on these forums someone blows my mind!

Junilu Lacar wrote:



That is just awesome! I really have no other comments about that!

Thanks so much for the help all!
8 years ago

Paul Clapham wrote:... Looking at small pieces (e.g. what is a boolean value, which is one of your questions, and a perfectly good question at that) is much easier when you don't have to worry about how those small pieces are going to be put together into a larger structure.



What I asked previously and the way I formulated it was really not a very well thought out approach. I edited the question and the topic title. Is that better?

Thanks.
8 years ago

Bear Bibeault wrote:asserts have nothing at all to so with return values. Why are you mashing them together?



Well... the Java Tutorials example used boolean return type fuctions whose return statement I did not understand and those same methods were used with assert. I thought that putting them together would give people a better handle of the context in which the question occurred. I can separate them if you think it would be better.

Thanks.
8 years ago
Hello there!

I am systematically going through the Java Tutorials and I came up to something I don't quote understand. I am looking at the answers for question #2. Here is a direct link to the question. It's a little frustrating that they have not even mentioned assertion when they ask us readers to do this, but that's OK.

Basically I am looking at the Card.java class and I see this:



ACE and KING are of type int.

This is what I *think* is happening here. Please correct me if I am wrong. Basically the code that follows the return statement is like an if expression to be evaluated - except it does not have parentheses around it. If the conditions are true (ACE is less than or equal to rank AND rank is less than or equal to KING) then the method will return true. If the one of the conditions is NOT true, then the method will return false. Is that correct so far?

If someone could shed some might for me and others who might be confused about this, it would be greatly appreciated!

Thanks so much for all your time and effort!
8 years ago

Junilu Lacar wrote:One more nit I just found:

Look at the EquationSelector class. What happens to it if you add new types of equations? Say you wanted to add Exponential and Cubic equations to your portfolio of equations. This is going to require you to change EquationSelector, right? Is that change really necessary? Should EquationSelection have to change if you add or remove Equation types? Probably not. I smell a need to refactor. But I would wait until I actually had to add a new Equation type. I would have tests that provide a safety net to facilitate refactoring. And I would do TDD on this.

Here's how it would go down:

1. Someone (maybe myself) asks me to add Exponential and
Cubic equations to the list of supported equations
2. I develop Exponential equation and its unit tests via TDD
3. I integrate Exponential equation and test the program end to end.
4. I find that I need to change EquationSelector to get it to give Exponential
equation as a choice.
5. I refactor so that I won't have to change EquationSelector when I add
(or remove) new Equation types.
6. I develop Cubic equation and its unit tests via TDD
7. I integrate Cubic equation and test the program end to end.
8. I'm done.



First of all, I would like to thank you for taking the time to write such an in-depth review of my code. I know that the fastest way to get better at something is to listen to the people who have "been there, done that"! Learning from the experience of others is much less painful than learning through your own experience...

I have a few questions on your comments. Most of them I understood, some of them I am a little confused about, and some of them I flat out have no idea what you are talking about - but that's OK because I want to learn . I would go over the things I understand and almost understand first, and then move on to the things that I have no idea what you mean.

Frankly, I should have known about the lower case names for the directory names. I actually had them lowercase in the previous version. I will change that for the next version. Quick question though... What do I do when I have a directory name that is composed of more than one words? Ex: Equation Solver... What is the naming convention? equationsolver? equationSolver? Or just flat out "don't use more than one word" for the directory?

Your comments on the class names are another thing that I should have known. As soon as I read that I remembered reading it in the Java Tutorials and a couple of other places. Thanks for the reminder.

Spelling out the full name of the members is also something that I have read about, but I failed to implement. If someone else was reading my code, it might be difficult to understand what is "coeff" supposed to mean.

In regards to the JavaDoc, it makes complete sense what you are saying. I will try to do what you suggest. Mostly the comments that I put in are for myself. Because I am so new to Java, most of these comments are for myself to remind me what the code actually does. I just don't know Java well enough yet to be able to look at a piece of code and understand what it does - especially with some of the more complex code (which might not be that complex at all, but it is for me most of the times ). Although it's probably a better idea to develop good JavaDoc writing style and if I need to leave reminders for myself I should use regular comments.

Here is my reasoning about the methods with private constructor and only containing static methods (I have only heard about factory methods, but I don't know how they work so I am leaving that out...):

The InputGetter and the GetCoeffs are "utility" classes so I didn't think that I should be letting anyone instantiate those. Now that I think about it, the EquationSelector class is also a utility class and probably should be in the Utils package. The reason, in regards to EquationSelector specifically, why I decided to declare a private constructor and static methods is because this class will always be used. I noticed that the main() method is static and it made sense to me, because it will always be run. So I figured since EquationSelector will always be run, rather than creating more logic in the main() method by having to instantiate it before I can use it, I thought I should just make it's methods static. I am not saying I don't agree with you. I don't have enough knowledge on the subject to agree or disagree. I just wanted to explain why I did what I did. Please let me know if that reasoning is not a "good enough" reason to implement it in such a way. By the way... I don't mean that sarcastically at all. If this is not good, I want to know how to do it better.

I wrote GetCoeffs in such a way so that I don't have to write a new method to get the coefficients every time I add a new equation type. If I don't have that class then I will have a lot of repeating code in the class of each equation type that would have to get the appropriate coefficients. I don't remember what the term is used when you just copy and paste code and just change the relevant parts, but when I read about it, I was told that was something I should try to avoid doing. Is there a way to keep GetCoeffs and maybe rewrite the implementation so that there isn't too much TMI while still practicing code reuse, instead of copy-paste? Please correct me if I am wrong, but from what I understand, with your suggested implementation, I would have to have a getCoefficients() method in each equation type class and gather the coefficients through that method, rather than the GetCoeffs utility class.

And now to the part which I know nothing about:

Unit testing... I have no idea how to do it? Are there any resources that can point me to? (Besides the one you showed in your post? I did not get anything on that page) That is something that is completely new to me. I mean.. I know that you "test" your code before you release the application, but as far as "how" to write and implement code that does that, I have no idea.

Thanks so much for all your time! I really appreciate it!


8 years ago
Hello everyone.

As promised, I have finished the new, re-written from the ground version of my experimental project. I posted it under my "Code Review Request" thread. You can find it here.

Thanks for any and all comments.
8 years ago