OO is not a primary concern for professors

[Junilu Lacar]

I still don't understand why instructors give this problem when they haven't taught proper object-oriented programming yet. Pedagogy still at least a decade behind. Sigh.

This topic was split from here. - Stephan van Hulst

[Campbell Ritchie]

Junilu Lacar wrote:. . . Pedagogy still at least a decade behind. Sigh.

I think that is a bit of an exaggeration. It depends who is teaching; there is a school of thought that you can teach programming and add object‑orientation later. I am not convinced by that, but I wasn't taught that way; I was taught objects from the w‍ord go.

The basic tenets of programming haven't changed in thirty years, but some things have. For example Bertrand Meyer could ask how you can have object‑orientation without multiple inheritance back in 1997, and nowadays we hear many people saying they hardly ever use inheritance.

[Junilu Lacar]

Actually, I was trying to be kind with a decade. Java has been around since 1995 and has been in widespread use as a first language to teach programming for at least a decade. I think more schools are starting to offer other languages like Python and C# as their "starter" languages now so the pedagogy in general, rather than evolving to have a stronger focus on object-oriented programming from the onset, is probably shifting to other languages, perhaps even to other programming paradigms like functional programming and its associated languages.

There might be instructors out there who recognize the problems we've seen with the kind of approach OP's instructor seems to have but I think those are a very small minority given the dearth of posts we see in these forums where a beginner actually starts out with an object-oriented programming focus. My own experience with instructors at the university level seems to support this supposition.

[Norm Radder]

What do the professors want?  Many of you want to see more OOP coding but if the professors don't require it for homework, I don't imagine the students will go out of their way to learn it.
When I was a TA at university for an assembler programming course, the professor's standards for homework which I did all the grading for was 50% for a  working program and 50% for a program with good comments and design. That made it possible for a non-working program that was well designed and documented to get about the same grade as a snakepit of a program that worked.
That sort of explains my hot button - documenting code.  I rarely see any documentation for code these days.  Why?  Many of the experienced people here seem to ignore it.  When I copy some code to test it can take several minutes or longer to figure out what it does and how to use it.
There I got that off my chest.

[salvin francis]

There are different ways to teach java.

In my opinion the first step would be to familiarize a student with flowchart and explain loops and conditions. Then, use these in code and teach the basics of variables and how to use them and our good old friend : "System.out.println". Loops and conditions are not always intuitive for newbies. As per my experience, many find it difficult to grasp a nested loop. Next topic, would be arrays and how to use them in code.
In the above approach the pitfall is that the student looks at the "class X {" and "public static void main(String args[]){" as boiler plate code and not really understand them till quite later.

There could be different variations in styles of teaching. For example an instructor can start directly with classes and methods as the first lecture and then move on to using variables and loops.

[salvin francis]

Norm Radder wrote:I rarely see any documentation for code these days.

Well, during the "learning" phase, one might change a method a zillion times. The aim would be to get the code to somehow compile/work and get the right output. Re-writing the documentation every time to accommodate the new changes would typically be just painful. And the worst problem would be to forget to update the documentation when a code changes. We all know what a false documentation does
As one gets better and writes more stable compilable code, one should be encouraged to at least write one liners to indicate what a method does.

[Junilu Lacar]

My main gripe is that Java, being a general purpose object-oriented language, is often taught without much of a focus on object orientation. We have seen many posters here who are already into their second programming course using Java who still program with a procedural mindset.  That's like giving people a chain saw and not giving them gasoline to make it run. So, many students have all this potential power at their disposal but they don't have any idea of how to harness that power through proper use of object-oriented techniques and design. All the other things mentioned like introducing basic loops and other control structures are irrelevant to this point. Of course you have to teach students those things first but to give them a problem with the complexity of something like RPS and RPSLS without a foundation of object-oriented concepts and telling to write a solution in Java, well, I think that's just not a good way to teach people how to program in Java.

[Stephan van Hulst]

I'm a firm believer of self-documenting code. Write method and class specifications, and otherwise only write comments when it's not clear why a certain line was written.

I write meticulous method contracts for professional code and hobby projects. On these boards, I tend to forego them because I mostly write example code to illustrate patterns and to show how certain methods from the standard API can be used. Documentation distracts from that and is usually also a waste of time, because readers actually have access to the code and can see what the API specification would be, given that parameters are checked and invariants enforced.

I guess that's my pet peeve. People complain about lack of documentation, but often fail to enforce their own specifications, or write readable code in the first place.

[Stephan van Hulst]

I disagree with you Salvin. When your method signatures change a zillion times, you haven't spent enough time on your design before you opened your editor.

To explore the problem domain and get a feel for what the proper API should look like, people can first write a proof of concept that isn't documented. After that, based on what they've learned, they can write an API with proper documentation and skeleton implementations. Write unit tests according to the specification of the classes and methods. Only then implement the API. It's fine if it turns out some signatures have to change, but update the documentation and unit tests before making the changes to the implementation.

The real problem is that when most people are done with the initial exploration phase, they slap some documentation and tests on their proof of concept and call it a day.

[Campbell Ritchie]

Junilu Lacar wrote:. . . a general purpose object-oriented language, is often taught without much of a focus on object orientation. . . ..

Agree. And as I have said several time before, that isn't how I was taught. We were taught objects first, then selection, then iteration. I would do it rather like that, but lots of objects first,
then predicates (small p) and booleans, which can probably be covered in one session or less.
Once you have your hands on boolean values, you can readily move on to selection; I found the hardest part of selection to learn was ?:
I think I would introduce arrays before iteration, but I am sure the best way for a beginner to fill an array with consecutive numbers is:-

int[] ascending = IntStream.range(1000, 2000)
                           .toArray();

Why are people scared of introducing beginners to Streams? That code is much easier to understand than

int[] ascending = new int[1000];
for (int i = 0; i < ascending.length; i++)
{
   ascending[i] = i + 1000;
}

. . . and much harder to get wrong.

I can only speak for where I write from, but people round here do actually know object‑orientation. I agree with Stephan about documentation: also, when posting here we simply don't have the time to write proper documentation.

[Junilu Lacar]

I'm with Stephan, write clear code that reveals its intent and design APIs that are intuitive and make the ideas involve fit with a coherent idea/pattern that permeates the design.

For example, there is a stark difference between these two designs that reveals the underpinning mindset of the designer:

public enum GameAction {
   ...
   public static GameAction getWinner(GameAction player1Action, GameAction player2Action) { 
       ... 
   }
} 

vs.

public enum Gesture {
   ...
   public boolean defeats(Gesture other) { ... }
}

Which of the above was designed with a more object-oriented mindset and which one with a more procedural mindset? The differences may seem trivial for a program as small as RPS or RPSLS but in larger, more complicated programs, the differences get amplified by the downstream design decisions that these foundational ones lead to.

The mindset we see with most posters and students is seldom the more object-oriented one. That's what's frustrating to see, especially when the students are already into their second or third programming course. These habits get carried into people's professional work and I've seen many examples of it and I think it contributes to many of the problems we see in professionally-written software. And if anything, it gets worse every year based on the ever-increasing difficulty I have in finding people who understand how to think, design, and code with proper object-orientation.

[salvin francis]

Stephan van Hulst wrote:I disagree with you Salvin. When your method signatures change a zillion times, you haven't spent enough time on your design before you opened your editor.

I guess you misunderstood me, I was referring to newbie programmers.

[Stephan van Hulst]

Norm referenced experienced developers/professors though.