Do you think programming novices should learn objects from day 1, as seen in the book "Objects First With Java: A Practical Introduction Using BlueJ" by David Barnes? Or do you think this is a bad idea?

For those unfamiliar with the book, here is a list of the topics discussed in the chapters:

Chapter 1 deals with the most fundamental concepts of object-orientation: objects, classes and methods. It gives a solid, hands-on introduction to these concepts without going into the details of Java syntax. It also gives a first look at some source code. We do this by using an example of graphical shapes which can be interactively drawn, and a second example of a simple laboratory class enrolment system.

Chapter 2 opens up class definitions and investigates how Java source code is written to create behavior of objects. We discuss how to define fields and implement methods. Here, we also introduce the first types of statements. The main example is an implementation of a ticket machine. We also look back to the laboratory class example from chapter 1 to investigate that a bit further.

Chapter 3 then enlarges the picture to discuss interaction of multiple objects. We see how objects can collaborate by invoking each other's methods to perform a common task. We also discuss how one object can create other objects. A digital alarm clock display is discussed that uses two number display objects to show hours and minutes. As a second major example, we examine a simulation of an email system in which messages can be sent between mail clients.

In Chapter 4, we continue by building more extensive structures of objects. Most importantly, we start using collections of objects. We implement an electronic notebook and an auction system to introduce collections. At the same time, we discuss iterations over collection and have a first look at loops. The first collection being used is an ArrayList. In the second half of the chapter we introduce arrays as a special form of a collection, and the for loop as another form of a loop. We discuss an implementation of a web log analyzer as an example for array use.

Chapter 5 deals with libraries and interfaces. We introduce the Java standard library and discuss some important library classes. More importantly, we explain how to read and understand the library documentation. The importance of writing documentation in software development projects is discussed, and we end by practicing how to write suitable documentation for our own classes. Random, Set and Map are examples of classes that we encounter in this chapter. We implement an Eliza-like dialogue system and a graphical simulation of a bouncing ball to apply these classes.

Chapter 6, titled Well-behaved objects, deals with a whole group of issues connected to producing correct, understandable, and maintainable classes. It covers issues ranging from writing clear, understandable code - including style and commenting - to testing and debugging. Test strategies are introduced and a number of debugging methods are discussed in detail. We use an example of a diary for appointment scheduling and an implementation of an electronic calculator to discuss these topics.

In Chapter 7, we discuss more formally the issues of dividing a problem domain into classes for implementation. We introduce issues of designing classes well, including concepts such as responsibility-driven design, coupling, cohesion, and refactoring. An interactive, text-based, adventure game (World of Zuul) is used for this discussion. We go through several iterations of improving the internal class structure of the game and extending its functionality, and end with a long list of proposals for extensions that may be done as student projects.

Chapters 8 and 9 introduce inheritance and polymorphism with many of the related detailed issues. We discuss a simple database of CDs and videos to illustrate the concepts. Issues of code inheritance, subtyping, polymorphic method calls and overriding are discussed in detail.

In Chapter 10 we implement a predator/prey simulation. This serves to discuss additional abstraction mechanisms based on inheritance, namely interfaces and abstract classes.

Chapter 11 introduces two new examples: an image viewer and a sound player. Both examples serve to discuss how to build graphical user interfaces (GUIs).

Chapter 12 then picks up the difficult issue of how to deal with errors. Several possible problems and solutions are discussed, and Java's exception handling mechanism is discussed in detail. We extend and improve an address book application to illustrate the concepts.

Chapter 13 steps back to discuss in more detail the next level of abstraction: how to structure a vaguely described problem into classes and methods. In previous chapters we have assumed that large parts of the application structure already exist, and we have made improvements. Now it is time to discuss how we can get started from a clean slate. This involves detailed discussion of what the classes should be that implement our application, how they interact, and how responsibilities should be distributed. We use class-responsibilities-collaborators (CRC) cards to approach this problem, while designing a cinema booking system.

In Chapter 14, we try to bring everything together and integrate many topics from the previous chapters of the book. It is a complete case study, starting with the application design, through design of the class interfaces, down to discussing many important functional and non-functional characteristics and implementation details. Topics discussed in earlier chapters (such as reliability, data structures, class design, testing, extendibility, etc.) are applied again in a new context.

  • Not necessarily a good idea. Think, for example, of newbies learning Haskell.
    – Ingo
    Commented Aug 19, 2011 at 9:38
  • 1
    Perhaps you should describe the approach, so that people who don't have the book can comment?
    – DeadMG
    Commented Aug 19, 2011 at 9:41
  • @Ingo: Suppose they are learning a language where OO is a central idea. Commented Aug 19, 2011 at 9:42
  • @FredOverflow - In that case I can hardly imagine how to teach without putting "Objects First".
    – Ingo
    Commented Aug 19, 2011 at 10:00
  • I sometimes suspect that due to their mandatory nature, Java's classes become like HTML's doctype tags to Jr devs. Just some boilerplate crap between you and the action rather than a critical construct that can keep your codebase from turning into giant chain of dominoes when used properly. You can do a lot in JavaScript without OOP but forget maintaining anything complex without it. Commented May 13, 2013 at 23:26

3 Answers 3


I personally think that the easiest programming concepts to learn are the ones that follow simple procedural logic (e.g. Represent a flow diagram). The next simplest to learn is basic objects as you can teach parallels to the real world (Car, Dog, Person etc).

So in short I think you should start day 1 by teaching them basic flow logic and then you can move onto objects fairly quickly after that.

Functional programming is probably the hardest to teach to new programmers unless they have a mathematical background or just think in that way.

YMMV with this answer :-)

  • 4
    I disagree. Just because something is easy/not easy to me does not mean that the same holds for others. There is no reason, for example, why functions shoudl be a harder concept than objects (with methods, inheritance and all that stuff).
    – Ingo
    Commented Aug 19, 2011 at 10:04
  • 1
    I agree that if one starts from scratch FP could be as easy (or as difficult) as OOP. At least, I do not see why one of the two paradigms should be more complicated.
    – Giorgio
    Commented Aug 19, 2011 at 14:12
  • Totally happy with the opposite viewpoints. It's just from my personal experiences teaching programming (and probably my own pre-disposed mind set). Hopefully people take my answer with a grain of salt :-) Commented Aug 19, 2011 at 15:21
  • 4
    I agree in principle, just... please, not the Car / Dog / Bird examples : ) Just because an example is infantile, doesn't make it easy to grasp. Unlike in real life, a dog is an abstract concept in context of programming, so it forces the novice to do an additional effort just to work out how it could translate into anything useful. Animal examples also tend to give a wrong impression that inheritance chains should form a large taxonomy. Commented Sep 26, 2014 at 10:42
  • 2
    @KonradMorawski - agreed, the typical examples fail to teach real OOP. A better example to teach OOP would be a Calculator or CalculatorService, i.e. something that provides a service to the rest of a program through a generalized interface. Commented Sep 26, 2014 at 11:37

I'm not sure the state of BlueJ now, but I was taught by David Barnes and Michael Kölling and used that book and BlueJ in 2004-2006.

It's good to have the work bench and see how the objects interact with each other.

As Martijn said basic flow is the easiest way to understand a program, a problem with BlueJ and the Objects First approach is that you're insulated from Main() and how an application starts so you can focus on Objects and their interactions.

BlueJ is great for learning OO and the Java language, but once you're au fait with OO, I would move to e.g. Eclipse and start using that knowledge to build applications with an IDE designed for building applications rather than learning OO/Java.

  • I've been with first-year undergraduate students learning to program with the Barnes and Kölling book andBlueJ this year, and I couldn't agree more with your comments on insulation. When they moved on to building GUIs, and moved over to Netbeans, so many of them were utterly lost without the BlueJ interface. I'm not sure how much of that is attributable to the teaching, and how much to the book and program.
    – Andy Hunt
    Commented Aug 19, 2011 at 11:14
  • I'm wary of using an IDE for beginners. IMHO, they can only understand the features after they've been programming for some time already. So maybe using a plain editor with syntax highlighting and javac on the console.
    – Raku
    Commented Aug 19, 2011 at 12:02

I was involved in a class taught with Objects First and BlueJ; while I came into the class with a stronger-than-expected programming background, my classmates who did not have any prior programming knowledge continually found themselves confused by the order in which things were taught: things like teaching the specifics of using ArrayList without explaining what the term "array" means or what the term "list" means, or not explaining what "public" means until chapter 5 (after debugging!), or teaching "for-each" almost a week before "for" (based on the rate we went through the book).

They were also totally lost as to how to do the basics when they moved to Eclipse, having no idea how to get started with a project or create their objects without the specialized BlueJ interface. After about the tenth time the person I was tutoring told me "I hate how BlueJ does this", I set her up with Eclipse (which was never used or taught in our course) and had to walk her through the basics.

In essence, it's a nice idea but horribly executed within that text.

Not the answer you're looking for? Browse other questions tagged or ask your own question.