We = Programmers.new
May 3, 2008 11:36 AM   Subscribe

What are good books, techniques and project for an object-oriented programming study-group?

A friend and I are looking to improve our programming skills. We have fairly similar backgrounds -- about 4 years of VBScript, PHP, HTML type work. Both of us want to improve our skills in OO programming, as well as learn more about non-web-based projects.

A common technique I've seen is for people to form study groups and work through the classics of programming lit: Design Patterns, Refactoring, Etc. They read the book, meet, discuss, examine, etc.

I think that sort of structure could work well for us. We're both bookish types. But I'd also like us to apply the book knowledge to actual code, some sort of project that we develop as we work our way through the text. Implementing the Factory pattern is going to teach us more than just reading about it, I think.

So have you ever done anything like this? What did you find that worked? What sort of project allows you to try out all these technique you learn about?

Also, is there a book that you'd suggest? I think we're going to work in Ruby, so I'm planning on reading "Ruby Design Patterns." I'd also like to dig into Martin Fowler's "Refactoring."
posted by iwhitney to Education (8 answers total) 9 users marked this as a favorite
 
I agree with you that writing actual code is going to be a lot more helpful than just reading about it. Most of the concepts of OOP don't really make sense in small one-page examples, you really have to use them on a real project before they actually show benefits.

I would suggest picking up a book about Extreme Programming (Kent Beck, the guy who created XP, has a good one). Even if you never work on an XP team, you'll learn about techniques like pair programming, writing unit tests, and refactoring, which will all be useful in learning the overall OOP stuff.

In fact, I would also suggest finding some other friend to use as a customer, and forming a two-man XP team to write a simple application for him/her. Using a real person as a customer works better than being the customer yourself, because real customers change their minds much more often and can force you to drastically change your design. Those kinds of changes happen often in real life, and they are what OOP and XP were designed to help with.

Also, I personally like Ruby as a language, but as of today it is mostly used in web projects because of the success of Rails. If you want more non-web experience, I would suggest going with C# or Java, because they are heavily used in the industry for application programming. Also, no matter which programming language you pick, make sure to look around for the best open source IDEs, unit testing frameworks, and refactoring tools.
posted by burnmp3s at 12:10 PM on May 3, 2008


More recommended books:

* Head-First Object-Oriented Analysis and Design - Intended to be quickly digested, will hold your hands through several OO design planning phases, with their insights and pitfalls.
* Smalltalk-80: The Language and Its Implementation -- Learn other (more conceptually pure) expressions of OO, where it came from, idioms, etc. (Similarly, if you want to learn functional programming, I would suggest playing with Haskell, even though you may do most of your coding in something less pure/more pragmatic (e.g. ocaml).)

Pre-emptively nth-ing Refactoring.

Also, I don't want to start a language pissing match, but several other languages have informatively different implementations of OO than VB, PHP (?), and Ruby -- it would likely be very enlightening to see how Python / Common Lisp CLOS / ocaml / Smalltalk / etc. have styled their OO systems.
posted by trouserbat at 12:21 PM on May 3, 2008


This doesn't specifically answer your question, but one of you could try picking an open source project and analyzing how it's built. Really go through and understand how the components fit together, graph out class relationships and give a presentation to the other member(s) of the group. Talk about design decisions they made (and possible alternatives), code structure, code completeness, code messiness, etc. Create graphs and see if you can really explain, at a high level, how every piece of the system fits together. Explain all of this to your group and then donate your presentation and graphics (and written explanation) back to the project as documentation.
posted by null terminated at 1:46 PM on May 3, 2008


Another thumbs up for Python, which is remarkably coherent. Ruby is fine too, but I'm still a bit turned off by the stuff it inherited from Perl.

A couple of older OOP classics:

Grady Booch's OO book and Brad Cox's Objective-C book.

Bertrand Meyer's book
is also recommended often, but I haven't read this edition.

In any case, be careful with patterns; watch for the case of "we have this pattern, how should we use it?" when it should be "we have this particular problem, which patterns might help?". Implementing patterns just for the sake of it is pointless, they are just the beginning of a vocabulary, not a definitive list of solutions.

The "two things" about programming to remember:

* Don't Repeat Yourself
* Nothing works until it's proven to work, and usually not even then
posted by and for no one at 1:54 PM on May 3, 2008


Don't get ahead of yourself. Before worrying about design patterns, be sure to have a steady grip on the OO fundamentals - polymorphism, inheritance, aggregation, encapsulation... Scott Ambler, The Object Primer is both accessible and covers the basics very thoroughly in a technology-neutral way. Bruce Eckel has a rare knack for explaining OO concepts. Even if you're not interested in Java, the first few chapters of his Thinking in Java is one of the clearest treatments I've seen. I find the Head First books hard to read and cheesily tiring in their breezy and breathless faux-enthusiasm, but maybe that's just me. When you get to design patterns, the classic is still the best. As for projects, building something you're enthusiastic about will always beat contrived examples from books.
posted by normy at 2:51 PM on May 3, 2008


Also, find an idea you would both like to implement and go for it. Plan it out beforehand, but don't get too wrapped up in that. When it feels like you're writing repetitive code (or at least once every few days, before you have a finely-honed sense of that), take a break and go back, look for stuff you could consolidate better. Find stuff that works, but feels awkward, but works, so you've let it live, and don't.

And, seconding _and for no one's_ thoughts above, particularly the 'watch for the case of "we have this pattern, how should we use it?" when it should be "we have this particular problem, which patterns might help?".' part.
posted by trouserbat at 3:06 PM on May 3, 2008


While not OO specific, there's lots of worthwhile advice in this previous thread.
posted by and for no one at 3:49 PM on May 3, 2008


Both of us want to improve our skills in OO programming, as well as learn more about non-web-based projects.

If you really want to get familiar with OO programming, I strongly recommend using a language like Java where everything is very clearly marked out (if verbose). It'll help you understand the Big Concepts quicker. Further, there's boatloads of free source code available to study and learn from. Finally, it's one of those languages that runs the gamut: you can write games, you can write accounting software, web sites with database access and concurrent automated processing... the sky's the limit, really.

What sort of project allows you to try out all these technique you learn about?

That's tough.

The problem with stuff like this is that everyone always thinks they're being so clever by starting off with something really simple and straightforward that can be built upon. So they'll do something like "code up a Blog" or "code up a Game." But at the end of it, the code you produce is no better than a sample for an Intro to Programming book. Why? Because of Rule #1:

RULE #1
Good code needs a good reason.

That's one of the reasons OSS tends to lose a lot of good programmers: money is a good reason, but perhaps even more important is you get to code real world problems. If you're the only one defining parameters for yourself, it's way too tempting to "take it easy" and not challenge yourself. So I'd recommend thinking about it more pragmatically.

Take a look around you. See if you can spot any places in regular day-to-day life with... let's call them "Computing Inefficiencies." The most dire computing inefficiency would be Total Lack of Computing, for instance. When I was traveling around Southeast Asia, I kept coming across these bed & breakfast / bungalow-style, mom-and-pop guest lodgings that were handling all their transactions with cash and a ledger. Think of all the time that could be saved by coming up with a faster interface to handle guest registration... or handling the accounting... booking in advance... there are a dozen ways a computer could really help here.

As a programmer looking for something to do, you have to take something like this and make it generic. Think about how you might write a software package that handles bookings, reservations, rooms... you'll need a database, an interface... do you want to make this web-based for online booking? do you need it to be fast, or is it more important that it's reliable? What are some things people in the industry might like to see, what would be helpful... all kinds of exciting challenges to solve, made all the more so because it's a real task that has a real goal. You can take these computing inefficiencies you find in your everyday life and make them grand in scale--instead of solving one person's problem, see if you can build something that you could market to a whole group of people.

If you're having a hard time thinking of just what to do, I honestly suggest getting out of your house and taking a walk around town. The possibilities are endless. For example, I'd bet the sort of software that dentists need can't be that complicated. You'll need a general appointment system. A client database. Some teeth-related stuff... maybe the ability to upload images. Go as crazy as you like! How about an interactive 3D model of a mouth--you could just use a generic 3D model, it doesn't have to be any particular client--that the dentist could, like, "tag" or annotate with notes. So, you'd see this interface with a big 3D mouth, and you can click the mouth and rotate it around, and maybe a few of the teeth are red instead of white because they've got "notes" attached to them, and when you click on the tooth a note pops up with more details... Wouldn't that be awesome?

I being a little silly, of course, but my point is that there are literally a million-zillion (literally!) programming problems you can find just walking around. Some might be too difficult to tackle without a large group, but a MANY of them will be simple, straight-forward issues that everyone has in common (storing a list of contacts, for instance, or adding a bunch of amounts together). The funny thing is, even though your typical dentist's office won't need anything more than a Pentium 90 to operate, I would bet you cold, hard, cash that there are something like two companies that write that software (at most), and both charge $40,000 for this easy-peasy code because they're the only game in town--solving a dentist's day-to-day problems isn't nearly as cool as writing your own video game.
posted by Civil_Disobedient at 4:27 PM on May 3, 2008 [1 favorite]


« Older Help me find the image manager of my dreams?   |   Want AVG 7.5 back!!! Newer »
This thread is closed to new comments.