• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

HFOOAD my first impression: Why is J2EE not covered?

 
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 9050
21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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".
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Peer Reynders:
HFEJB: Patterns and Performance, the Lost (last) Chapter



Thanks for the wonderful link Peer .

Bert, do you remember Peer's thread ?

Regards,
Darya
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 9050
21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ]
 
Ranch Hand
Posts: 1847
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Darya Akbari
Ranch Hand
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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."
 
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 9050
21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Welcome to the ranch Gary!

But be careful, this place can become addictive

Bert
 
Gary Pollice
Greenhorn
Posts: 2
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Ranch Hand
Posts: 372
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1855
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 9050
21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ruth Stout was famous for gardening naked. Just like this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic