Standard Design and Development Methodologies

[Novice]

I have a very general question that isn't really even specific to Java but
I'd appreciate your thoughts on this.

I'm a Java hobbyist. I've been writing code in Java for a while because I
like the language but haven't really used current standard design and
programming methodologies in a formal way to develop my code, sticking to
older methodologies that I learned long ago, like structured programming
and structured design. I'm thinking of trying to get paying work as a full-
time employee in a company using Java but I think I'm going to have to
acquire some new skills to be a credible candidate for a junior position in
systems development.

What are the standard design and development methodologies being used in
systems departments these days and, ideally, where can I find tutorials for
them, preferably free and online?

I expect that I will have to get at least a working knowledge of a bunch of
things, including OO Design, Patterns, and a dozen other things to have any
chance but, as a Chinese philosopher once said "a journey of a thousand
miles begins with a single step". I'd appreciate your help in building a
list of the things that someone like your employer would want met to have
before considering me for a junior position writing Java.

 

[Arne Vajhøj]

I have a very general question that isn't really even specific to Java but
I'd appreciate your thoughts on this.

I'm a Java hobbyist. I've been writing code in Java for a while because I
like the language but haven't really used current standard design and
programming methodologies in a formal way to develop my code, sticking to
older methodologies that I learned long ago, like structured programming
and structured design. I'm thinking of trying to get paying work as a full-
time employee in a company using Java but I think I'm going to have to
acquire some new skills to be a credible candidate for a junior position in
systems development.

What are the standard design and development methodologies being used in
systems departments these days and, ideally, where can I find tutorials for
them, preferably free and online?

I expect that I will have to get at least a working knowledge of a bunch of
things, including OO Design, Patterns, and a dozen other things to have any
chance but, as a Chinese philosopher once said "a journey of a thousand
miles begins with a single step". I'd appreciate your help in building a
list of the things that someone like your employer would want met to have
before considering me for a junior position writing Java.

OOA/OOD/OOP + design patters seems to be what to focus on.

GoF book
Code Complete
Applying UML and Patterns/Larman
Effective Java/Bloch

could be useful books to study.

Arne

 

[Arved Sandstrom]

I have a very general question that isn't really even specific to Java but
I'd appreciate your thoughts on this.

I'm a Java hobbyist. I've been writing code in Java for a while because I
like the language but haven't really used current standard design and
programming methodologies in a formal way to develop my code, sticking to
older methodologies that I learned long ago, like structured programming
and structured design. I'm thinking of trying to get paying work as a full-
time employee in a company using Java but I think I'm going to have to
acquire some new skills to be a credible candidate for a junior position in
systems development.

What are the standard design and development methodologies being used in
systems departments these days and, ideally, where can I find tutorials for
them, preferably free and online?

I expect that I will have to get at least a working knowledge of a bunch of
things, including OO Design, Patterns, and a dozen other things to have any
chance but, as a Chinese philosopher once said "a journey of a thousand
miles begins with a single step". I'd appreciate your help in building a
list of the things that someone like your employer would want met to have
before considering me for a junior position writing Java.

You could probably do worse than to read
http://en.wikipedia.org/wiki/Software_development_methodology. This is
of value primarily because it introduces a lot of common terminology.

Ultimately _every_ software development methodology (SDM) boils down to:

1. requirements analysis - understanding what the client needs you to do;
2. analysis & design - how you intend to meet those needs. See
http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design, since
we are talking Java, for general concepts;
3. implementation - actually write code;
4. testing - ensuring that your code, as written, satisfies the
requirements;
5. maintenance - nurturing the application over its lifespan.

How all the various approaches differ is how they break up and sequence
these activities. What really matters is that all these activities are
important.

It's probably best not to fixate on any given methodology. Just learn up
on the highlights of each, and keep in mind that all of them ultimately
boil down to requiring competence in the same skills. You'd be
interested initially in object-oriented analysis (OOA), object-oriented
design (OOD), and how to test your code (starting with unit testing and
perhaps functional testing).

Like Arne suggested, "Effective Java" by Bloch is a great book. So is
"Code Complete". IMO I wouldn't bother buying a copy of the GOF design
patterns book; borrow from a university library or locate a decent
website instead. Read some Martin Fowler
(http://martinfowler.com/intro.html). Don't get hung up on specific
methodologies (did I say that already?) - no project ever succeeded or
failed just because of what methodology a team used. Get some
familiarity with UML but don't go overboard with it.

My own specific suggestion - read
http://www.agilemodeling.com/artifacts/crcModel.htm (Scott Ambler is
also a good author). CRC is not just useful in agile.

If your understanding of persistence (databases) is not solid - in your
estimation, bone up on that.

If you don't have one already, select another OO programming language to
learn. You can make a lot more headway in learning all of the above if
you're not tied to one specific language. Just my opinion.

AHS
--
You should know the problem before you try to solve it.
Example: When my son was three he cried about a problem with his hand. I
kissed it several times and asked him about the problem. He peed on his
hand.
-- Radia Perlman, inventor of spanning tree protocol

 

[Lew]

You could probably do worse than to read
http://en.wikipedia.org/wiki/Software_development_methodology. This is
of value primarily because it introduces a lot of common terminology.

Ultimately _every_ software development methodology (SDM) boils down to:

1. requirements analysis - understanding what the client needs you to do;
2. analysis & design - how you intend to meet those needs. See
http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design, since
we are talking Java, for general concepts;
3. implementation - actually write code;
4. testing - ensuring that your code, as written, satisfies the
requirements;
5. maintenance - nurturing the application over its lifespan.

How all the various approaches differ is how they break up and sequence
these activities. What really matters is that all these activities are
important.

There's a comprehensive little pamphlet reviewing various software development methodologies called /Wicked Problems, Righteous Solutions/ by DeGrace and Stahl, 1990, that is as relevant today as when first published.

Its main conclusion, after a very neutral overview of the extant pet theories, is that successful methodologies rest on two key features: an individual who maintains the project architecture and structures in his/her own mind, and iteration.

As such an individual (as you should be, too), I have a toolbox of ways to look at a programming assignment - a kit of ontologies.

First and most fundamental skill - to look it up. Whatever the unfamiliar concept or skill, there is never an expert enough who's patient enough withtime enough and communication talent enough to explain it for you. You have to be able to do with fragments of advice (at best) and what you discover for yourself - through hard, hard study and very pragmatic experimentation. A former mentor of mine trained me that any IT person spending less than 20% over and above their normal work time to study and practice was doomed to fall behind.

'Struth.

As for ontologies, the most useful ones I know are event-driven programming, object-oriented programming, MVC (model-view-controller), layers (Law of Demeter), and "noun-and-verb" modeling. That last is my own term for usingthe language of the problem domain (its nouns and verbs) to define your program structures.

There's one style trick that induces better code: Keep it short. After about 500 lines of code and comment (yes, and comment) your class should feeltoo large, and after about 700-800 lines you should be castigating yourself.

The pressure to keep it short helps you think more clearly about structure.

And there's one mandatory, cross-methodology practice: Javadoc the shit out of your code. Document private and package-private methods and all static variables down to private. The extra asterisk at the start of the comment block hurts nothing.

Don't use specious comments, the kind that repeat what the code already says:

for (Foo foo : bunchOfFoos) // operate on each of the Foos

Pfeh! If a person doesn't know what a for-each loop is, such a comment will not rescue them.

Do liberally comment anything that makes a maintainer go, "Hmm."

// volatile: thread calling close() might not be same as called perform()
private volatile boolean isStopping;

This advice might not fit your idea of what constitutes a "methodology", but for Pete's sake, think. What does that "ology" suffix buy you but buzzword compliance? The real need is for a _method_, a process by which you canproduce effective, reliable, correct software on time to spec. In the endit's all about your personal commitment and skill.

 

[Lew]

There's a comprehensive little pamphlet reviewing various software development methodologies called /Wicked Problems, Righteous Solutions/ by DeGrace and Stahl, 1990, that is as relevant today as when first published.

http://www.google.com/search?q=ISBN 013590126X

 

[Derek K. Wodenhouse]

As for ontologies, the most useful ones I know are event-driven
programming, object-oriented programming, MVC (model-view-controller),
layers (Law of Demeter), and "noun-and-verb" modeling. That last is my
own term for using the language of the problem domain (its nouns and
verbs) to define your program structures.

That last is also known as "programming in Lisp".

 

[Lew]

That last is also known as "programming in Lisp".

Trivially, since the technique applies irrespective of platform.

It's also known as "programming in /X/", where /X/ is any programming language.

Thank you for your useful observation.

 

[Derek K. Wodenhouse]

Trivially, since the technique applies irrespective of platform.

It's also known as "programming in /X/", where /X/ is any programming language.

Not nearly as strongly. Lisps let you reify nearly any program
abstraction, and build a bridge from the solution domain to the problem
domain, expressing most of the business logic in problem domain terms. A
common program design in another language consists of a problem domain
focused library, plus an application layer atop that that contains the
business logic but is still largely written in solution domain terms,
with a sprinkling of problem domain nouns and verbs. A common program
design in Lisp consists of a domain-specific language for the problem
domain, in Lisp, and an application in that language with a sprinkling
of generic-Lisp nouns and verbs (mostly lists and data structure
traversals, and/or numbers and arithmetic -- much of which might be
regarded as present also in the problem domain).

 

[Robert Klemme]

Not nearly as strongly. Lisps let you reify nearly any program
abstraction, and build a bridge from the solution domain to the problem
domain, expressing most of the business logic in problem domain terms. A
common program design in another language consists of a problem domain
focused library, plus an application layer atop that that contains the
business logic but is still largely written in solution domain terms,
with a sprinkling of problem domain nouns and verbs. A common program
design in Lisp consists of a domain-specific language for the problem
domain, in Lisp, and an application in that language with a sprinkling
of generic-Lisp nouns and verbs (mostly lists and data structure
traversals, and/or numbers and arithmetic -- much of which might be
regarded as present also in the problem domain).

It's also pretty easy to create DSL's in - say Ruby - so Lisp is not
unique with respect to that. One can go even further and call any Java
library (in fact, _any_ library) a domain specific language. The
difference with Lisp is that it's basic syntax is trivial (sexpr) and it
has Macros which can make special forms look like regular function calls
by which means you can do things in this language which you cannot (or
not as easily) in others.

Kind regards

robert

 

[Arved Sandstrom]

There's a comprehensive little pamphlet reviewing various software development methodologies called /Wicked Problems, Righteous Solutions/ by DeGrace and Stahl, 1990, that is as relevant today as when first published.

Its main conclusion, after a very neutral overview of the extant pet theories, is that successful methodologies rest on two key features: an individual who maintains the project architecture and structures in his/her own mind, and iteration.

[ SNIP good stuff ]

I hesitated to start talking about methods/"methodologies" in my first
post, since it was getting lengthy. Or as you've phrased it, key
features of successful methodologies. However I would agree that an
iterative approach is most suitable for most projects.

In that regard I'd caution the OP that waterfall is still popular and
common, and that a lot of shops advertise that they are iterative+agile
when in fact they are doing more, and smaller, waterfall projects. It's
not quite the same thing.

On the subject of "an individual who maintains the project architecture
and structures in his/her own mind", this often won't correspond to
titles or labels (like "architect"). Another way of looking at it is
that you should have an individual who is the "coordinator", who can
guide and plan the work of the individual domain experts - the developers.

AHS
--
You should know the problem before you try to solve it.
Example: When my son was three he cried about a problem with his hand. I
kissed it several times and asked him about the problem. He peed on his
hand.
-- Radia Perlman, inventor of spanning tree protocol

 

[spk]

Why do you feel it is limited to Lisp? It seems to me to be generally
useful, regardless of the programming language. It is certainly useful
for design of Java programs.

Patricia

From: thoolen <[email protected]>
Newsgroups: comp.lang.java.programmer
Subject: Re: toward null-safe cookie cutter Comparators
Followup-To: comp.os.os2.advocacy
Date: Fri, 18 Nov 2011 15:21:25 -0500
Organization: thingamajig
Message-ID: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
<14715296.1119.1321552560149.JavaMail.geo-discussion-forums@prnv30>
<[email protected]>
<[email protected]>
<23591489.9.1321566539494.JavaMail.geo-discussion-forums@prap37>
<[email protected]>
NNTP-Posting-Host: boE97fIOqjAfikXEhaRruQ.user.speranza.aioe.org

From: kensi <[email protected]>
Newsgroups: comp.lang.java.programmer
Subject: Re: toward null-safe cookie cutter Comparators
Date: Thu, 17 Nov 2011 21:21:34 -0500
Organization: SICN
Message-ID: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]> <[email protected]>
<[email protected]>
NNTP-Posting-Host: boE97fIOqjAfikXEhaRruQ.user.speranza.aioe.org

From: "Derek K. Wodenhouse" <[email protected]>
Newsgroups: comp.lang.java.programmer
Subject: Re: Standard Design and Development Methodologies
Date: Sat, 19 Nov 2011 23:49:09 -0500
Organization: Occupy rec.arts.tv
Message-ID: <[email protected]>
References: <[email protected]>
<[email protected]>
<4908121.2133.1321762391730.JavaMail.geo-discussion-forums@prou19>
NNTP-Posting-Host: boE97fIOqjAfikXEhaRruQ.user.speranza.aioe.org


....take note of the supportive lead in by <[email protected]>.
"Lew" quit posting from an ISP when that service dropped
Usenet. Around that same time Derbyshire switched back to
bell.ca., as his ISP of choice, despite his complaints about the service.
The coincidence warrants closer examination as it is classic
Derbyshire behavior to run "Spy V Spy" type roles in newsgroups
where the idiot believes the topic is known to him.

Then there is this;

Date: Sat, 26 Jul 2008 09:50:50 -0400
From: Lew <com.lewscanon@lew>
Organization: the real lewscanon.com
User-Agent: Thunderbird 2.0.0.14 (X11/20080505)
Newsgroups: comp.lang.java.programmer
Subject: Re: Missing Lew's posts but not the impostor?
References: <[email protected]>
<[email protected]>
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 76.114.182.213



....as Daniel Pitts is now reading CJLP perhaps a comment is in order
from that source. IS the Lew leading the Derbyshire sock for real, or an
imposter?
?
?
SPACE MADE FOR CONTRIBUTIONS

__________________________________________________________

Of corse as per usual the OP's topic is yet another Debyshire troll.
Anyone require gill repairs?


From: Novice <[email protected]>
Newsgroups: comp.lang.java.programmer
Subject: Standard Design and Development Methodologies
Date: Sat, 19 Nov 2011 19:42:07 +0000 (UTC)
Organization: Your Company
Message-ID: <[email protected]>
NNTP-Posting-Host: 3xQmNYlLzPWlOroV9OKfZA.user.speranza.aioe.org

From: Just Plain Nasty <[email protected]>
Newsgroups: rec.arts.tv
Subject: Re: William Shatner Warns Of The Dangers Of Turkey Fryers
Date: Fri, 18 Nov 2011 19:56:20 +0000 (UTC)
Organization: Your Company
Message-ID: <[email protected]>
References: <[email protected]> <[email protected]>
NNTP-Posting-Host: 3xQmNYlLzPWlOroV9OKfZA.user.speranza.aioe.org

 

[Lew]

Not nearly as strongly. Lisps let you reify nearly any program
abstraction, and build a bridge from the solution domain to the problem
domain, expressing most of the business logic in problem domain terms. A

So does Java, C++, BASIC, Fortran, Ada, F#, Javascript, Forth, ...

common program design in another language consists of a problem domain
focused library, plus an application layer atop that that contains the
business logic but is still largely written in solution domain terms,
Hahaha.

with a sprinkling of problem domain nouns and verbs. A common program
design in Lisp consists of a domain-specific language for the problem
domain, in Lisp, and an application in that language with a sprinkling
of generic-Lisp nouns and verbs (mostly lists and data structure
traversals, and/or numbers and arithmetic -- much of which might be
regarded as present also in the problem domain).

Language War! Language War!

I'm breaking out my popcorn.

Just so you know, you Lisp fanboys love to cause fights, but where's the money in programming, hm?

Go have fun in your playpen.

 

[Lew]

Plonk, spk.

 

[Novice]

OOA/OOD/OOP + design patters seems to be what to focus on.

GoF book
Code Complete
Applying UML and Patterns/Larman
Effective Java/Bloch

could be useful books to study.

Thanks Arne. I already have Effective Java, although I haven't made the
time to go through it yet. I'll have to track down the others and make time
to work my way through them - and practice what they suggest as best I can!

 

[Novice]

You could probably do worse than to read
http://en.wikipedia.org/wiki/Software_development_methodology. This is
of value primarily because it introduces a lot of common terminology.

Ultimately _every_ software development methodology (SDM) boils down
to:

1. requirements analysis - understanding what the client needs you to
do; 2. analysis & design - how you intend to meet those needs. See
http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design,
since we are talking Java, for general concepts;
3. implementation - actually write code;
4. testing - ensuring that your code, as written, satisfies the
requirements;
5. maintenance - nurturing the application over its lifespan.

How all the various approaches differ is how they break up and
sequence these activities. What really matters is that all these
activities are important.

It's probably best not to fixate on any given methodology. Just learn
up on the highlights of each, and keep in mind that all of them
ultimately boil down to requiring competence in the same skills. You'd
be interested initially in object-oriented analysis (OOA),
object-oriented design (OOD), and how to test your code (starting with
unit testing and perhaps functional testing).

Like Arne suggested, "Effective Java" by Bloch is a great book. So is
"Code Complete". IMO I wouldn't bother buying a copy of the GOF design
patterns book; borrow from a university library or locate a decent
website instead. Read some Martin Fowler
(http://martinfowler.com/intro.html). Don't get hung up on specific
methodologies (did I say that already?) - no project ever succeeded or
failed just because of what methodology a team used. Get some
familiarity with UML but don't go overboard with it.

My own specific suggestion - read
http://www.agilemodeling.com/artifacts/crcModel.htm (Scott Ambler is
also a good author). CRC is not just useful in agile.

If your understanding of persistence (databases) is not solid - in
your estimation, bone up on that.

If you don't have one already, select another OO programming language
to learn. You can make a lot more headway in learning all of the above
if you're not tied to one specific language. Just my opinion.

Thanks, Arved. Lots of great suggestions, tempered with common sense like
not getting fixated on any specific methodology.

A couple of followup questions if I may.
1. I'm pretty solid on relational databases, although not OO databases.
I'm not clear on the actual purpose of "persistence layers" though. I
started to look at Hibernate a few years back but got sidetracked and
didn't get very far. Can you possibly summarize in a few sentences:
a. what a persistence layer does
b. how an OO database differs from a relational database?

I'm also intrigued to hear you suggest looking at another OO language as
a way to learn more about OO in general. Interesting idea. Like learning
French to help improve your Spanish, to use a non-computer metaphor.I did
dabble in C++ briefly after I had the basics of C but then discovered
that C++ was not easily portable across platforms. That's when I was sold
(brainwashed?) into looking at Java ;-)

What other OO language would be best to consider? C++? Smalltalk? .NET?
(Hmm, I'm not sure if .NET is even considered OO....)

 

[Novice]

There's a comprehensive little pamphlet reviewing various software
development methodologies called /Wicked Problems, Righteous
Solutions/ by DeGrace and Stahl, 1990, that is as relevant today as
when first published.

Its main conclusion, after a very neutral overview of the extant pet
theories, is that successful methodologies rest on two key features:
an individual who maintains the project architecture and structures in
his/her own mind, and iteration.

As such an individual (as you should be, too), I have a toolbox of
ways to look at a programming assignment - a kit of ontologies.

First and most fundamental skill - to look it up. Whatever the
unfamiliar concept or skill, there is never an expert enough who's
patient enough with time enough and communication talent enough to
explain it for you. You have to be able to do with fragments of
advice (at best) and what you discover for yourself - through hard,
hard study and very pragmatic experimentation. A former mentor of
mine trained me that any IT person spending less than 20% over and
above their normal work time to study and practice was doomed to fall
behind.

'Struth.

As for ontologies, the most useful ones I know are event-driven
programming, object-oriented programming, MVC (model-view-controller),
layers (Law of Demeter), and "noun-and-verb" modeling. That last is
my own term for using the language of the problem domain (its nouns
and verbs) to define your program structures.

There's one style trick that induces better code: Keep it short.
After about 500 lines of code and comment (yes, and comment) your
class should feel too large, and after about 700-800 lines you should
be castigating yourself.

The pressure to keep it short helps you think more clearly about
structure.

And there's one mandatory, cross-methodology practice: Javadoc the
shit out of your code. Document private and package-private methods
and all static variables down to private. The extra asterisk at the
start of the comment block hurts nothing.

Don't use specious comments, the kind that repeat what the code
already says:

for (Foo foo : bunchOfFoos) // operate on each of the Foos

Pfeh! If a person doesn't know what a for-each loop is, such a
comment will not rescue them.

Do liberally comment anything that makes a maintainer go, "Hmm."

// volatile: thread calling close() might not be same as called
perform() private volatile boolean isStopping;

This advice might not fit your idea of what constitutes a
"methodology", but for Pete's sake, think. What does that "ology"
suffix buy you but buzzword compliance? The real need is for a
_method_, a process by which you can produce effective, reliable,
correct software on time to spec. In the end it's all about your
personal commitment and skill.

Thanks Lew, lots of sound advice in your remarks! I totally agree with
your distinction between a methodology vs. a method; my original question
was not ideally worded.

I'm trying to figure out what kinds of things an interviewer from the
technical side of the shop - as opposed to HR - is going to expect. I'm
not sure how open-minded they will be to someone who wants a job but
doesn't seem to have much prior contact with specific methodologies so I
was hoping to get a list of the key methodologies. But that was probably
misguided since I expect they will be relatively open-minded as long as
you have the main SKILLS of each stage of the development process, even
if they don't use whatever formal methodology you might know. So, even if
you've never seen a UML diagram before but have done some other kind of
diagram that conveys the same basic information, they will accept you
anyway and recognize that you will be easily able to start doing UML
instead of whatever you have been doing. Or is all that wishful thinking?

 

[Arne Vajhøj]

I'm also intrigued to hear you suggest looking at another OO language as
a way to learn more about OO in general. Interesting idea. Like learning
French to help improve your Spanish, to use a non-computer metaphor.I did
dabble in C++ briefly after I had the basics of C but then discovered
that C++ was not easily portable across platforms. That's when I was sold
(brainwashed?) into looking at Java ;-)

What other OO language would be best to consider? C++? Smalltalk? .NET?
(Hmm, I'm not sure if .NET is even considered OO....)

..NET is OO.

But I think C# is too close to Java to provide maximum alternative
perspective.

C++, Ruby may provide more value for this purpose.

Arne

 

[markspace]

1. I'm pretty solid on relational databases, although not OO databases.
I'm not clear on the actual purpose of "persistence layers" though. I
started to look at Hibernate a few years back but got sidetracked and
didn't get very far. Can you possibly summarize in a few sentences:
a. what a persistence layer does

Persistence just saves stuff to long term storage. How it does that is
another matter. When talking databases, a persistence layer interfaces
objects to a database (usually a database connection of some sort). It
takes care of a lot of the busy work of reading a database entity into
objects, and writing objects out as database entities.

You can do this manually, but it's really busy work. Do it once to see
how it works, then forget it and go for JPA.

b. how an OO database differs from a relational database?

I don't know, other than I don't think OO databases are popular or
practical. Everyone I know uses the relational variety, or flat files.

 

[Lew]

I'm trying to figure out what kinds of things an interviewer from the
technical side of the shop - as opposed to HR - is going to expect. I'm
not sure how open-minded they will be to someone who wants a job but
doesn't seem to have much prior contact with specific methodologies so I
was hoping to get a list of the key methodologies.

You could probably do worse than to read
http://en.wikipedia.org/wiki/Software_development_methodology.
This is of value primarily because it introduces a lot of common terminology.

?

 

[Lew]

A couple of followup questions if I may.
1. I'm pretty solid on relational databases, although not OO databases.
I'm not clear on the actual purpose of "persistence layers" though. I
started to look at Hibernate a few years back but got sidetracked and
didn't get very far. Can you possibly summarize in a few sentences:
a. what a persistence layer does
b. how an OO database differs from a relational database?

This is a major topic. I'll hit some headlines /infra/.

...
What other OO language would be best to consider? C++? Smalltalk? .NET?
(Hmm, I'm not sure if .NET is even considered OO....)

..Net isn't a language, it's a platform.

You might read Grady Booch or others on what object-oriented blahblah is generally.

Don't get too bogged down there - skimming the TOC and a few paragraphs in each chapter in the bookstore will get you started.

Object-oriented is just a way of looking at things. Relational algebra (RDBMSes) is another, orthogonal way.

Object-oriented, as well explained by Booch and others, entails adherence to certain principles, the number and name of which vary a bit between authors. Basically it's encapsulation and inheritance, component and layered architecture, and a clean, well laid-out structure.

Encapsulation involves abstraction of the interaction between tightly focused types that hide their mechanics. You program to the interface <generically at times>.

Inheritance is a spice to use lightly.

O-O is at its best a synonym for really good modeling. Each type should befairly simple - easier to do if you concentrate on its interface and not the messy innards.

Unit tests are invaluable.

Good languages are C#, C++, Smalltalk (the progenitor).

Other languages to know are Lisp, Forth, Javascript, Python, Go, Prolog, C,bash.

Object-oriented databases are a dead end.

IMHO.

But SQL is really only for those who understand relations.

Relations are not objects.

And vice versa.

But they map to each other, with a lot of transformational infrastructure. The key is that the object and data ontologies are not the same.

I've done a lot of that - mapping objects to relations, or "object-to-relational mapping" (ORM).

The best way to do ORM in Java is JPA, the Java Persistence API. There arethree standard, free products that give you that specification: EclipseLink, Apache OpenJPA, and Hibernate. Hibernate comes with a weight of documentation and culture from its pre-JPA days. Don't get sucked into that. Stick firmly with JPA.

OK, "best" is relative. You might be fine with just the Collections API, which you should master anyway. But to talk to databases like Derby or PostgreSQL, JPA is wonderful. As long as you don't think of it as "talking to databases".

JPA gives you an object-oriented view of persistent information, hiding therelational sensibility from the program. It is about control of sessions,that is, 'EntityManager' lifetimes, and how durable to make object properties, not about data. The framework handles a subset of data manipulations opaquely to support that mapping.

Well, translucently, but learn the basics first.