i had a great experience with OO design in an internship in grad school. i was sole coder on a java project, a networked whiteboard app, and i had the time and

i had a great experience with OO design in an internship in grad school. i was sole coder on a java project, a networked whiteboard app, and i had the time and flexibility to scrap the whole thing halfway through and rewrite it from scratch once i had some clue about the problem domain. the best thing is that since the main functionality was a vector graphics editor, i actually got to implement one of the classic blackboard OO examples in practice, and see how it really worked out: Interface Shape AbstractShape implements Shape TwoPointShape extends AbstractShape Rectangle extends TwoPointShape Ellipse extends TwoPointShape Line extends TwoPointShape Arrow extends Line Text extends AbstractShape Icon extends AbstractShape Raster extends AbstractShape (or something like that) obviously this was the product of a lot of refactoring (i think the TwoPointShape "insight" came to me relatively late in the project) of course, i ended up spending most of my time chasing ConcurrentModificationException and jumping back and forth between two or three boxes tracking down network synchronization bugs (client A begins moving an icon, client B begins moving the same icon, client C begins moving the same icon, client B releases the mouse, client C releases the mouse, client A releases the mouse: what happens?), but that taught valuable lessons too: specifically, all they really ever teach in school is what i call the data paradigm: your app starts, takes input, does stuff, stops. gui- and network-event-based programs, and how to design, test, and debug them, barely come up. of course once i got into industry, i got turned on to array programming and never looked back :-)