• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Tim Cooke
  • Campbell Ritchie
  • Ron McLeod
  • Junilu Lacar
  • Liutauras Vilda
Sheriffs:
  • Paul Clapham
  • Jeanne Boyarsky
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Piet Souris
  • Carey Brown
Bartenders:
  • Jesse Duncan
  • Frits Walraven
  • Mikalai Zaikin

(Teaching) Effective Java: should they start with objects?

 
Marshal
Posts: 17010
298
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Welcome back, Josh!

One thing we've often noticed around the Ranch is that it doesn't seem like many students are being taught about objects and object-oriented programming early. Instead, students are taught about basic control structures and language constructs in the context of static methods. In fact, it seems like there are many CS programs out there that hold off on teaching objects and OOP until the second Java course. As a result, we see a lot of procedural thinking and procedural Java code. This is both discouraging and appalling to me as a professional programmer and I spend most of my time here and at work trying to help people unlearn many bad habits and teach them how to think more in terms of objects and object-orientation. It seems like a losing battle though. As Bob Martin has been pointing out lately, "our industry is in a state of perpetual inexperience" with 50% of programmers having less than 5 yrs of experience and the inexperienced largely not knowing much about proper OOP.

Since there's quite a bit of material about inheritance and designing for it in your book, have you ever considered including more items that relate to effective Java programming using OO thinking rather than procedural thinking?

And what are your thoughts about teaching people about objects early? Is it really too big of a leap for people to go directly to the OO paradigm? For example, how much harder is it really to understand/explain the following program versus the typical HelloWorld program?
 
Junilu Lacar
Marshal
Posts: 17010
298
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
As a follow-up, do you think that the introduction of Functional Programming (FP) constructs to Java makes it even more difficult to learn/teach how to write good Java code? Which of Java's new(er) FP features do you find yourself talking about the most so that people can use them more effectively and still be able to apply OO thinking/design and FP thinking/design properly?
 
Saloon Keeper
Posts: 14010
315
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Or even:

In one short example you introduce both interfaces and classes, and that it's okay to have a program smeared out over multiple source files. You don't have to completely explain ALL things encountered in this code in the first lesson, but it provides a good basis for multiple lessons. In particular, you can easily extend this program to add another type of Greeter that will greet the world differently. I really don't think this is beyond the comprehension of beginning programmers, especially not if they haven't been "tainted" by procedural programming lessons yet.

Students emulate code that they see the first time, which is why many coders default to public declarations, and sticking classes in the nameless package.
 
Junilu Lacar
Marshal
Posts: 17010
298
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I cut my programming teeth on BASIC and Pascal so I was in fact very "tainted" with procedural thinking when I learned OO. My exposure to OO was a gradual mix though, starting with object-like concepts in Clipper, an xBase dialect, and then more with OO Pascal in Delphi. Then some C++ before finally going to Java. So my paradigm shift from procedural to OO happened over a period of several years. It may be some kind of cognitive bias on my part but I don't remember having too much difficulty making the shift although I'm sure there were programs I wrote in the early to mid 90s that were more procedural than OO even when there were OO language features at my disposal.

Sometimes I wonder if having some background in procedural programming was in fact beneficial for me. It certainly gave me a broader perspective on the different ways you can approach a problem and the pros and cons of one programming paradigm versus another. I can't, however, imagine that teaching procedural thinking in an OO language is intentional, with the idea of having new programmers benefit from going through that paradigm shift when OO concepts are introduced. That just seems like it would confuse people more than it could help them, particularly with the constraints you have in an academic setting.
 
Marshal
Posts: 8302
592
Mac OS X VI Editor BSD Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:Or even


I have been taught Hello World such way


May feel like an overkill for a habitual Hello World program, but the concept I've learned I used quite a few times afterwards.
 
Sheriff
Posts: 22656
126
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I would have made the MessageProvider an argument to the render method instead of requiring MessageRenderer to cache it. You forget to call the setter, and you're greeted (pun intended) with runtime exceptions.
 
Author and "Sun God"
Posts: 185
12
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Junilu. I believe there are many acceptable ways to teach programming. Objects-first is fine, if done well.  Michael K├Âlling and John Rosenberg's work with BlueJ is exemplary in this regard. That said, I do NOT believe that "procedural thinking" is antithetical to object-oriented programming. I believe it's a necessary part. Honestly, I'm just as annoyed when programmers write methods that should be static as instance methods. I think you just have to know when to use which. Like many programmers of my era, I got my start writing in languages that did not offer explicit support for OO programming, but I found myself doing it anyway, without having been exposed to it. If you define a struct, give it a name, and write methods that operate on the struct, you're doing object-oriented programming. You aren't doing inheritance, but that's OK. I believe that procedural, object-oriented, and functional programming all have real benefits, and that they combine synergistically. It pays to learn many languages and schools of thought so that you know when to use which, and how to use ideas from one language or paradigm when programming in another. I've known object-oriented programming bigots, functional-programming bigots, and even a few procedural-programming bigots. All of them are selling themselves short. There are many great tools out there, and you harm yourself by "flipping the bozo bit" on all but one. Celebrate diversity ;)
 
Joshua Bloch
Author and "Sun God"
Posts: 185
12
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Regarding your followup:

As a follow-up, do you think that the introduction of Functional Programming (FP) constructs to Java makes it even more difficult to learn/teach how to write good Java code? Which of Java's new(er) FP features do you find yourself talking about the most so that people can use them more effectively and still be able to apply OO thinking/design and FP thinking/design properly?



I probably find myself talking about streams the most, as they can really improve the quality of your code, if used judiciously, but they can also make it far worse if overused. See this thread (or Item 45 in Effective Java, 3/e) for more discussion of the topic.
 
Marshal
Posts: 75866
361
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:Or even:


A subtle change makes it necessary to write an explicit constructor, though we are no longer quite consistent with Stephan's interface. I would like to see objects taught from the very beginning, as I was taught myself. When you do that, don't think about procedural code any more; a selection instruction looks exactly the same in a procedural language as in an object language.
 
Liutauras Vilda
Marshal
Posts: 8302
592
Mac OS X VI Editor BSD Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Rob Spoor wrote:I would have made the MessageProvider an argument to the render method instead of requiring MessageRenderer to cache it. You forget to call the setter, and you're greeted (pun intended) with runtime exceptions.


Agreed, would be much better implementation.
 
Liutauras Vilda
Marshal
Posts: 8302
592
Mac OS X VI Editor BSD Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
And perhaps preferred approach today might be:
 
Saloon Keeper
Posts: 4993
186
  • Likes 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Or use the existing interfaces Supplier and Consumer.
 
lowercase baba
Posts: 13056
67
Chrome Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think all that's wrong.  We shouldn't start by teaching control structures OR object.  We should start by teaching them how to analyze a problem, and think about what's needed.  Pick some basic task, like a clock.  IMHO, we should begin with talking about how you need to display things, update things, and represent them internally. While these things are connected, they are in many ways separate.

We should talk about things like <how you get the input data> is separate from <what you do with it>.  For example, it doesn't matter how i get someone's name - from a database, from a file, from user input - but once I have it, i can pass it into a method to do something with it.  

We should talk about thinking through the flow of a program - first you do A, then B, then C, then maybe, depending on input, go back to A again...which would THEN lead to loops and control structures.  I think you could almost have an entire semester where you talk about analysis and theory, without ever writing a single line of any actual language code.
 
Junilu Lacar
Marshal
Posts: 17010
298
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Joshua Bloch wrote:I do NOT believe that "procedural thinking" is antithetical to object-oriented programming. I believe it's a necessary part.


I think I get what you mean when you say that procedural thinking is a necessary part of OOP. It's not so much about being antithetical or not though but rather more about knowing when to apply one or another kind of thinking.

For example, I often see many beginner and even professional Java programmers write code with classes named like ShowResults and ValidateUserInput. When I see that kind of code, it's almost always because the programmer who wrote it had a strong focus on defining procedures/functions. The symptom is a poorly chosen name but this often reveals other problems like poorly or improperly assigned responsibilities, high coupling, and low cohesion. They haven't learned the "why" of thinking in terms of objects, about behaviors and the information involved in those behaviors.

Coming from a procedural programming background, I understood the problems of globally shared data, high coupling between modules, duplication across modules, and low cohesion in procedures/functions. This understanding came mostly through experience and making the same kind of mistakes that I would read about in magazines and books. So I could relate to the problems that OO tried to solve and I had a better understanding of what kind of things to avoid when writing OO programs.

It's just frustrating to see kids coming out of school still ignorant of the problems they can create by writing programs the way they learned to from their instructors (I don't want to write "the way they were taught" because there's a significant difference). Even more frustrating for me is seeing professional programmers who still haven't learned that the things they learned and are doing in their current work are creating problems.  You do run into people who get it though but they seem to be very few and far between. Like Uncle Bob said, our industry is in a state of perpetual inexperience and from what I've seen, that's very true and it's quite concerning.

fred rosenberger wrote:I think all that's wrong.  We shouldn't start by teaching control structures OR object.  We should start by teaching them how to analyze a problem, and think about what's needed.


Sure, that stuff, too.

It's all about context or lack thereof. I've often cited V. Anton Spraul's book, "Think Like a Programmer," which starts out discussing different problem solving approaches but I don't know how many schools actually use his book as a reference in their introductory programming courses. The school my son goes to certainly doesn't.

 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic