rbwhitaker
commented
1 year ago The object-oriented pathway has been significantly revised. I think the book technically still has a fair bit about CRC cards, which I plan on trimming down more. I'm not even sure I want to keep the topic in there, beyond maybe mentioning it. Though I could easily imagine pulling it out into a blog post/article or YouTube video for people who still want to see it. I might also do a similar thing with UML, whiteboard sketches, and code sketches. Frankly, diagramming is perhaps better shown than written anyway.
So this is largely done at this point, though it definitely still needs a lot of revising.
In 1st and 2nd Editions, the book was quite weak with regard to object-oriented design, but there were no challenges that pushed you to a point of needing to actually do anything too fancy, so most people went without really getting good at it. In 3rd Edition, I added Tic-Tac-Toe to the list of challenges, and suddenly, everybody felt like they had no clue what they were doing. In 4th Edition, I seriously revised this section of the book to make the learning curve easier, and got a lot of feedback that it was substantially improved. Having said that, I've still seen a lot of people struggle with it, and I see far more people asking questions about the challenges and chapters before The Catacombs of the Class than after it. I think a lot of people drop off at this point, because the learning curve is still somewhat steep. I'd like to revisit this and try to make some improvements.
One big question I have is about the emphasis on CRC cards. I'm not sure how much this particular conversation matters, and it takes up a lot of space in the book. The content I'm describing here could simply augment the CRC discussion, and the CRC challenges in the Catacombs of the Class could definitely stick around. But I could also see removing the CRC card discussion entirely, or maybe reducing its significance, leaving people with maybe just one CRC card challenge for a bit of practice, and then focus on other challenges.
As far as the learning curve here goes, I tend to see two problems that are closely related.
First, there's a big jump from the challenges so far, which ask people to make a single class (perhaps augmented by an enumeration or two) and a main method that makes one or two instances, all the way to "make a program with about five classes that all interact well with each other." There needs to be some middle ground as a stepping stone.
The other problem is just not knowing where one object should end and another should begin, and how to get them all to work together. This is exactly the object-oriented design challenge, and this book really can't cover it all in any depth. But readers deserve a bit more guidance around how to do this. The book needs to get them off on the right foot.
The Object-Oriented Design chapter and the Catacombs of the Class's middle section strike me as the right place to do this. I don't know the details now, but I think the OOD chapter should include a challenge or two that deal with getting two to five objects of different types to work together. Then I'm wondering about making the Chamber of Design into something different that gives people several more (and growing in size) challenges of this nature, so that when Tic-Tac-Toe comes around, it really isn't even that big of a leap.
There's a set of examples I walked some people through on Discord that might be helpful. This won't make sense to others reading it, but just as a reminder to myself, I liked the example there with a ship with guns and an ammo supply that was eventually shared.
The book should walk through the ship making new instances of the gun and eventually making an ammo supply that is shared among all of them. This could eventually evolve into an engine with power and needing to draw power to fire, etc. But the idea is to work through several situations that increase in complexity to illustrate who should bring objects to life, how they get passed around, and how they interact with each other.
There should be conversations here about knowing when one object should end and another should begin, as well as how objects should come into contact with each other.
There is also room here to revisit these when introducing abstract classes and interfaces.
In short, I think the book needs a couple of "growing boy" examples to flesh out these ideas better.
I also think this chapter deserves a challenge or two of its own, but I also think I want to de-emphasize CRC cards in the Catacombs of the Class in favor of expecting people to build small groups of objects in code. And with that, I'm not even sure CRC cards make a ton of sense. (Though it would not be hard to keep CRC cards as a blog post and video as supplementary material, if I do decide to completely remove it.)