@Henry, If you have understood both Head First books I doubt you would have 
asked some of the questions you have recently.

I have read both books about 5 times and still don't 'get' bits of them and 
have only applied a few of the patterns in the patterns book and still fail at 
complying to the key OO principles spelled out in the OO book.

I am now at the stage where occasionally I can see a perfect place for a 
pattern. I saw a perfect case for Template Method 2 days ago but have never 
used it before. I'm looking forward to giving it a try.

Other books I would recommend:

Martin Fowler's Patterns of Enterprise Application Architecture - 
http://www.amazon.co.uk/Enterprise-Application-Architecture-Addison-Wesley-signature/dp/0321127420/ref=pd_sim_b_6
These are patterns more concerned with ORM, tiered server apps etc and
has patterns like Service Layer,  Row Data Gateway, Active Record
(Reactor, Rails, Grails), Data Mapper, Front Controller,
MVC, Page Controller, etc etc

Design Patterns Explained: A New Perspective on Object-Oriented Design - 
http://www.amazon.co.uk/Design-Patterns-Explained-Perspective-Object-Oriented/dp/0321247140/ref=sr_1_1?ie=UTF8&s=books&qid=1230041055&sr=1-1
Worth it just for its excellent explanations of Strategy and Factory
patterns.

Martin Fowler's Refactoring - 
http://www.amazon.co.uk/Refactoring-Improving-Design-Existing-Technology/dp/0201485672/ref=pd_sim_b_3
A classic with LOTS of simple common sense refactorings like 'move
method', 'extract method', 'replace conditionals with polymorphism' etc etc

Uncle Bob Martin's Agile Principles, Patterns, and Practices in C# - 
http://www.amazon.co.uk/Principles-Patterns-Practices-Robert-Martin/dp/0131857258/ref=sr_1_1?ie=UTF8&s=books&qid=1230041170&sr=1-1
A heavier read but good chapters on unit testing, various OO
principles, DRY, LSP, OCP, Hollywood Principle (Don't call us, we'll
call you!)
Also, his chapter on designing a coffee maker app shows you how NOT to
build an OO model and avoid GOD classes and the dreaded Anemic Domain
Model

Uncle Bob Martin's Clean Code - 
http://www.amazon.co.uk/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882/ref=sr_1_1?ie=UTF8&s=books&qid=1235267448&sr=1-1
It will embarrass you by spelling out all the things you should do but don't do 
(like Pragmatic Programmer does!) but about 50% of it is essential reading, 
lots of great standards to try to comply with:
ie 
Methods
Only one Level Of Abstraction per method
No more than THREE arguments for a method
Command Query Separation
Prefer exception to error code
Only one level of indentation per method

Comments
Explain yourself in code, not comments (like Fowler's 'when you feel the need 
to write a comment write a method instead' rule) 
Delete commented code (as we have source control for this)

etc etc

If you feel you understand all the patterns in Head First Design Patterns and 
have fully grasped the SOLID principles (many explained in Head First OO like 
SRP, OCP, LSP, DIP) please teach me as I'm still finding my feet with them :-)

Alan






 Alan
www.alanlivie.com




________________________________
From: Henry Ho <[email protected]>
To: [email protected]
Sent: Sunday, February 22, 2009 1:03:18 AM
Subject: [CFCDEV] Re: To Reference or not to reference... that is my  question

I'm actually very fortunate that my local library has an e-book library that 
has almost every tech book out there available for free anytime anywhere.  

I have read the two OO books from the Head First series.  I'm aware of some of 
the OO principles and design patterns. I've read the 2 classics (Code Complete, 
and The Pragmatic Programmer).

Any other good books on OO and design in general that you guys recommend?  
Prefer something harder than just introduction to OO, OO principles, and design 
pattern?

Thanks,

Henry Ho



On Sat, Feb 21, 2009 at 4:13 PM, Sean Corfield <[email protected]> wrote:


On Sat, Feb 21, 2009 at 9:52 AM, Jared Rypka-Hauer
<[email protected]> wrote:
> Behind every successful programmer is a huge library of books he
> hasn't looked at in years.

Hey, stop looking in my office!

(I have bookcases full of great computing books that I'm embarrassed
to admin I have mostly not read at all, let alone in years... these
days, they're there for when I get stuck and need a fresh perspective)

I started do OOP in 1992 using C++. All of my early code sucked. Over
time it sucked less. I started doing Java in 1997. I've worked in a
variety of OO languages over the years and each new language has
taught me new ways to approach problems which is why I highly
recommend learning additional languages - that are very different from
your day-to-day language(s). Learn Smalltalk, learn Prolog, learn
Haskell. You'll probably never use them in your day job but you'll
learn great new techniques. Of those, only Smalltalk is OO - Prolog is
declarative, Haskell is functional - but all three will change the way
you think about problems. After 17 years of OOP, I'm still improving
my design skills and try to "learn something new every day". It's a
journey, not just a destination.

On UML, I agree with Alan: use UML to sketch out ideas but don't try
to use it to specify your code. Activity diagrams are by far the most
important type to learn and use, more so than Class diagrams.
Collaboration diagrams (aka Communication diagrams) are also very
important if you're intent on going down the UML route. I've used UML
on and off for a long, long time. In fact I started with OOSE (Ivar
Jacobson) and the Booch method (Grady Booch) before they joined forces
with James Rumbaugh (originator of OMT) to collaborate on what became
UML. OOSE was very focused on Use Cases which helped me focus on
high-level specifications rather than digging into class-level stuff
too quickly. I've worked on projects that use UML very formally and
they were hard work - for the same reason that trying to use Z to
specify a system is hard work: when it comes down to details, code is
much easier to write than a specification of that code.
--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood






      
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"CFCDev" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/cfcdev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to