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 -~----------~----~----~----~------~----~------~--~---
