Java applets

So the exam is tomorrow, and I have tried unsuccessfully to understand what exactly to do when coding applets (the html part in particular).

I hope the exam doesnt have much of that.

Anyway, how do you guys find them?

What you struggling with mate? I'll try help if I can.

It seems like there's more 'theory' based questions and questions based on understanding the work than actual coding in previous exams.
Does anyone know where to get hold of the answers to the previous exam?

I am definitely not looking forward to tomorrow's paper.
Besides the difficulty of understanding Java concepts from a not-so-comprehensive textbook, it's also my last exam... after writing 7 exams, I am quite exhausted.

Yeah, tomorrow will be my 9th and last exam for the year. Looking forward to a weekend of no textbooks!
Holding thumbs for a nice exam though.

Leila, I couldn't help notice you saying "previous exams". Do you have old exams to pass along?

Fully agree with not looking forward to tomo and the exhaustion factor. As I said to those around me, I'm going to sleep for a week.

Also my 9th and final exam tomorrow. To be honest, I dont think there is any hope in me passing

Maybe I will be lucky and get a supp... Anyway, Im not phased about repeating it next year. I am thinking of going more the IS route because I am not so hot at programming, and the INF subjects dont have COS214 as a requirement.

On second thought, the html part is easy. Its the actual applet thats hard
Sure, by my pc I can look up class names and functions and get the job done. But in an exam room I do not have that luxury. So memorizing all functions of all classes is a bit taxing to say the least.

That unfortunately is my biggest bug-bear with universities (not just UNISA), which is memorizing code. I'm a developer by profession and you simply do not memorize everything, it's actually impossible.

Since Google and Wikipedia is freely accessible to any developer these days, memorizing facts should be secondary. At the end of the day, you either can DO it or you cant. I actually couldnt get a textbook last year and google came to the rescue.

Oh, another hot tip! If you haven't tried, go to YouTube and search for some good programming videos. In the cos211x exam I looked at a video that explained the shortest path algorithm. Because time was tight, I had got passed the stage of being able to absorb anything from a book, but the video made it a lot easier to understand and see in motion.

But the shortest path algorithm is easy

The course is about object oriented concepts, not coding specifically. They should provide an appendix of common functions which could be used or not. How they actually are implemented is up to the student, and essentially what the whole course should be about. It shouldnt discriminate someone who learnt a few common funtions from one class and a different class was asked.

SCag Wrote:
-------------------------------------------------------
> Also my 9th and final exam tomorrow. To be honest,
> I dont think there is any hope in me passing
>
> Maybe I will be lucky and get a supp... Anyway, Im
> not phased about repeating it next year.

I don't think you're the only one.
I find object oriented concepts a little difficult to grasp.
I find C++ way easier than Java... but then on the other hand, I also feel likes the textbook is just not good enough.
When I had a look at forums from last year on COS2144, a lot of students didn't make it... also,a lot of them didn't like the textbook.
Although I have somehow managed to understand chps 1 - 6, I'm still struggling to understand chps 7,8 & 11...

I saw on one of the posts that the lecturers decided to change the prescribed textbook for next year.
That is a very good choice.

Has anyone tried to work through the previous exam paper?

Question 5 specifically...

@Leila: All the best but you and I will probably be repeating But be prepared for more Java. Tut 101 says in the front cover that next year the course is changing book and it is thus imperative to pass this year. I guess the book is changing to accomodate a semesterized course. But any other textbook will be better than what we got. To be honest, I think a strict UML course would teach OO concepts better. The 2nd year INF courses did not go in to UML that much. I dont know what 3rd year courses are like though...

@Brettc: Ive browsed over the paper a few times, but only to identify questions I might be able to get a few marks for

Quote
SCag
o be honest, I think a strict UML course would teach OO concepts better.

To be honest mate, nothing could be further from the truth. What would teach OO better is actually just developing using the methodology. That way you are literally using the principles even if you don't fully understand them as yet.

@Brett

What don't you understand mate, I'll try to help you.

In a nutshell, what the question expects is making the program loosely coupled. If you look at the abstract class Text, you will see it has a member in it "TextApplet". This shows tight coupling, as due to it being an abstract class in a strategy pattern, this type of thing shouldn't happen.

By taking away that coupling, you can make the abstract class an interface, as the only implementation in the abstract class relates to the member tA. Therefore you will have:

Language: Java
interface Text
{
   public void setText(String _text);
   public void draw(Graphics g); // Don';t know why we have public here, as everything is public in an interface, but that';s just me ranting.
}

Now as you can see, the interface is A LOT simpler than the abstract class. When you rewrite PlainText, you can now take away the need for all references to the TextApplet, so we end up with the following:

Language: Java
class PlainText implements Text // Notice implements, not extends
{
   protected PlainText() // No more ref to the applet
   {
   }
 
   private String textShown;
   public void setText(String _text)
   {
       textShown = _text;
   }
 
  public void draw(Graphics g)
  {
     g.setFont(new Font(new Font("Sans-serif", Font.PLAIN, 12));
     g.drawString(textShown, 20, 20);
     // Notice we took out the setColor, since that was the only attachment to the text applet object, and we will now set it later on
  }
}

Again, this class is now a lot easier to write due to it being loosely coupled.

The changes required to the TextApplet class are basically as follows:

• In the constructors of the Text() object, remove "this", as we no longer pass parameters to the constructors
• On the text object instance, we setColor() as now we took that out of the strategy subclasses. So basically text.setColor(Color.RED); in the if..then..else statements.
• We take "protected Color color;" out, as it is no longer needed
• We also take out the getColor() accessor, again no longer needed

That about covers that I think. The additional strategy class works identically to the previously mentioned class, so like so:

Language: Java
class FancyText implements Text
{
   protected FancyText() // No more ref to the applet
   {
   }
 
   private String textShown;
   public void setText(String _text)
   {
       textShown = _text;
   }
 
  public void draw(Graphics g)
  {
     g.setFont(new Font(new Font("Serif", Font.ITALIC, 12));
     g.drawString(textShown, 20, 20);
     // Notice we took out the setColor, since that was the only attachment to the text applet object, and we will now set it later on
  }
}

And then finally for the changes to TextApplet, you just need an additional if statement and setting the text:

Language: Java
text.setText(text);
 
if (textStyle == "code")
{
  text = new CodeText();
}
else if (textStyle == "fancy")
{
  text = new FancyText();
}
else
{
  text = new PlainText();
}

Now I didn't do anything to the CodeText class, but it would of course also need to change.

Does that explain it? Shout if you need help, and sorry for any small glitches, I typed from the Exam Tut.

As a side note, notice that now each class has a common field and method in setText(String _blah). You could make an abstract class (since you wouldn't want an instance) that houses this method, take it out of the interface and extend the strategy subclasses to use it. That way, you won't need to write that code into each subclass. Good ol' Object Orientation.

*EDIT: Added the extra bits for the text insertion.

Kyle, thanks for that

I figured it out earlier.
You'd also need to remove the g.drawString(tA.getText(), 20, 20); from the subclasses, and call drawString() in the paint() method.
Well that's how I did it anyway.

*Edit*
Ah ok, I see how you've done it. Could you explain why it would be better to do it your way?

@Kyle,

Think you left a "tA.getText" in your interface but I agree with your over all plan.
With regards to the setting of Colour and Text would it be more correct to leave Text as an abstract class and have 2 additional methods to set the text and color or do these both in paint to Graphic g?

I was thinking something along the lines of:

Language: Java
abstract class Text {
 
     abstract public void draw(Graphic g);
 
}
 
class PlainText extends Text {
  protected Color col_Text;
  protected String str_Text;
 
  protected PlainText(String sText, Color cColour) {
      col_Text = cColour;
      str_Text = sText;
  }
 
  public void draw (Graphic g) {
     g.setColor(col_Text);
     g.setFont(new Font("Sans-serif", font.PLAIN, 12));
     g.drawString(str_Text, 20,20);
 
  }
 
}
 
.
.
.
//Then in TextApplet move the setting of color before the "textStyle" setting and just use the following Text contructor:
 
    text = new PlainText(textVal, color);
//code
 
public void paint(Graphic g) {
   text.draw(g);
}

Anyways thats my thoughts but obviously there are a few ways of doing this and we gotta just hope its in line with the markers thoughts.



Edit : DOH, guess I took to long to type that all up

Would it be more right in RL, yep, more so than this example which goes completely overboard. In the exam, no, since they say exactly what you should do (Interface and set the colour in paint())

Yea, saw the mistakes and sorted them, hehe. Also with your abstract class, you should do it more like this for what I think is your intended result:

Language: Java
abstract class Text {
 
  protected Color col_Text;
  protected String str_Text;
 
  abstract public void draw(Graphic g);
 
  public Text(String sText, Color cColour) {
      col_Text = cColour;
      str_Text = sText;
  }
}
 
class PlainText extends Text {
 
  public PlainText(String sText, Color cColour) {
      super(sText, cColour);
  }
 
  public void draw (Graphic g) {
     g.setColor(col_Text);
     g.setFont(new Font("Sans-serif", font.PLAIN, 12));
     g.drawString(str_Text, 20,20);
  }
}

@Brett

Better my way, so to speak, only suites the exam. See, the ideal way in the real world would be more along the lines of how Darren was going about it. For the exam way I added the mutator simply because they didn't say put it in the paint() method, since the paint() method screws around with the encapsulation that they are trying to portray.

HAHA, guess I should ready the whole question next time. I always seem to skip the last line

Yes I did start doing my Text class like that but then messed up a copy and paste, so just continued on the wrong train of thought. (phone call mid typing didnt help)

Cant wait for 1600 (UK) tomorrow. Just out of a matter of interest, what time do you guys write in SA? Sure they have got better at trying to get everyone writing at the same GMT time.

2pm for us, so ending 4pm.

Are you waiting for the beginning or the end?

We write at 2pm tomorrow.

LOL, they still have not worked it out, thought they had.


I write 1400 - 1600 UK time so thats 2 hours after you, so if anyone finished early they could ...... haha.

I thought they fixed that this last year, guess u gotta draw the line some where when you have students writing world wide, you cant expect someone in Aus to write at 0200 just so they writting at the same time as SA

ED: Not that Im sugesting anything

Quote
kyle
To be honest mate, nothing could be further from the truth. What would teach OO better is actually just developing using the methodology. That way you are literally using the principles even if you don't fully understand them as yet.

Yeah you are right. Its alot easier learning stuff like patterns by actually seeing it implemented in code.

@SCaq

Have a look at http://www.javacamp.org/designPattern/ it helped me clear up a few of the Design Patterns and give nice working code that helps explain things very simply.

Concerning the past paper that was given to us:

1. For Question 2, the question asks for 3 exceptions that one must catch. One will catch IOException, FileNotFoundException. What's the third? RuntimeException? Also, concerning IOException, since main throws IOException, I assume we have to throw a new IOException somewhere in main and then handle it afterwards?

2. For Question 3, why exactly would it be wrong for Rectangle to inherit from Point?

Yelloa,

Concerning your questions:

1. Yea, those three will do (with RuntimeException). With IOException, due to IOException being a checked exception the compiler simply forces you to catch it. Now, buy enclosing the main method in a try..catch and catching IOException in it, we cover the checked exception, and thus do not need to catch it more than once. By Java using checked exceptions it basically forces you to error handle. Just because it is thrown by the method, doesn't mean that we have to throw it again. We can safely catch and handle it.

2. This I don't know if it is a cut and dried answer. What I would say though, is that you wouldn't extend Rectangle from Point as it is a single member, being topLeft that gains the functionality from the super class. Also topLeft does not symbolize any functionality, simply just the start point of the rectangle. It also simply doesn't follow logically for me. A Point is not a shape, therefore a Point is not a rectangle or a rectangle is not a derivation from a Point. A line, sure, but not a point. It's kind of like saying that a Car is the subclass of the Super class "Metal". Please if someone has a better answer, I'm also curious to know!

I also have a question. How would you all justify 4.2's question for 4 marks? Would you give the whole essay on Deep and Shallow cloning? There are not a lot of differences, at least not 4.

Love it when we get past papers with no answers or hints as to what they're looking for

Yea, I don't mind when it's practical, but the theory kills me with that.

Well, I have feeling that they are going to ask exactly the same paper as last year (minus the MCQ section, of course) and with an added 5 mark section...
making the paper out of 75.
For the past 2 years (and probably longer, I don't know), they have had the same paper for Java. Considering next year that the syllabus will change a bit, due to the change in textbooks, I doubt that the lecturers will set a new paper just for this year.

I code Java day in day out, but must say some of those questions in the past paper are stinkers, had me thinking and running for the book.

Also, the book is really bad for some stuff, so I usually go on the net for better coverage.

BTW, are you guys sticking to the book with Java version? I will use 1.6 and will state it on the cover of the answer book. That means parameterised containers and interfaces. Like Compareable<T> etc. So no type checking is required.

Yea, but the book doesn't use them, so it doesn't really matter. Rather code like a legacy developer though for the exam, its simply safer.

Regarding Question 3.2.1, I think it is indeed a cut and dried answer.

The relationship between Point and Rectangle is not a "type of" relationship, but more of a part-whole relationship. Point is part of a Rectangle; a Rectangle is not a type of Point.

That's surely enough for 1 mark.

Good luck to you all. If you're writing in Pretoria, I'll join you in the hall in less than 2 hours.