File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Bunkhouse Porch and the fly likes HFOOAD my first impression: Why is J2EE not covered? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Books » Bunkhouse Porch
Bookmark "HFOOAD my first impression: Why is J2EE not covered?" Watch "HFOOAD my first impression: Why is J2EE not covered?" New topic
Author

HFOOAD my first impression: Why is J2EE not covered?

Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Hi Bert and anyone else,

I got my copy today in Germany from Amazon.com after I placed the original order in August 2006.

My first impression after skimming through the book is that it looks handy. What I miss and what hit my brain first is that you do not cover J2EE in any way. I expect to see at least talk about J2EE design patterns and other stuff to be taken into account when doing OOAD in a real world enterprise application in the year 2007.

This is also something which was promised by Head First EJB but was never delivered, neither in Head First EJB nor in Head First Design Patterns. Nor in Head First OOAD.

Is there a reason why you are so shy for covering up with J2EE ?

Regards,
Darya


SCJP, SCJD, SCWCD, SCBCD
Bert Bates
author
Sheriff

Joined: Oct 14, 2002
Posts: 8764
    
    5
Hi Darya,

The idea of HF Java EE Design Patterns (or maybe, more generically "Enterprise patterns"), is something that is on the list. I think that if we decide to cover that topic, it deserves an entire book, and not just section of another book. HFOOAD was never really intended to be a patterns-related book.

hth,

Bert


Spot false dilemmas now, ask me how!
(If you're not on the edge, you're taking up too much room.)
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Hi Bert,

the problem I have with HFDP and HFOOAD is that both talk like they were in a nut shell. In reality this however is never the case and in 2007 you are always embedded in an enterprise environment.

In fact I have no problem at all when you explain things in a nut shell. But I have a problem when there is not a chapter or two that shows how things are in a real environment.

In HFEJB you also intended to provide such a chapter but you never came up with one. Neither in the book nor elsewhere. Didn't you promised somewhere to provide the missing J2EE design pattern chapter after it was mentioned in HFEJB but actually didn't appear :roll: ?

If you want to fill the gap between theory and real world then I think there is no way getting around it other than to cover J2EE. I stick with J2EE because all Head First books so far were Java based and that is why we are here at JavaRanch.

Regards,
Darya
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 39547
    
  27
Darya, why do you think that OOAD would be different if it is implemented using J2EE? OOAD principles apply in general, while J2EE is about particular APIs that can be used to implement an OOD once it is done.
[ December 13, 2006: Message edited by: Ulf Dittmer ]

Ping & DNS - updated with new look and Ping home screen widget
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Darya, I don't share your concern.

In my view, the J2EE patterns really are "just" special applications of the more general design patterns. If you know the GoF design patterns, nothing in the J2EE should be a big surprise to you. And the GoF patterns are general enough that they can easily be applied to non-J2EE environments, for example when you are working with Spring, Struts, whatever...

I'm a professional Java developer for nearly a decade now, currently working on a 1 million lines of code system, and only had marginal contact with EJBs. In fact I think that seeing EJBs as kind of mandatory for "serious" Java development is one of the biggest problems in the Java community. I'm relieved to see that HF doesn't strengthen this believe.

Having said that, I also don't believe that the HF series was meant to be the only books you ever read.

For a good book on how to apply OO principles and patterns in "real world projects", take a look at Robert C. Martin's works, especially "Agile Software Development - Principles, Patterns and Practices".


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Originally posted by Ulf Dittmer:
Darya, why do you think that OOAD would be different if it is implemented using J2EE? OOAD principles apply in general, while J2EE is about particular APIs that can be used to implement an OOD once it is done.


I know that OOAD has nothing to do with J2EE. But in a real world project you need to use your OOAD skills in an J2EE environment. Here is where the D in OOAD comes into play.

Regards,
Darya
[ December 13, 2006: Message edited by: Darya Akbari ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Darya, can you give a concrete example of what kind of advice you'd need, what kind of problems you are encountering when applying OOAD to J2EE?
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2906
Originally posted by Ilja Preuss:
Having said that, I also don't believe that the HF series was meant to be the only books you ever read.


And yet none of them have a Bibliography (Annotated or otherwise) or a "Learn More" section.

HFEJB: Patterns and Performance, the Lost (last) Chapter


"Don't succumb to the false authority of a tool or model. There is no substitute for thinking."
Andy Hunt, Pragmatic Thinking & Learning: Refactor Your Wetware p.41
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Originally posted by Ilja Preuss:
Darya, can you give a concrete example of what kind of advice you'd need, what kind of problems you are encountering when applying OOAD to J2EE?


Hi Ilja,

I don't need any advice. My question was only why the HF team did not include J2EE.

Originally posted by Ilja Preuss:
If you know the GoF design patterns, nothing in the J2EE should be a big surprise to you.
...
I'm relieved to see that HF doesn't strengthen this believe.


You are right when you say that if someone knows the GoF design patterns they should also be OK with the J2EE design patterns.

Nevertheless this must not be valid for everyone. If that is all that clear then why do we have J2EE design patterns .

And don't be too much relieved (or misled ) about Head First's stand on J2EE. Their J2EE HF books are bestsellers .

Regards,
Darya
[ December 27, 2006: Message edited by: Darya Akbari ]
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855


Thanks for the wonderful link Peer .

Bert, do you remember Peer's thread ?

Regards,
Darya
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Originally posted by Bert Bates:
... HFOOAD was never really intended to be a patterns-related book.


Hi Bert,

Are you joking ? Isn't D in OOAD exactly where design patterns belong?

Regards,
Darya
[ December 13, 2006: Message edited by: Darya Akbari ]
Bert Bates
author
Sheriff

Joined: Oct 14, 2002
Posts: 8764
    
    5


Yes indeed, if we'd decided to add design patterns to the book then they would have fallen nicely under the 'd' section

And, as far as that other link goes - we said way back then that it's on our list, and, in fact it is! As far as getting us to re-prioritize our list, we are open to bribes

Now, as far as a "what to read next" list is concerned, that's an intersting question. We've been thinking about this a bit lately. On the one hand we've tried to make it clear that we don't consider our books any kind of total solution. In fact we try to stress that we believe that a book should be well focused, and NOT try to be everything to everyone. That said, i agree that it would be nice to add a "what to read next" list, but the fact that we haven't, doesn't in any way indicate that we think our books are the last word! Quite the opposite is true, in general we like to think our books might be a decent intro.

hth,

Bert
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2906
Originally posted by Bert Bates:
And, as far as that other link goes - we said way back then that it's on our list, and, in fact it is! As far as getting us to re-prioritize our list, we are open to bribes


Ahem - I provided the link to show that I brought up the point about the "what to read next" list over a year ago. Personally I think that you are wasting space on the list by keeping that "Lost Chapter" on it but the list is probably endless (while our life spans are not).

I just imagined that the (co)authors would each have their own personal favorite books and probably already have a quick supporting sentence or blurb for each in the recesses of their brain that they might be willing to share with the rest of the world - but considering the deadline pressures on this one, small stuff like that probably would have fallen ofF the table pretty quickly.

Then of course there is the potential "culture shock" that a neophyte Head First reader may experience when transitioning to some of the more "academic" texts.

Originally posted by Darya Akbari:
Isn't D in OOAD exactly where design patterns belong?


In a way OO-thinking and Design-Pattern thinking share some common core elements. This is the reason why Allan Shalloway/James Trott discuss them together in Design Patterns Explained: A New Perspective on Object-Oriented Design - they really discuss the OO design process in general and more as a by-product show how some common design patterns emerge from good design (no shoe-horning of problems into pre-baked solutions). In the end they cover fewer patterns than HF Design Patterns; despite it's title Design Patterns Explained is primarily a OOD book. On the other hand Dr. David West (not to be confused with HF OOAD co-author David West) in Object Thinking goes so far to state that Alexander's design patterns have been misunderstood by the software world - beyond which there is very little stated about "design patterns" in connection with "Object-Oriented Thinking" (& Design).

In the end Design Patterns are simply a by-product of good OO design (applied repeatedly) - not cookie-cutter approaches to solving every problem under the sun. So unless your goal is to present Design Patterns as a result of good OO practices which can be re-invested, you may be better off by remaining silent on them as a neophyte should be learning the more general Principles of OOD and not get the impression that OOD is nothing but a bunch of pre-digested, catalogued patterns. OO neophytes are notoriously overzealous with Design Patterns once they learn about them; they need to heed Scott Ambler's advice: Apply Patterns Gently.


Originally posted by Darya Akbari:
Is there a reason why you are so shy for covering up with J2EE ?


I have to admit I was a little bit surprised by this question. Why would you think that it would be covered? J2EE is a framework, based on a distributed component architecture, for implementing enterprise scale applications. J2EE is composed of classes and objects itself but has been repeatedly accused of demolishing Object-Oriented Domain Models. Java EE's complexity has contributed to reports like JEE5: The Beginning of the End of Java EE - complexity is not something you would want to burden an OO neophyte with, a Book on OOD needs to show that OOD manages complexity, not needlessly create it.

When it comes to enterprise application design patterns I personally think time is better spent with Martin Fowler's more general Patterns of Enterprise Application Architecture than with Core J2EE Patterns: Best Practices and Design Strategies 2e. Many J2EE Patterns are ways to address J2EE�s idiosyncrasies rather than solutions to general challenges arising in software development. Sure, when working with J2EE I'd prefer to have Core J2EE Patterns available to me but not to the point of excluding other more general pattern books; also Core J2EE Patterns should really come with a copy of J2EE AntiPatterns attached to it.
[ December 13, 2006: Message edited by: Peer Reynders ]
Jeroen T Wenting
Ranch Hand

Joined: Apr 21, 2006
Posts: 1847
I don't remember who it was but one very important Java person said a few years ago (and it's still valid today) that "J2EE patterns" are in fact antipatterns used to mask the deficiencies in the design of J2EE itself.

He may have been a bit harsh, but the very term "J2EE pattern" as something separate from normal SE practice makes little sense.
If you need a specific "new" pattern just for using one specific API or library else that library is useless to you, a pattern that is useless in any other context, there's something wrong with that library or API (at least for your application) or there's something wrong with your understanding of how that library should be used.

Most VALID "J2EE patterns" are composites of other patterns, and you should be able to find your way by reading HF Design patterns, HF OOAD, and a J2EE book. Maybe add a dedicated J2EE pattern catalogue if you insist, but if you do also add a book about antipatterns.


42
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Originally posted by Peer Reynders:
... complexity is not something you would want to burden an OO neophyte with, a Book on OOD needs to show that OOD manages complexity, not needlessly create it.


I thought more of a last chapter in HFOOAD similar to the lost chapter in HFEJB .

Regards,
Darya
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Originally posted by Jeroen T Wenting:
... and you should be able to find your way by reading HF Design patterns, HF OOAD, and a J2EE book. Maybe add a dedicated J2EE pattern catalogue if you insist, but if you do also add a book about antipatterns.


Actually, this is how I use J2EE. Starting with the global GoF patterns and then applying some of these patterns to the chosen technology which in most cases is J2EE.

Now, HFOOAD would have done a great job if it had shown, in its OOD section, how to use these J2EE patterns.

I definitely don't share you thoughts of grabbing all these books and find my own way to J2EE. Of course, one should have an understanding from all, but not in any detail. And here is where a good book like HFOOAD steps in and glues it all together. I want to learn the best practices on how to glue it all together. I don't want to learn on how NOT doing things. Antipatterns are more for the experienced user, so these should come later, if at all. Much more important are the good patterns .

HFOOAD is exactly the place where it belongs, because it's here, right between OOA and OOD, where you must make your decision for the technology.

Ignoring this step and leaving people wandering in uncertainty is one reason why lot of teams are in trouble and projects become unsuccessful .

Regards,
Darya
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Darya Akbari:
I don't want to learn on how NOT doing things. Antipatterns are more for the experienced user, so these should come later, if at all. Much more important are the good patterns .


But Antipatterns aren't just about what not to do. They are also about what to *do* instead.

And I think they are just great for beginners, because they are likely to recognize the patterns. "I *am* doing that. Oh, right, that's exactly the pain I feel. Oh, that's the way to do it better, I have to try it."
Gary Pollice
Greenhorn

Joined: Jan 04, 2007
Posts: 2
Originally posted by Darya Akbari:


Now, HFOOAD would have done a great job if it had shown, in its OOD section, how to use these J2EE patterns.

...

I definitely don't share you thoughts of grabbing all these books and find my own way to J2EE. Of course, one should have an understanding from all, but not in any detail. And here is where a good book like HFOOAD steps in and glues it all together. I want to learn the best practices on how to glue it all together. I don't want to learn on how NOT doing things.

...

HFOOAD is exactly the place where it belongs, because it's here, right between OOA and OOD, where you must make your decision for the technology.

Ignoring this step and leaving people wandering in uncertainty is one reason why lot of teams are in trouble and projects become unsuccessful .

Regards,
Darya


There are a lot of things that can be put into an OOAD book. However, the purpose of the HFOOAD is to get people started with a small set of good practices. None of the Head First books are too broad. They all focus on a few things and get you started thinking properly about the topics by giving you things to do and succeed at. I plan on teaching with HFOOAD next year in my OOAD course, but I will also use the HFDP as the second text -- and I'll even be handing out additional readings for added depth on specific topics. Every time I've tried to use a book that covers it all, I'm disappointed in the fact that it just doesn't work. If, after you read HFOOAD, you get the main ideas of OOAD and are able to then go deeper into different practices, we've done our job.

Clearly we could have gone into coding style, user stories, analysis classes and stereotypes, more UML, databases, patterns, and so on. The book's 600 pages now. That seems to be a pretty good start.
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Welcome to JavaRanch Gary,

Originally posted by Gary Pollice:
... I plan on teaching with HFOOAD next year in my OOAD course, but I will also use the HFDP as the second text -- and I'll even be handing out additional readings for added depth on specific topics.
...


I hope you share your additional reading stuff also here and that one specific topic will be J2EE .

Regards,
Darya
Bert Bates
author
Sheriff

Joined: Oct 14, 2002
Posts: 8764
    
    5
Welcome to the ranch Gary!

But be careful, this place can become addictive

Bert
Gary Pollice
Greenhorn

Joined: Jan 04, 2007
Posts: 2
Originally posted by Darya Akbari:
Welcome to JavaRanch Gary,



I hope you share your additional reading stuff also here and that one specific topic will be J2EE .

Regards,
Darya


Thanks Darya and Bert. The reading that I assign for my classes can be found at in the documents section of the project SourceForge project. It's at: CS4233 Course Pages. I really don't get into J2EE in this class. I have seven weeks to handle the basics of OOAD and J2EE is really an optional / advanced topic.

--Gary
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
Originally posted by Bert Bates:
Welcome to the ranch Gary!

But be careful, this place can become addictive

Bert


I hope so for Gary .

Regards,
Darya
B.Sathish
Ranch Hand

Joined: Aug 18, 2005
Posts: 372
I have already read the HFDP book. Is it necessary to read the HFOOAD book? Does it cover something new or the same set of design principles explained in HFDP?
Darya Akbari
Ranch Hand

Joined: Aug 21, 2004
Posts: 1855
HFOOAD has some references to HFDP. So that shows that HFOOAD is on top of HFDP if you like.

Design patterns are of value when you are in the second part of the OOAD process, the Design part.

Bert Bates
author
Sheriff

Joined: Oct 14, 2002
Posts: 8764
    
    5
Without knowing your background, it's impossible to say how much benefit you'd get from HFOO after reading HFDP. Certainly the sets of topics are related, but the books really do stand alone. Ideally the sequence would be HF Java, then HFOO then HFDP, but you could swap the last two.

My idea would be to go to the book store and look through the book for 15 minutes
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: HFOOAD my first impression: Why is J2EE not covered?
 
Similar Threads
Good books for EJB and Design patterns
How to Start the Studies... for Java Architectural Exam ?
Books/References for SCEA
What are the best J2EE Design Patterns books?
oo concepts book