Object "Savvy"

[Jacquie Barker]

Originally posted by 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

GREAT example, Peter! That leads me to this excerpt from the book:
"Say that we have a class declared as follows:
class Professor implements Teacher, Administrator { ... }
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();
// We may also store a 'handle' on the Professor in
// reference variables of type Teacher and Administrator, because
// a Professor IS a Teacher (by virtue of implementing the
// Teacher interface, a Professor knows how to perform all of
// the services/behaviors that a Teacher is called to perform --
// i.e., the method signatures in the Teacher interface --
// and the same is true for a Professor as an Administrator.
Teacher t = p;
Administrator a = p;
// We can also "hand" a "handle" on this Professor to ANY method
// expecting to receive a Professor, OR a Teacher, OR an
// Administrator object reference as an argument.
------------------
author of:
Beginning Java Objects

[Jacquie Barker]

Originally posted by 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.
[snip]
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!

I often get asked by my students about how to break into a new technology like Java when one doesn't have experience on his/her resume. The best way is to try to get some experience in your current company, where you are already a known quantity; for example, my employer (and my client) allowed me to start from scratch with Java about five years ago because I had already proven myself with other languages and technologies. So, my first recommendation is to seek an on-the-job training opportunity within your current company, if you are already working.
If this simply isn't possible, how about developing a Java application on your own time and then taking it with you to demonstrate at your next interview?

------------------
author of:
Beginning Java Objects

[Noel Castillo]

Jacquie's 'Tried and True' Method for Learning Java Properly
....
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.

Jacquie,
Thank your for your "Tried" and "True" post. As a Java newbie, it will help me a lot in aligning my efforts towards the true north in Java. My observation from your tips is that you did not mention UML w/c helped me a lot in digesting the concepts presented in the Mughal&Rasmussen book. I would sometimes reverse-engineer some of their examples just to get a high-level view of the concepts.
Also, you did not mention design patterns. I understand these are important when trying to learn OO Design. My goal after SCJP is to understand patterns and implement a small project.
Lastly, I know that the options are wide open after going thru your 13 tips, however you only mentioned JDBC and not the other quite popular new technologies (in my perspective) like JSP, servelets, XML. How do these rank to you as things to aspire for in becoming more marketable in Java?
I wish you success with your book.
All the best,
Noel Castillo

[This message has been edited by Noel Castillo (edited January 04, 2001).]

[Dean Duffing]

Hi:
I would have to agree with most postings in this thread. My background has gone from mainframe,to client-server, to web. While I do find some value in the "object-based" experience I acquired doing PowerBuilder, a void is still there without the experience and OO research. I am interested in your book to help fill this void, but don't feel it is equal to actual experience... especially when it comes to the job market. There seems to be alot of people out there that can "talk the talk", but not "walk the walk". When starting with nothing though, the book should be the "foot in the door" towards getting that experience.
One good thing about Java seems to be its inherent OO Nature... it seems harder to code non-OO Java than code OO C/C++... just my initial opinion.
------------------

[Nehal Dave]

Hi there... What you have talked about is one of the basic problem which i still face.. That is how to structure a perticular application using OOP & specially Java where you have rich resources like inheritance & where u can extends any number of interfaces. I am a web programmer which started with making dynamic sites using ASP & rdbms. Then as i started to learn about the things i moved to Servlets. So to understand servlets i had to dig deep in java. To me when i started java.. all i knew was c,html,javascript,vbscript,asp & bit of VB.Let me tell you till date i have reffered the following books on java. The books are not in any order of refrence but just a list...
>java 2 complete ( SYBEX )
>Java 2 The Complete Reference (Patrick Naughton)
>Core Java vol 1 & 2 ( sun )
>java 2 unleased ( sams)
>Java servlet programming (O'Reilly)
>Java Network programming (O'Reilly)
>java beans Unleased ( sams)
>teach yourself java 2 in 21 days (sams)
>proffessional JSP ( wrox)
& few more........I surf java.sun.com site & its forum a lot & is also member of lots of sites & forums from where i find the most pratical ideas & opinions.No doubt after reading each book i have gained a lot ... but after each book i have felt that i have still not understood how to apply all this fundamental knowledge & the basics in solving a perticular problem. Ill like to give you an example.. I am trying to make a chat server application where the user can log in to chat from applet . Now as the need to parse each an every message at the server ( like simple message, a personal message & so on... ) i think its bettter to use classes for each type of messages... but i am finding it difficult to think how to go about with the message classes & design them as my base about classes ,inheritance is not strong enough. This is just one of my numerous problems which i have faced.. Still my quest for OOPS continous.. Would love to read the book if i win it ... or else will again spend some hard earned money to gain a bit or lots from this book..
Hope youre book doesnt dissapoint me...
Cheers
Nehal.

[eric moon]

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!

Well, it's funny because, unlike most people here, I read extremely deeply about OO and java before doing much programming at all. One of the hardest aspect of java for me when I started on the mac, was getting it to work at all. But the concepts behind objects were so exciting, I read the books like novels.
It's quite another issue to start using inheritance, polymorphism, abstract classes and interfaces to their best advantage in a large application. I think you have to get in there and make some mistakes in designing your objects to see where each of these tools is really useful.
[Great example of just what I was talking about, Peter!]

[This message has been edited by eric moon (edited January 04, 2001).]

[Satthish kumar]

Hello Jacquie,
I am a software professional who has been programming in java for the past 8 months. Regarding OOP concepts I do not have much problem but I get stuck up almost everytime, when there is a need to define classes and interfaces for a particular problem space - I have read somewhere that nouns in the context of problem space are to be made classes and the verbs their attributes - this is too abstract for me.
Could you please help me out with this - are there any specific set of guidelines to map the problem space with the solution space - how do I identify classes(their methods and attributes) that are really optimal for the application being designed.
------------------
sathish
[This message has been edited by Satthish kumar (edited January 04, 2001).]

[Kajol Shroff]

Hi Jacquie,
I am a begginer in JAVA and am not from Programming background...
I am reading Thinking in JAVA....and am confused betweenn Package nad IMPORT ....all i can understand is Package is folder where all JAVA files reside...
IMPORT is we are importing that folder along with one or all files within it.
Is it right..
I am not thorough with the OOPS concept....all i can understand bout oops concept is that whenever we create an object a new memory location is created...and we are using the copy of the class whose object is created..
I would like to know more about it......
Reply ......I want to know whether i am on the right track ...as i am planning for SCJP also....sooner..
Thanxs
Kajol

[Jacquie Barker]

Originally posted by Noel Castillo:
Jacquie,
Thank your for your "Tried" and "True" post. As a Java newbie, it will help me a lot in aligning my efforts towards the true north in Java. My observation from your tips is that you did not mention UML w/c helped me a lot in digesting the concepts presented in the Mughal&Rasmussen book. I would sometimes reverse-engineer some of their examples just to get a high-level view of the concepts.
Also, you did not mention design patterns. I understand these are important when trying to learn OO Design. My goal after SCJP is to understand patterns and implement a small project.
Lastly, I know that the options are wide open after going thru your 13 tips, however you only mentioned JDBC and not the other quite popular new technologies (in my perspective) like JSP, servelets, XML. How do these rank to you as things to aspire for in becoming more marketable in Java?
I wish you success with your book.
All the best,
Noel Castillo

[This message has been edited by Noel Castillo (edited January 04, 2001).]

Noel, thanks for your comments. Regarding the three items you mention:
UML: The first item in my list is to learn object modeling; UML is indeed the premier notation for doing so, but understanding the notions behind object modeling is even more important. My book goes into UML modeling notation in Part 2 (chapters 8 - 12).
Design Patterns: I don't see these as something that a beginner need focus on, but certainly once you've mastered the basics of OOA/D/P, learning about design patterns is useful. I introduce the notion of design patterns briefly in chapter 12.
Servlets, JSPs, etc: these all fall under the umbrella of J2EE (Java 2 Enterprise Edition), which I mention in the last step of my recommended learning process.
Best regards,
Jacquie
------------------
author of:
Beginning Java Objects

[Jacquie Barker]

Originally posted by Dean Duffing:
Hi:
I would have to agree with most postings in this thread. My background has gone from mainframe,to client-server, to web. While I do find some value in the "object-based" experience I acquired doing PowerBuilder, a void is still there without the experience and OO research. I am interested in your book to help fill this void, but don't feel it is equal to actual experience... especially when it comes to the job market. There seems to be alot of people out there that can "talk the talk", but not "walk the walk". When starting with nothing though, the book should be the "foot in the door" towards getting that experience.
One good thing about Java seems to be its inherent OO Nature... it seems harder to code non-OO Java than code OO C/C++... just my initial opinion.

Dean, I passionately agree with you! Tools like PowerBuilder, which give you a point and click way to build software without really seeing what is happening behind the scenes, do not require you to structure your overall application from the perspective of objects -- just the GUI portion. So, when folks attempt to learn Java by acquiring a drag and drop GUI building IDE, they are short-circuiting their learning experience significantly.
I also concur that Java is truer to the OO paradigm than C++ is; Appendix E of my book discusses the noteworthy differences as I see them between the two languages. Here's an excerpt from that Appendix (copyright 2000 Jacquie Barker):
'Breaking' the OO 'Rules' with C++
We talk at great length in Part 1 of the book about the advantages of encapsulation, information hiding, inheritance, and polymorphism in OO languages. Although C++ does indeed take advantage of these benefits, it provides a few 'back doors' that allow you to break the spirit of these features. Here are a few examples:
Friend functions: These functions reside outside the bounds of any class. They are given permission to access private attributes of one or more classes, thus breaking the spirit of encapsulation.
Virtual functions: In C++, we have to designate a method as virtual in order to get overriding to take place; this means that the developer of a C++ class must anticipate the future need to override a particular method in advance. With Java, the reverse is true: all methods are automatically 'overridable' unless they are flagged with the keyword final, which prohibits overriding.
This goes hand in glove with polymorphism: In Java, the ability for objects to perform the correct version of a method is automatic. With C++, if we fail to designate a method in a base class as virtual, then we may think we are overriding the method - we may indeed write method code in a subclass to 'mask' the parent's version - but at run time, the subclassed objects will only 'see', and hence be able to run, the parent's version of the method.

------------------
author of:
Beginning Java Objects

[Jacquie Barker]

Originally posted by Satthish kumar:
Hello Jacquie,
I am a software professional who has been programming in java for the past 8 months. Regarding OOP concepts I do not have much problem but I get stuck up almost everytime, when there is a need to define classes and interfaces for a particular problem space - I have read somewhere that nouns in the context of problem space are to be made classes and the verbs their attributes - this is too abstract for me.
Could you please help me out with this - are there any specific set of guidelines to map the problem space with the solution space - how do I identify classes(their methods and attributes) that are really optimal for the application being designed.

Alas, Satthish, this area is indeed "fuzzy", as I point out in my book. Beginners are encouraged to use the noun-phrase and verb-phrase analysis technique to determine what the classes and their behaviors should be -- I provide an example of doing so in Chapters 10 and 11. After a while, experienced object modelers develop a "knack" for identifying what the appropriate classes should be without using quite such a rote approach.
I'm afraid that I cannot do justice to this topic without including all of chapters 10 and 11 in this reply!
------------------
author of:
Beginning Java Objects

[Jacquie Barker]

Originally posted by Kajol Shroff:
Hi Jacquie,
I am a begginer in JAVA and am not from Programming background...
I am reading Thinking in JAVA....and am confused betweenn Package nad IMPORT ....all i can understand is Package is folder where all JAVA files reside...
IMPORT is we are importing that folder along with one or all files within it.
Is it right..
I am not thorough with the OOPS concept....all i can understand bout oops concept is that whenever we create an object a new memory location is created...and we are using the copy of the class whose object is created..
I would like to know more about it......
Reply ......I want to know whether i am on the right track ...as i am planning for SCJP also....sooner..
Thanxs
Kajol

I cover both of these topics in my book (packages in Chapter 13; object instatiation throughout Part 2). It would be prohibitive for me to try to include enough on the latter topic in this forum, but here's what I have to say about packages in Chapter 13 (copyright 2000 Jacquie Barker):
To appreciate import statements, we first must understand the notion of Java packages.
Because the Java language is so extensive, its various built-in classes are organized into logical groupings called packages. For example, we have:
o java.sql - the package that contains classes related to communicating with ODBC-compliant relational databases
o java.io - the package that contains classes related to file I/O
o java.util - the package that contains a number of utility classes, such as the Java collection classes that we'll be learning about in this chapter
o java.awt - one of the packages that contains classes related to GUI development
and so forth. Most built-in Java package names start with 'java', but there are some that start with other prefixes, like 'javax'; and, if we acquire Java classes from a third party, they typically come in a package that starts with 'com.companyname', e.g. 'com.xyzcorp.stuff'.
The package named 'java.lang' contains the absolute core of the Java language, and the classes contained within that package are always available to us whenever we write Java programs, so we needn't worry about importing java.lang; but if we wish to instantiate a Vector, one of Java's built in collection classes, as an attribute inside one of our classes, for example, then we must import the 'java.util' package, as the following example illustrates.
// Simple.java
// Our class needs to instantiate a Vector, and so we must import // the package that defines what a Vector is.

import java.util.*;

public class Simple {
public static void main(String[] args) {
Vector v = new Vector();
}
}
The asterisk ('*') at the end of the import statement above is a wildcard character; it informs the Java compiler that we wish to import all of the classes contained within the java.util package. As an alternative, we can import individual classes from a package:
// ImportExample.java
// We can import individual classes, to better document where
// each class that we are using originates.

import java.util.Enumeration;
import java.util.Vector;
import java.util.Date;
import java.io.PrintWriter;

// etc.
This of course requires more typing, but it serves as better documentation of where each class that we are using in our program originates.
If we were to attempt to reference the Vector class in one of our classes without this import statement, we'd get the following compilation error when compiling that particular class:
Class Vector not found.
This is because 'Vector' is not in the name space of our class: that is, it is not one of the names that the Java compiler recognizes in the context of that class. Generally speaking, the name space for a given class contains the following categories of names, among others:
o the name of the class itself
o the names of all of the attributes of the class
o the names of all of the methods of the class
o the names of any local variables declared within a method of a class
o the names of all classes belonging to the package that the class in question belongs to
o the names of all public classes in any other package that has been imported (we'll learn what constitutes a 'public' class later in this chapter)
o the names of all public features (attributes, methods) of any of the classes whose names are in the name space
o the names of all public classes in java.lang
and so forth.
We could work around the failure to import a package by fully qualifying the names of any classes, methods, etc. that we use from such a package; i.e. we can prefix the name of the class, method, etc. with the name of the package from which it originates, as shown in the next example:
// Simple2.java
// no import statement

public class Simple {
public static void main(String[] args) {
java.util.Vector v = new java.util.Vector();
}
}
This, of course, requires a lot more typing, and impairs the readability of the code.
Although most built in Java packages have names that consist of two terms separated by periods - e.g. java.awt - some built in Java packages have three - e.g. java.awt.event; and, as far as packages developed by third party organizations, there's really no limit to the number of terms that can be concatenated to form a package name. (The package name is a reflection of the directory hierarchy uses to store .class files, but understanding the details of how this works is somewhat complex, and is not necessary for the work that we're going to do in this book.) The important point to note about all of this is that the statement:
import nameA.nameB.*;
will only import classes in the nameA.nameB package; it will not import classes in the nameA.nameB.someothername package. That is, the wildcard pertains to class names only.
It's also important to note that importing a package is only effective for the particular .java file in which the import statement resides. If you have three different classes of your own that all need to manipulate Vectors, for example, then all three of their .java files must include an import statement for java.util.
Java also provides programmers with the ability to logically group their own classes into packages. For example, if we wanted to, we could invent a package such as 'com.objectstart.srs' to house our SRS application. Then, anyone else wishing to incorporate our SRS classes within an application that they were going to write could include the statement:
import com.objectstart.srs;
in their code, and even though our compiled class files are kept physically separated from their application's compiled class files, our classes would become logically combined with theirs, assuming a few other environmental details had been taken care of.
Going into a detailed discussion of how to create our own packages is beyond the scope of this book to address. But, as it turns out, if you do nothing in particular to take advantage of programmer-defined packages, then as long as all of the compiled .class files for your code resides in the same directory on your computer system, they are automatically considered to be in the same package, known as the default package. All of the code that we write for the SRS application will be housed in the same directory, and hence will fall within the same default package. This is what enables us to write code such as:
public class SRS {
public static void main(String[] args) {
Student s = new Student();
Professor p = new Professor();
// etc.
}
}
without using import statements: because Student, and Professor, and SRS, and all of the other classes comprising our SRS application are within the same default package.
The bottom line is that import statements as a building block of a .java source code file are optional; they are only needed if we are using packages that are neither found in package 'java.lang' nor in our own package. Throughout our work on the SRS, we will point out specifically which Java language packages we need to import for the various built-in classes that we'll be using.
------------------
author of:
Beginning Java Objects

[Kajol Shroff]

Thanks Jacquie.....
That was really goood.....
I wish i would have won the book, it really sounds great. YOu have done a real good job it seems....
The book is really expensive in India.....
Any ways.....
I would really be in touch with u....i mean i will be posting the queries and hope u too reply to them......
Thnks again
Kajol