How about...
// HelloJava.java
package edu.myschool.FirstPrograms;
/**
* A First Java Class Definition
* (additional, necessary code comments
* removed to constrain message size)
*/
public class HelloJava
{
public static void main( String args[] )
{
System.out.println( new HelloJava().toString() );
}
public String toString()
{
return new String( "Hello, World!" );
}
}
...as a potential counterpart? :)
I think that the most important thing to teach when first learning OO is the concepts of using objects to accomplish the promise of reusability offered through mechanisms available from the chosen programming language. The mechanics of the language, while significant and often daunting (especially C++) are secondary elements that provide a "look" into what OO has to offer from the perspective of features offered by a particular language.
I find that traditional "procedural/structured" programmers often never acquire the "mindset" necessary to "think OO." While they do often learn the "packaging" fundamentals of producing objects, they often horrendously violate "rules" of abstraction, inheritance and encapsultation...and rarely, if ever, use polymorphism at all or effectively. The biggest "first" sin seems to be one of inheritance. I've seen many, many cases of "Bird is a Rock" because a Bird must use a Rock object for a particular functional role. The mechanics of the language allow you to declare your hierarchy as you choose, even if a Bird is most definitely not a kind of Rock. Too many programmers are content with accepting the outcome of the compilation process and execution for desired effect as an indication of successfulness in architectural design choices. It makes me scream...
For the sake of tradition and the lesson of mechanical "influence" that a language brings to the table, I'd not vary from an appropriate Hello, World! in a "first program." If students are unable or unwilling to come back the following session, hey, maybe programming and/or OOP are not their bags, baby?! ...or perhaps the presentation interface offered by the instructor leaves them wallowing in a sea of stupor rather than invigorating them to investigate their potential for a future in Java? Of course, a good salesperson should be able to sell more than 3 people in a classroom of 25-ish on the coolness of using Java where its benefits might be realized when applied to some business or academic challenge. The easiest thing in the world to do is blame the message content and not the messenger... You might expect that a messenger in Nebuchadnezzar II's era, after having ran across a decent bit of desert at an Egyptian front back to the Babylonian command and control center, would have had some way of presenting an otherwise disappointing message?
However, in contrast to my previous mention of learning OO concepts, if this is a first-ever programming course for students, I tend to prefer to first explore the importance of data and its type(s) as they are "seen" from the programming language, before ever launching an IDE. And, on that note, is the student learning to use an IDE or the language/concepts of OO? I strongly prefer the CLI and vi(m) as a core development "environment."
But, by the second session, your 3 will be only one remaining geek in a penguin shirt :) Far better to save the one who can be saved, IMHO! :D
Take Care.
Rob!
© 2015, O’Reilly Media, Inc.
(707) 827-7019
(800) 889-8969
All trademarks and registered trademarks appearing on oreilly.com are the property of their respective owners.