@Woody Yes I did, but I'm not sure if I implemented it right though.
@ 6:50 PM: you can also use for-each loop if you don't want to think about the # of elements in an array: for (StringAvailable index : x) { //do something }
@Professor Andrew Since some of us got 0 feedback on our test, and time is short before the next lab test, would it be possible for you to post the solution of how you were supposed to implement the problem and what you gave marks for?
That way we can compare for ourselves. For example:
public class DoSomething { //you got 1 mark for x reason }
Prof Eckford, The arrays on the test, is it gonna be related to Lab4 or Lab5a? I complete lab5a with much ease compared to Lab4 and I think that was the case with everyone.
I agree with Dennis. If we could have the 'perfect' solution to the labtest, it would much easier for everyone (and faster) to see where we went wrong.
Can you please post another practice lab with more Arrays in it? I'm not confident on Arrays as someone mentioned above that most of the class is having problem with Arrays.
All asking for labtest solutions: I can give solutions to the ones I wrote. I'm kind of screwed for time this week but I'll try to post it before the next labtest.
Professor, I have a guideline question regarding inheritance. For example, this showed up in the last lab (Lab 5):
When writing the deposit() method inside the LineOfCredit class, should we use super.setBalance() or this.setBalance() to call setBalance()? Or is this up to our preference?
It would make sense if we use super() instead because it emphasizes the fact that we didn't override the method we inherited, and that we are indeed calling the original one.
Let me try to explain this: You can't use this.setBalance() because the class LineOfCredit doesn't have an attributes that represents balance. LineOfCredit inherits BankAccount's balance.
Sir, your java work in class goes a little too fast for me to record. Could you post your work on the website after classes so we could take a second look at it? It would help with studying as well. I have talked to a couple friends and we all agree this would be a great resource.
Our textbook does have a section on GUI, in fact they have 2 chapters on GUI and related topics. It is chapters 17 and 18 entitled Swing I and Swing II... the start of Swing I (17) talks about the JFrame approach we did in class... I only scanned it over as of now, but there are a lot of other interesting things in there... in fact there are a lot of interesting topics throughout the entire textbook that are worth skimming over. Not necessarily important for our class, but they have greatly solidified my current understanding of Java, and have made writing programming solutions easier (e.g. Chapter 11 on Recursion and Chapter 12 on UML and Patterns)
Not at all. You CAN use this.setBalance() since it is inherited from BankAccount (as well as all the other private attributes, even though you can't access them).
In fact, that's what I used in my code and it works fine. My question was whether or not it was considered 'best practice' to use super instead of this.
Although you can use this.setBalance(), I would say that you shouldn't, but only as a rule of best practice for clarity reasons.
When someone reads your code, if they see this.(blah) it may lead then to believe it is an internal attribute instead of an inherited one. However, when you explicitly write super.(blah) then everyone can instantly know that you're referring to an inherited attribute.
The difference may not seem important now, but I'm sure it'll make a difference in large programs so getting used to this way of writing is better.
For the style question: I would say super.setBalance() is better, though this.setBalance() and just plain setBalance() will both work. But I would put it down to personal preference.
Awesome, more work!
ReplyDeletelol @ "a" is for "awesome"
ReplyDeleteBut, ya, I agree with the above comment. This is definitely helpful, thank you.
I couldn't submit my files, got the following errors:
ReplyDeleteerror: course 1030 has no submit directory for assignment lab5
error: course 1030 has no submit directory for assignment lab5a
I can't submit.
ReplyDelete@ Milton
ReplyDeleteFor lab5, change it to Lab5 and your directory to Lab5.
But it doesn't work for lab5a.
Oh I should've tried that. Thanks. I'll try and see if it works tomorrow.
ReplyDeleteCan someone help me with StringUtil please? I'm done with everything else, Arrays are always a problem for me
ReplyDeleteStill didn't get Feedback of lab 4 and 5. It's probably the 5th time i've emailed :(
ReplyDeleteI really want the feedback before the labtest :'(
@ 6:50 PM
ReplyDeleteI think you use this:
for(int i = 0; i < x.length; i++)
{
//x[i]
}
Did anyone submit lab5a?
This comment has been removed by the author.
ReplyDelete@Woody
ReplyDeleteYes I did, but I'm not sure if I implemented it right though.
@ 6:50 PM:
you can also use for-each loop if you don't want to think about the # of elements in an array:
for (StringAvailable index : x)
{
//do something
}
@Professor Andrew
Since some of us got 0 feedback on our test, and time is short before the next lab test, would it be possible for you to post the solution of how you were supposed to implement the problem and what you gave marks for?
That way we can compare for ourselves. For example:
public class DoSomething
{
//you got 1 mark for x reason
}
Prof Eckford,
ReplyDeleteThe arrays on the test, is it gonna be related to Lab4 or Lab5a? I complete lab5a with much ease compared to Lab4 and I think that was the case with everyone.
I agree with Dennis. If we could have the 'perfect' solution to the labtest, it would much easier for everyone (and faster) to see where we went wrong.
ReplyDeleteCan you please post another practice lab with more Arrays in it? I'm not confident on Arrays as someone mentioned above that most of the class is having problem with Arrays.
ReplyDeleteProfessor are you married? :P
ReplyDeleteJust curios to know?
All asking for labtest solutions: I can give solutions to the ones I wrote. I'm kind of screwed for time this week but I'll try to post it before the next labtest.
ReplyDelete6:59: Common law.
Professor, I have a guideline question regarding inheritance. For example, this showed up in the last lab (Lab 5):
ReplyDeleteWhen writing the deposit() method inside the LineOfCredit class, should we use super.setBalance() or this.setBalance() to call setBalance()? Or is this up to our preference?
It would make sense if we use super() instead because it emphasizes the fact that we didn't override the method we inherited, and that we are indeed calling the original one.
6:59 : Get a Life. Why would you wanna know if he's married or not? You wanna marry him?
ReplyDeleteSomebody has a crush on the professor.
ReplyDeletehey guyz
ReplyDeleteDoes anybody know where to get more information on GUI ?? Its not given in our book.
@ 2:59 PM
ReplyDeleteLet me try to explain this:
You can't use this.setBalance() because the class LineOfCredit doesn't have an attributes that represents balance. LineOfCredit inherits BankAccount's balance.
Hope that helps.
Sir, your java work in class goes a little too fast for me to record. Could you post your work on the website after classes so we could take a second look at it? It would help with studying as well. I have talked to a couple friends and we all agree this would be a great resource.
ReplyDelete@ March 7 7:48 PM
ReplyDeleteOur textbook does have a section on GUI, in fact they have 2 chapters on GUI and related topics. It is chapters 17 and 18 entitled Swing I and Swing II... the start of Swing I (17) talks about the JFrame approach we did in class... I only scanned it over as of now, but there are a lot of other interesting things in there... in fact there are a lot of interesting topics throughout the entire textbook that are worth skimming over. Not necessarily important for our class, but they have greatly solidified my current understanding of Java, and have made writing programming solutions easier (e.g. Chapter 11 on Recursion and Chapter 12 on UML and Patterns)
@ Woody
ReplyDeleteNot at all. You CAN use this.setBalance() since it is inherited from BankAccount (as well as all the other private attributes, even though you can't access them).
In fact, that's what I used in my code and it works fine. My question was whether or not it was considered 'best practice' to use super instead of this.
@ 6:34
ReplyDeleteAlthough you can use this.setBalance(), I would say that you shouldn't, but only as a rule of best practice for clarity reasons.
When someone reads your code, if they see this.(blah) it may lead then to believe it is an internal attribute instead of an inherited one. However, when you explicitly write super.(blah) then everyone can instantly know that you're referring to an inherited attribute.
The difference may not seem important now, but I'm sure it'll make a difference in large programs so getting used to this way of writing is better.
Interesting. Thanks.
ReplyDeleteSo, child classes inherits parant's methods.
=)
For the style question: I would say super.setBalance() is better, though this.setBalance() and just plain setBalance() will both work. But I would put it down to personal preference.
ReplyDelete