Object "Savvy"

[Jacquie Barker]

I am a professional software engineer and adjunct professor at The George Washington University. Time and again, I meet software developers who have attempted to master an OO programming language like Java by taking a course in Java, or by reading a book in Java, or by acquiring and using a Java integrated development environment (IDE) tool such as Forte, or Visual Caf�, or JBuilder, or Power J, or Kawa. However, there is something fundamentally missing: a basic understanding of what objects are all about, and more importantly, knowledge of how to structure a software application from the ground up to make the most of objects.
For those of you who are just learning Java, I am curious: did you get a good "grounding" in objects first?
------------------
author of:
Beginning Java Objects

[Rakesh Sharma]

You have raised a very logical query. It will be very nice of you if you could guide us how to structure a software application from ground.
------------------

[Daniel Searson]

No! I didn't get a grounding in objects at all. I came straight from C and tried to program Java like I would a procedural program. The results were slightly embarrassing when I look back at them. This wasn't helped by the fact that my first Java book was something like "Complete Idiot's Guide to Java" which taught applets and not much else (although it gave me a good lesson in syntax etc).
I think more books for beginners need to explain more about objects and classes first, before learning the syntax and libraries.
------------------
- Daniel

[Rob Acraman]

I self-taught myself C++ (years ago - around '85) before Java. When I first loaded on my C++ compiler, I had great fun for a day or two with all the "magical" things I could now, before I realised there was obviously a BIG something I was missing. I promptly went out and bought Booch's book.

[Allen Alchian]

Jacquie,
You've pretty well described my experience to a "Tee". My programming background is Pascal...no OOP...with some dabbling in self-taught C and Visual Basic for Applications, and some fortran experience from decades ago. I figured I could teach myself Java because other than having different syntax, how difficult could another language be?
Surprise, surprise. Sure I could easily master the basic flow control of the language, but the idea of formulating the program for an object oriented solution really floored me.
Yes, I went out and bought an IDE right away (JBuilder) and bought a couple of books too. That was back in September. Now my Java self-help library has grown to seven books and will soon include an eighth because I decided to take a beginning Java course at the local university even though I'm now finally getting the hang of writing a basic Java program. (I wish I could say that your book is included in my library. Maybe it will be...I'll have to take a look at it.) And I never use the IDE...just TextPad (which I highly recommend...and yes, I'm a registered user).
The weakness of many Java books, from my perspective, is that the authors seem to think the reader easily grasps the concept of formulating the problems as objects. With my background, that just wasn't the case. In fact, I still wonder if I could REALLY put together a full program in an OOP language...something more than the simple exercises in the Teach-Yourself books that require only one or two classes. I think I could, but I just haven't tried yet...that'll happen in the class which starts in a couple of weeks.
I also agree with Daniel about books mixing applications and applets together. And I really get frustrated with the books that provide a prepared package of inputs and outputs so your first programs will look fancy. This has you learning the author's package and not Java...a beginner can't distinguish which is which. I prefer to just take command line arguments and send output to System.out.println() for starters. That's enough to allow me to learn quite a bit of the Java basics.
So, coming to the bottom line, and the short answer to your question: "No, I didn't get a good grounding in objects first." I guess your book does that. Right?
While I've got your attention, let me just add one more point. Another area of learning Java in which I had a real struggle was interfaces. I had to read, re-read, and do more reading and studying before I finally could understand how interfaces and inheritance work together. Only after studying many examples from several books was I finally able to get a good handle on the proper role of these two concepts and how they differ and relate to each other. In short, I think this is an area that is treated too lightly by any one book.
Thanks for dropping in for an ear-full!
Allen

[Jacquie Barker]

Originally posted by Allen Alchian:
[b]Jacquie,
You've pretty well described my experience to a "Tee". My programming background is Pascal...no OOP...with some dabbling in self-taught C and Visual Basic for Applications, and some fortran experience from decades ago. I figured I could teach myself Java because other than having different syntax, how difficult could another language be?
Surprise, surprise. Sure I could easily master the basic flow control of the language, but the idea of formulating the program for an object oriented solution really floored me.
Yes, I went out and bought an IDE right away (JBuilder) and bought a couple of books too. That was back in September. Now my Java self-help library has grown to seven books and will soon include an eighth because I decided to take a beginning Java course at the local university even though I'm now finally getting the hang of writing a basic Java program. (I wish I could say that your book is included in my library. Maybe it will be...I'll have to take a look at it.) And I never use the IDE...just TextPad (which I highly recommend...and yes, I'm a registered user).
The weakness of many Java books, from my perspective, is that the authors seem to think the reader easily grasps the concept of formulating the problems as objects. With my background, that just wasn't the case. In fact, I still wonder if I could REALLY put together a full program in an OOP language...something more than the simple exercises in the Teach-Yourself books that require only one or two classes. I think I could, but I just haven't tried yet...that'll happen in the class which starts in a couple of weeks.
I also agree with Daniel about books mixing applications and applets together. And I really get frustrated with the books that provide a prepared package of inputs and outputs so your first programs will look fancy. This has you learning the author's package and not Java...a beginner can't distinguish which is which. I prefer to just take command line arguments and send output to System.out.println() for starters. That's enough to allow me to learn quite a bit of the Java basics.
So, coming to the bottom line, and the short answer to your question: "No, I didn't get a good grounding in objects first." I guess your book does that. Right?[\b][\QUOTE]
Yes, that's what I attempt to do with my book. Here's an analogy that I use in the introduction to the book:
"Imagine that you have been asked to build a house, and that you know the basics of home construction. In fact, you are a world-renowned home builder whose services are in high demand! Your client tells you that all of the materials you will need for building this home are going to be delivered to you. On the day construction is to begin, a truck pulls up at the building site and unloads a large pile of strange, blue, star shaped blocks with holes in the middle. You are totally baffled! You have built countless homes using materials like lumber, brick, and stone, and know how to approach a building project using these familiar materials; but you haven't got a clue about how to assemble a house using blue stars.
Scratching your head, you pull out a hammer and some nails and try to nail the blue stars together as if you were working with lumber, but the stars don't fit together very well. You then try to fill in the gaps with the same mortar that you would use to adhere bricks to one another, but the mortar doesn't stick to these blue stars very well. Because you are working under tight cost and schedule constraints for building this home for your client, however (and because you are too embarrassed to admit that you, as an 'expert' builder, don't know how to work with these modern materials), you press on. Eventually, you wind up with something that looks (on the outside, at least) like a house.
Your client comes to inspect the work, and is terribly disappointed. One of reasons he had selected blue stars as a construction material was that they are extremely energy efficient; but, because you have used nails and mortar to assemble the stars, they have lost a great deal of their inherent ability to insulate the home. To compensate, your client asks you to replace all of the windows in the home with thermal glass windows so that they will allow less heat to escape. You are panicking at this point! Swapping out the windows will take as long, if not longer, than it has taken to build the house in the first place, not to mention the cost of replacing stars that will be damaged in the renovation process. When you tell your customer this, he goes ballistic! Another reason that he selected blue stars as the construction material was because of their recognized flexibility and ease of accommodating design changes; but, because of the ineffective way in which you assembled these stars, you are going to have to literally rip them apart and replace a great many of them.
This is, sad to say, the way many programmers wind up building an OO application when they don't have appropriate training in how to approach the project from the perspective of objects. Worse yet, the vast majority of would-be OO programmers are blissfully ignorant of the need to understand objects in order to program in an OO language. So, they take off programming with a language like Java and wind up with a far from ideal result: a program which lacks flexibility when an inevitable 'mid course correction' occurs in terms of a change in the requirements specification, as when new functionality needs to be introduced after an application has been deployed."
My book is organized into three parts. In Part 1 (Chapters 2 - 7), I explain object concepts in detail, using just a smattering of Java (which I introduce in Chapter 1). But, since object concepts are language neutral for the most part, I deemphasize Java complexities in Part 1. Part 2 teaches you how to produce a UML object model for a Student Registration System case study; then, in Part 3, I teach you how to render the object model as a fully functional Java application, including file I/O and a GUI.

------------------
author of:
Beginning Java Objects
[This message has been edited by Jacquie Barker (edited January 01, 2001).]
[This message has been edited by Jacquie Barker (edited January 01, 2001).]
[This message has been edited by Jacquie Barker (edited January 01, 2001).]

[Jacquie Barker]

Originally posted by Allen Alchian:
[snip] While I've got your attention, let me just add one more point. Another area of learning Java in which I had a real struggle was interfaces. I had to read, re-read, and do more reading and studying before I finally could understand how interfaces and inheritance work together. Only after studying many examples from several books was I finally able to get a good handle on the proper role of these two concepts and how they differ and relate to each other. In short, I think this is an area that is treated too lightly by any one book.

Allen, here's a bit about interfaces, taken from chapter 7 of my book ... it assumes that you know what an abstract class is, so let me know if you need additional background:
Interfaces
Recall that a class, as an abstract data type, is an abstraction of a real world object from which some of the unessential details have been omitted. We [saw] that an abstract class is 'more abstract' than a 'normal' class because [we omit] the details for how one or more particular behaviors are to be performed.
Now, let's take this concept of abstraction one step further. With an abstract class, we are able to avoid programming the bodies of methods that are declared to be abstract. But what about the attributes of such a class? In our Course [abstract superclass] example, we went ahead and laid out the attributes that we thought would be needed generically by all types of courses: courseName; courseNumber; creditValue; enrolledStudents; and instructor. But, what if we only wanted to specify common behaviors, and not even bother with attributes? Attributes are, after all, typically declared to be private, and we may not wish to pin down what attributes a future class must use in order to achieve the desired public behaviors.
Say, for example, that we wanted to define what it means to teach at a university. Perhaps, in order to teach, an object would need to be able to provide the following services:
o Agree to teach a particular course;
o Designate a textbook to be used for the course;
o Define a syllabus for the course; and
o Approve the enrollment of a particular student in the course.
Each of these behaviors could be formalized by specifying a method signature, representing how an object that is capable of teaching would be asked to perform each behavior:
public void agreeToTeach(Course c);
public void designateTextbook(TextBook b, Course c);
public Syllabus defineSyllabus(Course c);
public boolean approveEnrollment(Student s, Course c);
A set of method signatures such as these, which collectively define what it means to assume a certain role (such as teaching) in the grand scheme of an application, is known as an interface. Interfaces, like classes, are given names; so, let's call this the 'Teacher' interface.
Armed with this set of method signatures, we could set about designatingvarious classes of objects as teachers. For example, we could deem Professors as being able to teach, or Students as being able to teach, or generic Person objects as being able to teach, simply by instructing the appropriate class to implement the Teacher interface using the syntax shown below:
class Professor implements Teacher {
// details omitted ...
}
What exactly does it mean for a class to implement an interface? It means that the class must override - i.e. provide method bodies for - all of the method signatures called for by the interface in question. If we fail to do so, the Java compiler will generate an error; that is, if we were to code the Professor class as shown below, implementing three of the four method signatures called for by the Teacher interface but neglecting to code the fourth method:
class Professor implements Teacher {
String name;
String employeeId;
// etc.

// Get/set methods omitted.

// We override three of the four method signatures
// called for by the
// Teacher interface, to provide method bodies.
public void agreeToTeach(Course c) {
// Logic for the method body goes here;
// details omitted.
}

public void designateTextbook(TextBook b, Course c) {
// Logic for the method body goes here;
// details omitted.
}

public Syllabus defineSyllabus(Course c) {
// Logic for the method body goes here;
// details omitted.
}
// But, we've failed to provide an implementation of the
// approveEnrollment() method!
}
If we were to try to compile this class as is, we'd get the following compiler error:
Class Professor must be declared abstract. It does not define
boolean approveEnrollment(Student, Course) from interface Teacher.
Implementing an interface is therefore virtually the same thing as having to 'flesh out' abstract methods when subclassing an abstract class. The only difference is that, with an interface, we typically specify abstract behaviors only, whereas an abstract class specifies a data structure (attributes) as well as a mixture of abstract and concrete behaviors. So, in terms of the 'abstractness spectrum', an interface is even more abstract than an abstract class (which is in turn more abstract than a 'regular' class) because an interface leaves even more details out of the picture.
(As we'll see in Chapter 13, an interface is also capable of defining constants.)
A class may be instructed to implement as many interfaces as desired. For example, if we were to invent a second interface called 'Administrator', which specified the following method signatures:
public boolean approveNewCourse(Course c);
public boolean hireProfessor(Professor p);
then we could instruct a class to implement both the Teacher and Administrator interfaces:
class Professor implements Teacher, Administrator { ... }
in which case the class would need to override all of the method signatures called for by both of these interfaces.
When a class implements more than one interface, it effectively assumes multiple identies or roles, and its 'handle' can therefore be managed by various types of reference variables. Based on the preceding definition of a Professor as both a Teacher and an Administrator, the following code would be possible:
// We instantiate a Professor object, and store its 'handle'
// in a reference
// variable of type Professor.
Professor p = new Professor();
Teacher t;
Administrator a;
t = p; // We store a 'handle' on the Professor in a reference
// variable of type Teacher!
a = p; // We store a 'handle' on the Professor in a reference
// variable of type Administrator!
as illustrated conceptually in the figure below. [FIGURE MISSING]
This is conceptually the same thing as you, as a person, being viewed as having different roles by different people: you are viewed as an employee by your manager, as a son or daughter to your parents, perhaps as a parent to your children, and so forth.
Note that not all OO languages embrace the notion of interfaces. For example, Java does, but C++ does not. It is Java's provision for a class to be able to implement multiple interfaces that justified the Java language designers from doing away with multiple inheritance, as we discussed in Chapter 5."
I hope this helps!
------------------
author of:
Beginning Java Objects

[Jacquie Barker]

Originally posted by Rakesh Sharma:
You have raised a very logical query. It will be very nice of you if you could guide us how to structure a software application from ground.

Rakesh, my book does just that - but it takes over 600 pages! I cannot do justice to the entire topic in this forum, but I'd be happy to answer specific questions that you might have about object topics and/or Java.
Regards,
Jacquie
------------------
author of:
Beginning Java Objects

[Allen Alchian]

Wow Jacquie, that's great!
I copied your response into my word processor and I'm formatting it so I can study it is detail. I also got your other "snippet" that you inserted into the other thread here in the Beginners forum, and I'm working my way through it. I really like the way you step through the process of developing the Student Registration System application. I'm definitely going to have to check out your book at the local bookstore.
Many thanks!

[l haydu]

Before I started learning Java, I had experience with Borland's Delphi and also had a course in C++. I learned Delphi on the job because that was the development software of choice of the company I was working for at the time. It wasn't until I started learning Java that some of the unfamiliar keywords and concepts in Delphi became really clear; e.g., abstract, class methods, interfaces, overload and override. Until I learned Java, I never really knew what those things meant and how to use them. I am looking forward to using Java this year for some projects at work.

[JC Cook]

Jacquie,
It seems with most efforts at teaching OOP, authors and teachers feel the need to be very basic with beginners, using simple analogies and starting the reader with easy coding exercises. This is good, in that it gives the new student a sense of accomplishment, but bad in that he never develops an understanding of how objects are actually used in real life, how to design with objects, etc. We read books and take classes, and all we really understand is that a "car is a vehicle".
Hooray for you showing us a real-world example with design preceding development! Learning how to pound a nail teaches us little about how to design and build a house. Knowing how to do the latter makes learning to pound nails almost trivial. I'm anxious to get your book.
Here's a java greenhorn question, prefaced by some rhetoric:
In my experience, implementing any kind of discipline, such as good object oriented design and development, depends heavily on upper level management buying into its benefits and mandating its implementation. For lowly coders to embrace OOP is fine, but do you find many top level people in business who really understand and appreciate the value of OOP, and who require correct practices?

[Bob Young]

I also am in the steep learning curve phase of Java. I went out and purchased a beginning java book and now about 9 months latter I have 6 Java books. I am now getting more comfortable with the syntax and I realized the need to understand objects more throughly than what the beginning books described. The beginning books just describe it as sending messages to the objects and presto it happens! We all know that this is very simplistic. I was considering purchasing Timoth Budd's book but based on what I read, your book may be better for me.

[Ed Lance]

Great point...I have to agree with most everyone else, not well grounded in OO concepts before learning Java. Which leads to another question. Is is possible to totally understand OO concepts without implementing them in some language/program? Seems as if one needs to keep reading/learning theory and then trying to implement the new knowledge in a program to really become a master!

[Brian Tomlin]

Jacquie,
I also come from a non-OO programming background and I have been having somewhat of a difficult time grasping OO concepts. In fact, I posted a comment requesting guidance in this topic just last month on the Java College forum here at JavaRanch.
I too have bought a couple of Java Books and I feel fairly comforatable with the syntax of Java and most of the terms used in OO languages, but I still have a hard time Thinking in objects.
My goal is to get to the point where I could sit down and DESIGN an object oriented application and feel confident that I have utilized OO techniques adequately. I also have not had a lot of modeling experience and I am looking forward to reading part 2 of you book. I'm sure it's hard to include everything, but how much detail do you go into as far as the modeling part?
Thanks for your time,
Brian

[Jacquie Barker]

Originally posted by l haydu:
Before I started learning Java, I had experience with Borland's Delphi and also had a course in C++. I learned Delphi on the job because that was the development software of choice of the company I was working for at the time. It wasn't until I started learning Java that some of the unfamiliar keywords and concepts in Delphi became really clear; e.g., abstract, class methods, interfaces, overload and override. Until I learned Java, I never really knew what those things meant and how to use them. I am looking forward to using Java this year for some projects at work.

The first seven chapters of my book are devoted to explaining all of these concepts, and MORE, in great detail! I'd encourage anyone who is "fuzzy" on object concepts to check it out (and, feel free to post specific questions that I might be able to answer for you in the meantime!).
------------------
author of:
Beginning Java Objects

[Jacquie Barker]

Originally posted by JC Cook:
Jacquie,
It seems with most efforts at teaching OOP, authors and teachers feel the need to be very basic with beginners, using simple analogies and starting the reader with easy coding exercises. This is good, in that it gives the new student a sense of accomplishment, but bad in that he never develops an understanding of how objects are actually used in real life, how to design with objects, etc. We read books and take classes, and all we really understand is that a "car is a vehicle".
Hooray for you showing us a real-world example with design preceding development! Learning how to pound a nail teaches us little about how to design and build a house. Knowing how to do the latter makes learning to pound nails almost trivial. I'm anxious to get your book.
Here's a java greenhorn question, prefaced by some rhetoric:
In my experience, implementing any kind of discipline, such as good object oriented design and development, depends heavily on upper level management buying into its benefits and mandating its implementation. For lowly coders to embrace OOP is fine, but do you find many top level people in business who really understand and appreciate the value of OOP, and who require correct practices?

Great question, JC! Here are my "real world" experiences.
First of all, as with any new technology, the first OO project that an organization undertakes will actually take LONGER than the same project would have taken using an already established technology, because the project team has TWO learning curves to conquer: understanding how to structure a problem from the perspective of objects, and then of course mastering the OO language of choice (Java, C++). (If the organization is already skilled with OO techniques using another language, say C++ or Smalltalk, then picking Java up is relatively painless.) So, right out of the chute, you may have trouble convincing management to let you adopt a new paradigm when you cannot promise immediate cost savings.
An OO approach will pay off big time in the long run, however -- IF an application is properly designed from the perspective of objects -- in that:
1. The code will be much more flexible/less "brittle" when new requirements are introduced;
2. The code should lend itself more readily to reuse because the building blocks -- classes -- are very modular, self contained packages. It's like the difference between trying to recycle all of the plumbing from one house -- INTACT -- in a second home versus using the individual pieces of pipe, which are infinitely more reconfigurable.
So, as with any new technology, if you are fortunate enough to work for a management team who is technically savvy and who has monitored industry developments, they'll already appreciate the long-term benefits to an organization of using OO approaches and technologies. If, on the other hand, you work for a management team who does not have such technical "vision", then I would sell Java on a different front -- namely, the cost savings that can be realized from developing platform-independent code. (I consult for the Government, and about every two to three years they were rewriting critical applications so as to port them from one operating system platform to another -- when I introduced them to Java a few years ago, they soon realized that developing applications in Java would break that very costly cycle.)
------------------
author of:
Beginning Java Objects

[Jacquie Barker]

Originally posted by Bob Young:
I also am in the steep learning curve phase of Java. I went out and purchased a beginning java book and now about 9 months latter I have 6 Java books. I am now getting more comfortable with the syntax and I realized the need to understand objects more throughly than what the beginning books described. The beginning books just describe it as sending messages to the objects and presto it happens! We all know that this is very simplistic. I was considering purchasing Timoth Budd's book but based on what I read, your book may be better for me.

Bob, I am delighted that you are considering buying my book! I have been teaching object technology and Java
courses at the university level for almost five years, and the book is based on material that has been "road tested"
and "fine tuned" by hundreds of students ... I hope you enjoy it!
------------------
author of:
Beginning Java Objects

[Jacquie Barker]

Originally posted by Ed Lance:
Great point...I have to agree with most everyone else, not well grounded in OO concepts before learning Java. Which leads to another question. Is is possible to totally understand OO concepts without implementing them in some language/program? Seems as if one needs to keep reading/learning theory and then trying to implement the new knowledge in a program to really become a master!

Ed, in my opinion, I think you do have to ultimately sling some code in order to fully appreciate the OO paradigm, which is why I always insist on introducing my Object Methods students to a bit of code (originally, C++, but now Java) even if they don't plan on doing any programming professionally. I've found that doing so really helps to "cement" the concepts. In fact, in my book, I actually cover each concept THREE TIMES:
First, in part 1, I explain OO concepts at the conceptual level, with some simple Java thrown in.
Then, in part 2, I revisit these concepts from the context of developing an object model, or "blueprint", of a system to be built.
Finally, in part 3, you see the concepts put to use in depth within the context of a working Java application.
------------------
author of:
Beginning Java Objects

[Jacquie Barker]

Originally posted by Brian Tomlin:
Jacquie,
I also come from a non-OO programming background and I have been having somewhat of a difficult time grasping OO concepts. In fact, I posted a comment requesting guidance in this topic just last month on the Java College forum here at JavaRanch.
I too have bought a couple of Java Books and I feel fairly comforatable with the syntax of Java and most of the terms used in OO languages, but I still have a hard time Thinking in objects.
My goal is to get to the point where I could sit down and DESIGN an object oriented application and feel confident that I have utilized OO techniques adequately. I also have not had a lot of modeling experience and I am looking forward to reading part 2 of you book. I'm sure it's hard to include everything, but how much detail do you go into as far as the modeling part?
Thanks for your time,
Brian

Brian, I strongly encourage you to focus on Part 1 of the book, too, because it lays the groundwork for why objects are so powerful.
Quoting from Chapter 8 of my book:
"In recent years, there has been a major push in the industry to meld the best ideas of competing methodologies into a single approach, with particular emphasis being placed on coming up with a universal modeling notation. The resultant notation, known as the Unified Modeling Language (UML), represents the collaborative efforts of three of the leaders in the OO methodology field - James Rumbaugh, Grady Booch, and Ivor Jacobsen - and has become the industry standard object modeling notation. (You'll learn the basics of UML in Chapters 10 and 11.) Along with the UML, these three gentlemen - known affectionately in the industry as the 'Three Amigos'- have also contributed heavily to the evolution of an overall methodology known as the Rational Unified Process (RUP), a full-blown software development methodology encompassing modeling, project management, and configuration management workflows. But, we aren't going to dwell on the details of this particular methodology in this book, because as we mentioned in the Introduction, it is not our intention to teach you any one specific methodology in great detail. By teaching you a sound, generic process for object modeling, you will be armed with the knowledge you need to read about, evaluate, and select a specific methodology such as RUP, or to craft your own hybrid approach by mixing and matching the processes, notation, and tool(s) from various methodologies that make the most sense for your organization."
Then, later on:
"It is important to keep in mind that a methodology is but a means to an end, and it is the end - a useable, flexible, maintainable, reliable, and functionally correct software system, along with thorough, clear supporting documentation- that we care most about when all is said and done. [...] the real legacy of a software development project is the resultant software system, which is, after all, the reason for using a methodology to produce a model in the first place. We must take care to avoid getting so caught up in debating the relative merits of one methodology versus another that we fail to produce useful software � there are many paths to the same destination."
So, while I do indeed introduce you to use case analysis in Chapter 9, and UML notation in Chapters 10 and 11, my book is not an in-depth treatment of every bell and whistle of these techniques -- there are entire books devoted just to those topics. What my book DOES give you, however, is (a) a common sense understanding of WHY we do what we do when we model, and (b) insight into how to translate an object model into Java code.
Thanks for your interest!
------------------
author of:
Beginning Java Objects

[Brett Knapik]

Bruce Eckels "Thinking in Java" does a great job introducing OOP. After I read it, I never have a doubt in my mind on how OOP works.
------------------
I wish there was a button on my monitor to turn up the intellegince.
Theres a button called 'brightness' but it doesn't work

[zulfiqar raza]

I came from a procedural programming background, and it took time and effort to learn object oriented programming techniques. The basic concepts are not hard, but applying those concepts when you are used to procedural programming is the harder part.
I think programming in Delphi has helped me grasp some of the concepts, in addition to good books, such as:
Bruce Eckel's "Thinking in Java",
Khalid Mughal's "A Programmer's Guide to Java Certification"
Craig Larman's "Applying UML and Patterns"
I also wasted a lot of money on books which claimed to cover Object Oriented Programming but did nothing of the sort. I have not yet seen a single book which can properly teach OOP concepts. If Jacquie's book can really do that, than it would indeed be a unique book.
The above three books combined, I believe gave me a good understanding and working knowledge + doing OO projects.
zulfiqar raza

[This message has been edited by zulfiqar raza (edited January 02, 2001).]

[Jacquie Barker]

Originally posted by zulfiqar raza:
I came from a procedural programming background, and it took time and effort to learn object oriented programming techniques. The basic concepts are not hard, but applying those concepts when you are used to procedural programming is the harder part.
I think programming in Delphi has helped me grasp some of the concepts, in addition to good books, such as:
Bruce Eckel's "Thinking in Java",
Khalid Mughal's "A Programmer's Guide to Java Certification"
Craig Larman's "Applying UML and Patterns"
I also wasted a lot of money on books which claimed to cover Object Oriented Programming but did nothing of the sort. I have not yet seen a single book which can properly teach OOP concepts. If Jacquie's book can really do that, than it would indeed be a unique book.

Thanks for your comments! I would agree wholeheartedly that Bruce Eckel's book is great; in fact, there are LOTS of great books out there that talk individually about Java, and/or object concepts, and/or object modeling. I was "moved" to write my book because I couldn't find a SINGLE book that covered object concepts, AND object modeling, AND Java programming all rolled into one! Knowing how much students hate to pay for textbooks (!), I wanted to enable them to buy one book that could potentially carry them through two semesters (!) -- Object Methods, then Java Programming.
Of course, only with time will I know whether I've truly succeeded in my mission (the book was only released about a month ago); but, so far, the reviews on Amazon.com have been encouraging.
Thanks again for your comments!
------------------
author of:
Beginning Java Objects

[Sean Casey]

My experience was in an accelerated 10 week course which covered everything from language fundamentals all the way to networking with jdbc. I stress the word accelerated. The class met once a week for 6 hours and we crammed everything in. I felt slighted by the fact that I invested over 2000 dollars and I was never given a chance to fully grasp the fundamentals of inheritance and composition with objects. As I prepare for the SCJP2, I am finally grasping the importance of objects.

[Mamta Murthy]

Hello Jackie,
I have been in the teaching field for a number of years and was teaching Java for the past year or so. During this period I needed some really good Java books which would also cover object oriented concepts on a proper basis. But I was disappointed not fo find ANY single perfect book. I mean, while there were books to cater to certain topics, the same books lacked information in other areas. As a result I had to read through 5 or 6 books at a time to get a clearer understanding of how things worked in Java. As for grounding basics in object oriented programming with Java, the less said the better-it's that bad! As a faculty I had to make sure that my students did not lose out on anything that might be relevant to them in their future jobs but the course was structured in such a way that there was really no time to delve deep into the OOP basics. A vast number of such courses are out there in the market and students do not really know what they are missing by not going deep into the OOP basics.
What I felt all along while teaching the course was that I should write a book myself to cater to all such needs(I mean I know the things I was looking for and didnt find..there might be others like me!) . Now reading your comments I really feel glad someone is taking the effort to do this. I can only hope that I also can make such a difference as you did!
Regards
Mamta

[Kalpesh Soni]

I think for c++ or for java, bruce eckel gives you really good introduction of objects
I have been into programming for just one year, started with c then c++ and now java, i am presently preparing for new SCJP2. I think bruce eckel is just like a god to me


[This message has been edited by kalpesh soni (edited January 08, 2001).]

[Anil Vupputuri]

Hi,
I would like to ask u a question in deciding to choose abstract class or Interface, as i read one book on Design Patterns which its given as
Program to an interface and not to an implementation
purring this more succinctly,you should define the top of any class heirarchy with an abastract class which implements no method, but simply defines the methods that class will support.Then ,in all of our derived classed u have more freedom to implement these methods as most suits our purpose.
The other major concept you should recognize is that of object composition.This is simply the construction of objects that contain others:encapsulation of several objects inside another one.

While many beginning OO programmers use inheritance to solve every problem,as you begin to write more elaborate programs, the merits of object composition become apparent.Your new object can have the interface that is best for what you want to accomplish without having all the methods of the parent classes .
Thus, the second major precept suggested by Design patterns is
Favor object composition over inheritance
so which approach would u suggest.

[Kalpesh Soni]

well
you should always prefer interfaces to abstract class
1. you can make abstract class with no implementation of method
<bt>but then there is no use of making it an abstract class, interface will be better
2. if you make it an interface you solve the multiple inheritence problem

as your derived class can now implement as many interfaces as you wish
3. When you are FORCED to give some default implementation of a method, you cannot afford to make it abstract then you can go for abstract class

as far as composition and inheritance goes , that is mostly about the point of view i guess

a simple examples is this:
a shirt is composed of a collar (so use composition here)
but a cat is a type of animal
so use inheritance
i hope this helps !

[Lokesh katta]

Hello jacquie,
Wish you a happy new year.
I am software programmer(Also SCJP) .I directly learnt Java without any programming background.
In fact I was happy enough i had a very good tutor who taught me java basics very clear.
But as any programmer does I concentrated more on syntax rather than oops concepts
I also got a good insight of what objects are?
But after coding for an about 8 months in different projects, Now when i am trying to design a project(modeling it) i am finding lots of difficulties in the decision making process of how to design your objects so that they are flexible for future requirement changes and also as when to use which patterns,etc.
Do you explain all these intricacies of objects ?
I am planning to buy it if you are really doing it..
Lokesh

[Jacquie Barker]

Originally posted by kalpesh soni:
I think for c++ or for java, bruce eckel gives you really good introduction of objects
I have been into programming for just one year, started with c then c++ and now java, i am presently preparing for new SCJP2. I think bruce eckel is just like a god to me

Kalpesh, I'm glad to hear you've reached "Java Nirvana"!
Regards,
Jacquie
------------------
author of:
Beginning Java Objects

[Mark Ott]

J,
I am a PhD chemist who is going back to learn his 'other' first love, programming. I did quite a bit of Pascal programming in grad school, so I figured I could learn Java with little difficulty. What I did (and what I urgently suggest) is a text on OO programming with Java. The text I used (self taught) was 'An intorduction to OO programming With Java by Thomas Wu (his book site is http://www.drcaffeine.com ) It introduces OO programming great and gives you a bare bones start to Java in general. I am now studying for the SCJP exam, and my previous reading really did help.
My $0.02....
M

[Steve Fahlbusch]

Greetings Jacquie,
I have found in teaching about OOP that it greatly helps for students to have a grounding in the more procedural and a very good grasp on the syntax. Then the object paradigm shift happens a lot sooner.
In '93 I was retraining a group (approx 125) to retask from current activities to a "software engineering" track. Classes ranged for about 4 weeks.
Given the group (some had never used a PC)we started with "this is a PC", then apps (word, excel, access), basic, then c++, oop in c++, team oop project.
The c++ class was very much procedural oriented, functional decomposion, stressing the syntax of the language (used Stroustrap). When we hit OOP (was using Coad and Nicola - OOP) It took about two weeks for almost all "get it".
I still quite often teach, use a similar approach to the above and am always on the lookout for a good text. I have not yet looked at your book but have hopes it will be as useful as Coad's (Great book, great approach, very good smalltalk code, not so good c++ code).
Steve

[Jacquie Barker]

Originally posted by Anil Vupputuri:
Hi,
I would like to ask u a question in deciding to choose abstract class or Interface, as i read one book on Design Patterns which its given as
[b]Program to an interface and not to an implementation
purring this more succinctly,you should define the top of any class hierarchy with an abstract class which implements no method, but simply defines the methods that class will support. Then,in all of our derived classed u have more freedom to implement these methods as most suits our purpose.
The other major concept you should recognize is that of object composition.This is simply the construction of objects that contain others:encapsulation of several objects inside another one.

While many beginning OO programmers use inheritance to solve every problem,as you begin to write more elaborate programs, the merits of object composition become apparent.Your new object can have the interface that is best for what you want to accomplish without having all the methods of the parent classes .
Thus, the second major precept suggested by Design patterns is
Favor object composition over inheritance
so which approach would u suggest.
[/B]

Mr. Kalpesh Soni has already given a great, succinct reply to your question, which I'd like to embellish upon.
You have actually posed several issues: (a) the pros and cons of implementing interfaces vs. using inheritance; (b) the use of abstract classes as root classes for all inheritance hierarchies; (c) the use of object composition versus inheritance. Please allow me to respond to each separately.
---------------------------------
(a) Interfaces vs. Inheritance
Think of a method signature as the way that you communicate with an object to request it to perform a service, and the method code body as instructions to that object as to HOW it should perform the service. The combined collection of all method signatures that a particular class recognizes represents all of the services that the object can perform. Now, the question is, how do we instruct a class as to what its method signatures should be?
For a given signature, you can either:
(1) Create a parent class which defines the method signature as a concrete method, in which case you've not only provided a method signature but also a default method body for the subclasses to inherit (and optionally override);
(2) Create a parent class which defines the method signature as an abstract method, without a code body;
(3) Create an interface, which also defines the method signature without a code body.
The decision of whether to use inheritance or interfaces (or a combination of the two) boils down to whether there are things besides method signature that need to be passed along: method bodies; attributes; etc. If the only thing that I wanted to communicate were method signatures, I would opt for implementing an interface.
Implementing an interface is virtually the same thing as having to 'flesh out' abstract methods when subclassing an abstract class. The only difference is that, with an interface, we typically specify abstract behaviors only, whereas an abstract class specifies a data structure (attributes) as well as a mixture of abstract and concrete behaviors. So, in terms of the 'abstractness spectrum', an interface is even more abstract than an abstract class (which is in turn more abstract than a 'regular' class) because an interface leaves even more details out of the picture.
-------------------------
(b) Abstract classes as root classes
There is one school of thought which states that one should only instantiate leaf classes in an inheritance hierarchy. That is, if we had the hierarchy:
class Person
class Student extends Person
class GraduateStudent extends Student
class UndergraduateStudent extends Student
then you'd want to avoid instantiating Person and Student directly, and only create objects of type GraduateStudent and UndergraduateStudent. (I don't necessarily adhere to this school of thought, by the way.) Nonetheless, one way to prevent instantiation of Person and Student would be to declare them both to be abstract (with Java, by the way, this can be done even if all of the methods in these classes are concrete; the same is not true of C++).
But, I have developed numerous applications in which the root classes have been concrete.
------------------------
(c) Composition vs. Inheritance
These two techniques are not mutually exclusive; think of them as two alternative tools in a toolbox -- say, a hammer and a screwdriver. For some jobs, one of these is clearly superior to the other, but for other jobs (say, pulling up a carpeting staple), either one will do.
First of all, there is disagreement in the field as to what composition really means.
o To some, it means the use of inner classes such that one class "engulfs" another, with the "engulfed" objects living wholly within the containing class. Consider a grade book used to track student performance in a particular course. If we were to define a GradeBook class, and then create GradeBook objects as attributes - one per Course object - then it might be reasonable for each GradeBook object to exist wholly within its associated Course object. No other objects would need to communicate with the GradeBook directly; if a Student object wished to ask a Course object what grade the Student has earned, the Course object might internally consult its embedded GradeBook object, and simply hand a letter grade back to the Student.
o To others (myself included), it simply means that one object may maintain handles on other objects (in the form of attributes) to which it delegates service requests. This definition encompasses the previous notion of "engulfed" objects along with objects that live externally to one another, but which are connected via handles. For example, if a Student object has an attribute facultyAdvisor of type Professor, then although the Professor object lives externally to the Student object, the Student object may still call upon it to perform behaviors whenever necessary. (We ask the student who its advisor is via the method call getAdvisorName(); and, internally to that method, the Student is calling upon its advisor for the answer:
class Student {
Professor facultyAdvisor;
// details omitted

public String getAdvisorName() {
// Delegation at work.
return facultyAdvisor.getName();
}
}
================
The bottom line is that that you must always strive to create classes that are proper abstractions of the real world. In doing so, we use various techniques -- composition, inheritance, delegation, interfaces -- to achieve the desired effect. So, there are no simple answers as to one technique always being better than another.
Regards,
Jacquie
------------------
author of:
Beginning Java Objects
[This message has been edited by Jacquie Barker (edited January 03, 2001).]
[This message has been edited by Jacquie Barker (edited January 03, 2001).]

[Jacquie Barker]

Originally posted by Lokesh katta:
Hello jacquie,
Wish you a happy new year.
[snip] Now when i am trying to design a project(modeling it) i am finding lots of difficulties in the decision making process of how to design your objects so that they are flexible for future requirement changes and also as when to use which patterns,etc.
Do you explain all these intricacies of objects ?
I am planning to buy it if you are really doing it..
Lokesh

Lokesh, thanks for your inquiry. My book is truly a beginning level book, so my goal is to introduce the rationale for why we need to do all of the things that we must do when developing an object oriented application. It is, in essence, a starting point from which folks may branch out once they understand the "big picture". So, for example, on the subject of design patterns, I explain the concept of what a design pattern is in Chapter 12, but then refer readers to other books written exclusively on that topic.
The best bet would be for you to browse through a copy at your local bookstore to see if you have already advanced past the level that I cover ...
Regards,
Jacquie
------------------
author of:
Beginning Java Objects

[Jacquie Barker]

Originally posted by Sean Casey:
My experience was in an accelerated 10 week course which covered everything from language fundamentals all the way to networking with jdbc. I stress the word accelerated. The class met once a week for 6 hours and we crammed everything in. I felt slighted by the fact that I invested over 2000 dollars and I was never given a chance to fully grasp the fundamentals of inheritance and composition with objects. As I prepare for the SCJP2, I am finally grasping the importance of objects.

WOW! I wouldn't wish that intense a learning curve on anyone! Here's my recommended approach to learning Java (from Chapter 17 of Beginning Java Objects, copyright 2000 Jacquie Barker):
Jacquie's 'Tried and True' Method for Learning Java Properly
1. Understand OO analysis and design - hopefully, this book has gone a long way toward helping you to accomplish this, and our recommended reading suggestions later in this chapter will help you to deepen this understanding.
2. Obtain a good beginning book on Java - again, this book has hopefully given you a good jump start with the language, and you can follow that up by obtaining a copy of Ivor Horton's Beginning Java 2.
3. Download and install a free copy of the latest release of the Java 2 Platform, Standard Edition (J2SE) Software Developer's Kit from Sun's website as described in Appendix C.
4. Compile and run a simple 'Hello, World' program from the command line to ensure that all Java SDK components are installed and working properly.
5. Choose a simple first problem to automate: one that (a) you are very familiar with the requirements for - perhaps an application that you have already built in some other language, or an application based upon some hobby - and (b) which only requires a handful of domain classes when modeled.
6. Produce a class diagram for your application based on the object modeling techniques that we learned in Part 2 of the book.
7. Write the code for your 'core' model classes, and get the application to work as a command-line driven application first as we did for the Student Registration System (SRS) in Chapter 14. (This is your model, without a graphical view.)
8. Learn more about the Java Abstract Windowing Toolkit and Swing components for constructing GUIs, and buy a good reference book(s) about this subject.
9. Add a GUI front-end onto the code you produced in step 7, as we did for the SRS in Chapter 16. My personal bias is that you do so by writing the GUI code from scratch, without using a 'drag and drop' GUI building tool, as I believe that you learn GUI concepts more thoroughly by doing so.
10. Learn about the Java Database Connectivity (JDBC) API, and buy a good reference book about this subject.
11. Acquire the appropriate JDBC driver for your particular DBMS, if necessary. Or, check my website for links regarding free, single-user DBMS's in the public domain that are ideal for educational use.
12. Connect your application to a database 'back-end' so as to persist your objects. You may wish to experiment with an object DBMS (ODBMS) vs. a relational DBMS.
13. (Optional) If you are inclined to use an integrated development environment (IDE), invest in a commercially available Java IDE such as Kawa or Symantec Caf�, or investigate Sun's Forte IDE, which is available as a free download from Sun's website. Make sure to avoid any IDE that introduces platform-dependent extensions to the Java language - focus on producing 100% pure Java code for ultimate portability whenever possible. (My personal bias is to avoid drag and drop GUI builders; the time you save in creating the GUI may be ultimately lost when you try to work around the code that was automatically generated.)
14. From this point forward, your options are open-ended! For example, you may wish to become familiar with Java 2 Enterprise Edition, which provides support for enterprise-level server-side applications; you may wish to study up on the Java 2D and 3D graphics APIs; or your interests may lie with the Java 2 Micro Edition (J2ME), a highly optimized Java runtime environment targeting consumer products such as cellular phones and pagers. Whichever direction you choose to take, you can rest assured that there will be plenty of new Java-related innovations in the months and years to come.
------------------
author of:
Beginning Java Objects
[This message has been edited by Jacquie Barker (edited January 03, 2001).]

[Steve Hayes]

About Java Nivana...
Bruce Eckel's books are v.good. I recently purchased his new CDROM which has some MP3 audio files that I load on my player as I while away the hours getting to work across London (takes hours at the moment). However, Jacquie, I really like your description of 'Interfaces' and also the earlier description of why it's essentially to understand 'why it is you're walking and where you're going' rather than thinking 'hey I can walk!' Another book in the collection is always useful 'cos there's always another way of delivering a complex idea so that in the end it sticks. The way you present things seems straightforward, intelligent without being too highbrow. Just the kind of book I can digest. I'm looking to take SCJP in the next three months and although I think I have many of the concepts, faced with putting together a large bit of software in Java I think I might end up scratching my head. I've been looking for a book that goes through a largish realworld example for sometime that also gets across many important concept I'm going to need to know. Yours sounds v.tempting. What does it cover that's important for the SCJP exam? ) Steve

[Jacquie Barker]

Originally posted by Steve Hayes:
About Java Nivana...
Bruce Eckel's books are v.good. I recently purchased his new CDROM which has some MP3 audio files that I load on my player as I while away the hours getting to work across London (takes hours at the moment). However, Jacquie, I really like your description of 'Interfaces' and also the earlier description of why it's essentially to understand 'why it is you're walking and where you're going' rather than thinking 'hey I can walk!' Another book in the collection is always useful 'cos there's always another way of delivering a complex idea so that in the end it sticks. The way you present things seems straightforward, intelligent without being too highbrow. Just the kind of book I can digest. I'm looking to take SCJP in the next three months and although I think I have many of the concepts, faced with putting together a large bit of software in Java I think I might end up scratching my head. I've been looking for a book that goes through a largish realworld example for sometime that also gets across many important concept I'm going to need to know. Yours sounds v.tempting. What does it cover that's important for the SCJP exam? ) Steve

Steve, thanks for your support and encouragement! Yes, there are indeed many different ways of explaining the same thing, and my hope is that the way I have chosen will suit enough people to have made writing the book worthwhile.
Having also taken the SCJP test, I am sorry to say that most of what you'll need to know for that exam is trivia concerning some oddities of the Java language; the exam goes out of its way to trip you up with code examples that contain minor subtleties. So, I'd recommend getting a study guide specifically geared toward the SCJP. My book will be much more useful in preparing to take the follow-on Certified Java DEVELOPER's Exam, in which you are expected to actually code an application, then answer questions about your application design as an on-line exam.
The book I used for the SCJP exam, Boone/Stanek's "All-In-One Java 2 Exam Guide", was promising in terms of its chapter organization, but the edition I got (a first release) was RIDDLED with non-trivial typos! So, unless they've released a newer version in which the typos have been corrected, I'd search for a different book.
Good luck!
------------------
author of:
Beginning Java Objects

[Peter Tran]

Hi Jacquie,
Regarding your initial inquiry that started this discussion thread, I think most people (correct me if I'm wrong) have a difficult time grasping OOA/OOD/OOP when they first start doing it. It's only with much practice with trial and error that the concept of "object-oriented" anything finally sinks in.
For me, it�s like having an object-oriented light bulb inside my head. The more I worked with objects the brighter the bulb got. When I run into a difficult concept and the bulb would flicker (e.g. when I was trying to figure out when to use abstract class vs. interfaces), but after I grasp the concept and figured out what to do than the bulb would get brighter. I would like to think that my object-oriented light bulb is getting brighter by the day.
Here�s a personal example. I didn�t grasp the nuances of interfaces until I had to use the JAVA 2 Collections Framework. The collection classes are defined via a handful of interfaces (e.g. List, Maps, Set, etc.). The first time I started using these classes, I was instantiating an object of the derived class with the reference type from the same derived class!
java.util.ArrayList aList = new java.util.ArrayList();
What was worse was I wrote all methods to accept an ArrayList.
public void accumulateValueInList(ArrayList theList) {
// Iterate through list and accumulate value.
}
After littering my code with the above code, I was then told to use a LinkedList. My first reaction was �No!!!� - because I would have to change my method signature from ArrayList to LinkedList (and I had a lot of methods coded this way). Only after going through this painful exercise did I realize that it would have been a lot less painful, if I initially used the interface as my reference type.
public void accumulateValueInList(java.util.List theList) {
// Iterate through list and accumulate value.
}
Now I only had to change where I instantiated the collection object, and none of my methods needed to change.
Regards,
-Peter Tran

[Sean MacLean]

Jacquie,
Regarding the original question, I was fortunate enough to enter my BCs degree at the exact time that all of the courses where switching to Java. Therefore, the approach from day one was object based. I think completely in terms of objects when I design and code because I've never had a grounding in procedural programming (well, a term of Basic years ago, but I got over that). As well, the degree required several OO courses including a course on OOP examining and programming in 5 different languages, a course in OO design techniques and a Software Engineering course in Java. Hopefully, this is the trend for most degrees now. I can't imagine programming in Java without a thorough knowledge of OO basics. It would be like driving a Porche in first gear and not knowing that you can shift!
Sean

[Steve Hayes]

"Steve, thanks for your support and encouragement! Yes, there are indeed many different ways of explaining the same thing, and my hope is that the way I have chosen will suit enough people to have made writing the book worthwhile.
Having also taken the SCJP test, I am sorry to say that most of what you'll need to know for that exam is trivia concerning some oddities of the Java language; the exam goes out of its way to trip you up with code examples that contain minor subtleties. So, I'd recommend getting a study guide specifically geared toward the SCJP. My book will be much more useful in preparing to take the follow-on Certified Java DEVELOPER's Exam, in which you are expected to actually code an application, then answer questions about your application design as an on-line exam.
The book I used for the SCJP exam, Boone/Stanek's "All-In-One Java 2 Exam Guide", was promising in terms of its chapter organization, but the edition I got (a first release) was RIDDLED with non-trivial typos! So, unless they've released a newer version in which the typos have been corrected, I'd search for a different book."
Thanks Jacquie for your honest reply. For the interest of others I've been using "The Complete Java 2 - Certification Study Guide" by Roberts, Heller & Ernest. Whilst other books are OK (even excellent in the case of Bruce E's Thinking in Java) as you say it's worth having a book that focuses on what you need to know for the exam.
But for the greater goal of being comfortable with the overall concepts I will browse through your book and probably buy it anyway. Once you find a good Java book it's hard not to miss the opportunity. I'll still be trying to convince my girlfriend of this when I sneak yet another Java book into the house.
More volumes = less volume!!!

[Anne Yang]

Since I am not familiar with the book giveaway discussion, I posted my thoughts as a new topic. Now I am moving my response to its right place.
After I passed the SCJ2P exam over a month ago, I started looking for an entry-level java programmer position. Even though I have a Ph.D. degree, experience and a partial certification in Oracle, five years of experience as a mainframe programmer, I haven't got any job offer. I was in a couple of interviews, but after telling the interviewers that I have no java work experience, and know only some HTML besides java within the set of technologies they are interested in, I was out of luck. Lots of interviewers ask me about web-related technologies such as javascript, asp, jsp, xml, corba, etc, which are within my expectation. But surprisingly, the most commonly asked question is about UML! I ordered a book on UML just a few days ago. But when I learned about Beginning Java Objects, the book that javaranch is promoting this week, I rushed to order one. The reviews on this book are very good, and the book is already out of stock at
bookpool. For those java beginners who's also stuck like me, I would recommend this book. From what the author wrote in this discussion, the book sounds exactly like what I am looking for---OOD in Java, and knowledge on UML will definately help in job hunting.
Jacquie:
A very broad question: Do you think SCJ2P plus a good digestion of you book would give us some firm grips on entry-level java positions? If not, what steps do you recommend to follow?
Thanks much!