Jump to content


Photo

Find some Head First OOA&D errata?


  • Please log in to reply
6 replies to this topic

#1 j.gohel

j.gohel

    New Member

  • Members
  • Pip
  • 3 posts

Posted 11 December 2006 - 11:29 PM

Please go to the official O'Reilly site to check the current list of known errata and submit yours!

#2 LouBarr

LouBarr

    Active Member

  • Head First Team
  • PipPip
  • 25 posts
  • Location:Cambridge, UK

Posted 12 December 2006 - 03:07 AM

You can submit errata to O'Reilly online: http://oreilly.com/c...6008673/errata/
Louise Barr
Development Editor, Head First

#3 LouBarr

LouBarr

    Active Member

  • Head First Team
  • PipPip
  • 25 posts
  • Location:Cambridge, UK

Posted 12 December 2006 - 02:24 PM

(Several folks whose posts have been rescued from spam pruning)
Chronos Posted: Fri Dec 01, 2006 7:44 am Post subject: HFOOAD errata

Tongue tied design-guru, bottom p10: "That also helps make the code more reusable, so ypu dont have to...." (you is misspelled)

There are no dumb questions, p43:
Q: and what does loosely coupled mean again?

A: Loosely coupled is when the objects in your application each have a specific job to do, and they do only that job. So the functionality of your app is spread out over lots of well-defined objects, which each do a single task really well.


This answer seems to define High Cohesion more than loose coupling.



From Wikipedia:

Cohesion -is a measure of how well the lines of source code within a module work together to provide a specific piece of functionality. Modules with high cohesion tend to be preferable because high cohesion is associated with several desirable traits of software including robustness, reliability, reusability, and understandability whereas low cohesion is associated with undesirable traits such as being difficult to maintain, difficult to test, difficult to reuse, and even difficult to understand.


Low/Loose Coupling - one module does not have to be concerned with the internal implementation of another module, and interacts with another module with a stable interface (see Information hiding). With low coupling, a change in one module will not require a change in the implementation of another module. Low coupling is a sign of a well structured computer system.

- - - - - - - - -

BillMietelski Posted: Fri Dec 01, 2006 9:10 pm

Chronos, nice catch! I just picked up the book, so I haven't made it to page 10 yet, but I did find a few typos in the TOC.

Fyi, for folks that want to submit errata: the publisher has a page set up at ...
http://www.oreilly.c....form/hfobjects

Last edited by BillMietelski on Sat Dec 02, 2006 4:25 am; edited 1 time in total

- - - - - - - - -

Grumbler Posted: Fri Dec 01, 2006 10:44 pm

Bill,

Where did you pick up the book from? My pre-order from Amazon says its in stock but they haven't shipped it and when I call they say I won't be getting it until January 12th - 17th. I'm getting sick of waiting :!: I may order from a place in Maine...they say they have it in stock but now I am started to doubt it ohmy.gif

edit: Update! I ordered it from here and canceled my Amazon order. %50 off too
http://www.bookpool.com/sm/0596008678

- - - - - - - - -

BillMietelski Posted: Fri Dec 01, 2006 11:12 pm

Grumbler,

I got mine from Amazon on Thursday.

I don't have any inside info on how the Amazon systems work, but my suggestion is to cancel your original order. Then once you've confirmed that the order is cancelled, go right back in and place another order.

It sounds screwy, but it worked for me. Maybe the Amazon programmers need to read the book! biggrin.gif

I placed my first pre-order on 11/16. When I heard that Amazon was shipping, I logged in to my account and saw that my order was going nowhere fast. The estimated ship date was still January 16th. Maybe it's a problem with their pre-order process, but since it's so easy to cancel an order, I did just that.

Then I went right back in, and placed another order. That was on Tuesday. The book shipped on Wednesday, and it was delivered yesterday. I actually ordered another copy on Wednesday (I like to keep a copy at home and a copy at the office) and I just checked UPS and it's on a truck to be delivered any minute now.

It all may be a coincidence, but if you just called and they still gave you a January ship date, someone or something ain't right.

Maybe their system starts shipping the most recent orders instead of the oldest orders (just a guess). Or maybe they go by estimated ship date, and the system didn't update the January date on your order. (Again, just a guess).

Anyways, like I said ... I'd try cancelling the original order, and try again. It won't cost you anything, and you just might shake something loose in their shipping system. smile.gif


Update ...

Grumbler, it looks like you found a way while I was typing. It's actually more like 25% off (that 50% is off the List Price, not Amazon's price) but I'm glad you're getting your copy. I've used Bookpool.com myself and have never had a problem.

Last edited by BillMietelski on Sat Dec 02, 2006 1:28 am; edited 1 time in total

- - - - - - - - -

mikefarinha Posted: Fri Dec 01, 2006 11:22 pm

Chronos,

I think that loose coupling is more appropriate than high cohesion. I see them as two things work together, such as:
"Two loosely coupled technologies (such as XHTML & CSS) have high cohesion when implemented together."

In terms of OO programming you would have one object, called car, and another object, called tire. If these two objects are loosely coupled you could implement better traction to the tire object which wouldn't break the car object, but since tire is loosely coupled you can take the tire object and implement it with van, or, truck, or tractor, or swing, or....

am i making sense?

- - - - - - - - -

Chronos Posted: Sat Dec 02, 2006 3:02 am

Mike,

Thanks for your comments. However, you seem to be mixing coupling and cohesion together-even though they are distinctly different concepts. Check out the wikipedia definitions I've supplied above.

If you want to bounce that against another source... say Head First Design Patters: try the definition of cohesion located in the lower right of p339 - or the definition of Loose Coupling, located on the top p53.

- - - - - - - - -

Chronos Posted: Sat Dec 02, 2006 3:08 am

(BillMietelski)
Chronos, nice catch! I just picked up the book, so I haven't made it to page 10 yet, but I did find a few typos in the TOC.

Fyi, for folks that want to submit errata: the publisher has a page set up at ...
http://www.oreilly.c....form/hfobjects


Bill, Thanks for the link!

- - - - - - - - -

Grumbler Posted: Sat Dec 02, 2006 4:13 am

Bill,
I kind of thought the old cancel and re-order trick might have worked but the person I talked to said something about a purchase order for the books and sorry the web site says they are in stock etc etc... Mine was pre-ordered 8-13-2006 so I thought maybe a bunch of people pre-ordered even before that and they sent out the first batch and ran out Next time I will cancel and re-order but for now, I found a new place to check for books
Thanks,
Grumbler
(BillMietelski)
Grumbler,

I got mine from Amazon on Thursday.

I don't have any inside info on how the Amazon systems work, but my suggestion is to cancel your original order. Then once you've confirmed that the order is cancelled, go right back in and place another order.

It sounds screwy, but it worked for me. Maybe the Amazon programmers need to read the book! biggrin.gif

I placed my first pre-order on 11/16. When I heard that Amazon was shipping, I logged in to my account and saw that my order was going nowhere fast. The estimated ship date was still January 16th. Maybe it's a problem with their pre-order process, but since it's so easy to cancel an order, I did just that.

Then I went right back in, and placed another order. That was on Tuesday. The book shipped on Wednesday, and it was delivered yesterday. I actually ordered another copy on Wednesday (I like to keep a copy at home and a copy at the office) and I just checked UPS and it's on a truck to be delivered any minute now.

It all may be a coincidence, but if you just called and they still gave you a January ship date, someone or something ain't right.

Maybe their system starts shipping the most recent orders instead of the oldest orders (just a guess). Or maybe they go by estimated ship date, and the system didn't update the January date on your order. (Again, just a guess).

Anyways, like I said ... I'd try cancelling the original order, and try again. It won't cost you anything, and you just might shake something loose in their shipping system. smile.gif


Update ...

Grumbler, it looks like you found a way while I was typing. It's actually more like 25% off (that 50% is off the List Price, not Amazon's price) but I'm glad you're getting your copy. I've used Bookpool.com myself and have never had a problem.


- - - - - - - - -

mikefarinha Posted: Sat Dec 02, 2006 7:32 pm

Chronos,

I could be mistaken, I haven't yet read my HF patterns book. I have to finish HF Java after my school semester is over(last semester!).

However I see the term loosely coupled to mean dealing with one thing that has little or no knowledge of it's current surroundings but on the other hand that one thing was built to process a particular input regardless of where the input comes from. I used to work in construction with concrete and there are certain types of bolts that you set into the concrete, lets say a half inch anchor bolt. That bolt has to connect to something else, lets say a half inch all-thread. So how do these two things connect together? they use what is called a coupler. Its a common term for anything that connects anything else together, I'm sure you've heard of a coupler. This coupler is a simple piece of hardware. You can screw anything its size into either of its ends. So you can use it to screw in a half inch anchor bolt and a half inch all-thread. Or you can screw in two half inch anchor bolts. Or you can screw in two half inch all-threads. The coupler doesn't care. If you change out an all-thread with an anchor bolt the coupler doesn't care, you don't have to modify the coupler if what ever it was connected to changes... thats how I see loose coupling.

Now from how I understand the term Cohesion, in general, is that two things work well together (both things can be considered loosely coupled) Taking my prior analogy the coupler works extremely well with both an all-thread and and anchor bolt. So I would say that a coupler has High Cohesion with an anchor bolt. It also has High Cohesion with an all thread. now if you took another type of anchor bolt, lets say a 7/16", it may fit into the coupler but it wouldn't be too secure so together they have low cohesion.

Here's a good diagram of what I'm talking about.


However I could be completely mistaken!

- - - - - - - - -

Chronos Posted: Sat Dec 02, 2006 7:32 pm

Mike,

Thanks for the extended explanation of your understanding. I know your trying to tie concepts to what you already know... it can be a useful way to understand and process new information. However, it can lead you astray... as in your understanding of Cohesion.

Cohesion isn't about working together at all. It's about how well a class (or method) does one thing, and one thing well. That's it! Lets take Amazon.com for example. If Amazon.com has a java class that has three methods: process payment, lookup books, and add to wish list-we'd say that the class has LOW COHESION: it does many different things. Lets say that we refactor that one class into three classes, one that process payment, one that does book lookup, and one that adds to wish list... then we can say the classes have HIGH COHESION: they do one thing, and one thing well.

From hardware/tools perspective... we might say that an allen wrench is a highly cohesive tool... it does one thing, and one thing well. An allen wrench isn't really useful for much else, agree? Take a hammer on the other hand. I've used a hammer to put nails in the wall, remove them, pull up sod, punch holes in the wall (after missing nails!), as a crowbar, etc. I think we'd agree that a hammer isn't very specialized as a tool, and could be considred a low cohesion choice.


Coupling has to do with how much knowlege two classes have to know about each other in order to be useful. If class A knows about class B, and class B knows about class A, we'd say that these two classes are TIGHTLY COUPLED. Now-let's say that class A knows about interface B. If classes C, D, and E all implement interface B -then we'd say that while class A only knows about interface B, it can use classes C, D, and E. This is an example of how to reduce coupling, leading to LOOSE COUPLING.

A screw and a washer are good examples here. A screw doesn't need to know about a washer to do it's job, but it can work well with a washer. A washer can work with a screw, nail, or without either really. We'd classify a screw and a washer as loosely coupled.

Now, lets take a bolt and the correctly fitting nut. These two things know which size they are, and which size they interface with. If you get the wrong size nut for a bolt, it's not much good. And the bolt really needs to interface with a nut, which has specific threads (coarse, vs fine). Nuts and bolts know the details about each other. We'd consider a bold and nut to be very tightly coupled.... they are very useful when paired correctly, but really aren't very useful when not paired-or when paired incorrectly.

- - - - - - - - -

mikefarinha Posted: Sat Dec 02, 2006 7:32 pm
However, it can lead you astray... as in your understanding of Cohesion.


I see the light now!

You're right my definition of Cohesion wasn't right. I should have done more research before posting! :oops:

I'll have to get back to you after I read my HF OOAD and Design Patterns....

Thanks for the lengthy explanation Chronos! biggrin.gif

- - - - - - - - -

brett Posted: Tue Dec 05, 2006 5:07 pm

Cohesion and coupling are very much related concepts. In general (and generalities are just that -- generalities) the higher the cohesion of the objects in your application, the more loosely coupled they are. It's in fact very hard to accurately talk about coupling without also talking about cohesion.

I think it's also worth pointing out that in Head First books, all that there is to say on one topic is rarely in one place. So what may seem like an over-simplification or over-statement in an earlier section is merely getting the learner's brain into a general understanding, that will be made more specific in later chapters. Cohesion and loose coupling are dealt with again in Chapter 5, and dealt with at length. They also come back into play in Chapter 10.

As for cohesion being about things working together, the definition isn't, but the practical application is. You simply cannot have an object with high cohesion that is intrinsically tied or coupled to another object, in terms of functionality. Two objects that are highly cohesive may refer to and use each other often, but cannot depend on each other (or the cohesion begins to break down). So from a practical point of view, I do believe that it's appropriate to tie the terms together.

As for coupling, coupling really isn't about knowledge of other objects; it's about dependence on other objects. You could have a highly cohesive class, a loosely coupled class, in a system where every single method and variable are public. So classes could "know" about each other, but if they're not dependent on each other to function, loose coupling is still in effect. But I think you're using knowledge more in terms of dependence.

Again, I really think it's counter-intuitive, and actually counter-practical, to try and wedge these terms apart. They're much better seen as closely related for practical implementation and usage.

One last note, as I don't want this to be an argument or defense as much as a discussion: we're far more interested in the deep concepts in any Head First book, over learning a formal definition. So I'd suggest that for the learner to tie the concepts of coupling and cohesion together is a GOOD thing; it is not as formal as some might desire, but much of what we believe makes OOA&D useful is getting away from formality, and instead focusing on practicality.

Hope this clears things up some.

-Brett
_________________
Brett McLaughlin
Series Editor, Head First


#4 jamesm

jamesm

    New Member

  • Members
  • Pip
  • 8 posts

Posted 02 January 2007 - 12:59 PM

Inventory.java on page 5 has a bigger problem than the String comparisons: the rather vital line "return guitar;" (present in the code on page 17) is entirely missing!

#5 jamesm

jamesm

    New Member

  • Members
  • Pip
  • 8 posts

Posted 04 January 2007 - 03:36 PM

page 248, penultimate statement from Jill, first line: "proeprties" should be "properties".

page 574, last line: "think" should be "thank".

#6 BillMietelski

BillMietelski

    Active Member

  • Members
  • PipPip
  • 28 posts

Posted 19 January 2007 - 02:31 PM

Fyi, for folks that want to submit errata: the publisher has a page set up at ...
http://oreilly.com/c...6008673/errata/

#7 Listi Hade

Listi Hade

    Active Member

  • Members
  • PipPip
  • 23 posts

Posted 30 August 2015 - 10:04 PM

https://www.squadup....e-2-online-full






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users