888 888 d8b 888 888 Y8P 888 888 .d8888b .d88b. 88888b.d88b. .d88b. 888888 88888b. 888 88888b. .d88b. 88K d88""88b 888 "888 "88b d8P Y8b 888 888 "88b 888 888 "88b d88P"88b "Y8888b. 888 888 888 888 888 88888888 888 888 888 888 888 888 888 888 X88 Y88..88P 888 888 888 Y8b. Y88b. 888 888 888 888 888 Y88b 888 88888P' "Y88P" 888 888 888 "Y8888 "Y888 888 888 888 888 888 "Y88888 888 Y8b d88P "Y88P" d8b d8b 888 Y8P 88P 888 8P 888 888 .d8888b 88888b. " 888888 888 88K 888 "88b 888 888 "Y8888b. 888 888 888 888 X88 888 888 Y88b. 888 88888P' 888 888 "Y888 888 888 d8b 888 888 Y8P 888 888 .d8888b .d88b. 88888b.d88b. .d88b. 888888 88888b. 888 88888b. .d88b. 88K d88""88b 888 "888 "88b d8P Y8b 888 888 "88b 888 888 "88b d88P"88b "Y8888b. 888 888 888 888 888 88888888 888 888 888 888 888 888 888 888 X88 Y88..88P 888 888 888 Y8b. Y88b. 888 888 888 888 888 Y88b 888 88888P' "Y88P" 888 888 888 "Y8888 "Y888 888 888 888 888 888 "Y88888 888 Y8b d88P "Y88P" 888 888 888 .d88b. 888 .d8888b .d88b. d8P Y8b 888 88K d8P Y8b 88888888 888 "Y8888b. 88888888 Y8b. 888 X88 Y8b. "Y8888 888 88888P' "Y8888
Smalltalk: Lost and Found
After Almost 40 years, It’s Still Taking Us to School
Smalltalk is the first and still canonical object-oriented programming language. Alan Kay and other members of the Learning Research Group at Xerox PARC (Palo Alto Research Center) developed Smalltalk in the 1970s. Smalltalk use decreased over the decades, but it’s gaining attention as developers struggling with increasingly complex code look to abandon procedural metaphors for simpler higher level metaphors. We can still learn from Smalltalk even if we don’t use it. (Though we should consider using it.)
When examining Smalltalk we find today’s “object-oriented” tools missed a few essential concepts when they adopted object-orientation. Sacrificing these concepts means developers lost some powerful programming metaphors.
OOP promises organization, simplicity, flexibility, and reusability, yet we often experience disorganized, tangled, inflexible, and duplicate code. Today’s popular multi-paradigm languages make it easier to write procedural code rather than object-oriented code.
Pure object-oriented programming allows building systems with less shared state, less unwanted coupling, and even less code. It reduces time developers need to understand and change code. Readable, decoupled, and testable code means moving fast without breaking things. Ultimately it saves time, and time is money. I like money. You like money too? We should hang out.
Revisiting Nouns and Verbs
There Is No Spoon
Something learned early when studying OOP is to name classes as nouns or noun-phrases and name methods as verbs. It seems like too simple an idea to make better object-oriented designs, but it makes a big difference. In fact, there is reasonable evidence that adherence to this idea could make a design, and ignorance of it could break one. The evidence comes from my own experiences refactoring code as well as what I’ve recently learned while studying Smalltalk.
Naming has such an effect because better names reduce the context an object has, i.e., what an object is aware of versus what it needs awareness of to do its job. Removing unnecessary information raises the level of abstraction providing more opportunity for reuse and minimizes the chance that the message needs changing when requirements change.
A message name constrains the possible interpretations to some extent, which is good. This indicates what the program is doing when the object sends the message and hints to implementing objects the context in which they are operating. However, we should only constrain the meaning of a message as much as necessary and not so much to exclude other valid uses.
To summarize what I’ll be talking about: If an object sends a message that mentions any noun other than those that indicate the parameters it’s passing then there is likely added context and a case for renaming.
Notice I said “likely”. There’s no need to deal in absolutes (as only the Sith do). As I’ve learned more about programming, and life, I’ve learned that nothing is absolute. Everything is relative. You can find exceptions to every rule. Black and white are just acute versions gray.
Messages should only include nouns within their context because messages are ignorant of the things that respond to them and the inner parts of the things that respond to them.
If you remember the movie “The Matrix”*, there is the famous scene when Neo visits The Oracle and meets a boy who bends spoons with his mind. When Neo attempts this, the boy gives him a helpful tip:
Do not try and bend the spoon, that’s impossible. Instead, only try to realize the truth…there is no spoon. Then you will see it is not the spoon that bends, it is only yourself. -Spoon Boy, The Matrix movie
Shower Idea: Keyboards and Object-Oriented Design
You know that hypnotic thinking that happens in the shower? I do that outside of the shower. I’m not just staring at the wall. That’s the story of why I’m calling this a shower idea (even though I didn’t think of this in the shower).
I’ll probably post more of these shower ideas in the future. I usually forget to write them down, but I’m going to stop doing that. These ideas aren’t groundbreaking. They’re just interesting food for thought.
Adventures in Programming with Java: The Beginning
Update: Life has a way of getting between us and our best intentions. The person who I was working with is recently overwhelmed by obligations at work and home. Unfortunately, we are unable to proceed with our learning project at present. Maybe in the future we will try again. I’ll leave this post up because I still think it has some good information in it.
Someone I know recently got the programming itch. It began with a foray into an Excel spreadsheet application using Visual Basic for Applications. The urge to build other things soon took grasp, and this person is now interested in diving deeper.
I don’t think I’m in any position to teach someone programming as I have too many of my own questions on the subject. It’s been said, however, that teaching something is a good way to solidify what you know and change your perspective of your own knowledge. Teaching forces you to simplify what you know. Having a simple mental model of something complex is a perspective that is difficult to attain once you’re past childhood. Teaching others is an opportunity to devise a simple model for someone else, and if we retain that simplified model ourselves, it enriches what we know about the complex nature of… whatever complex thing we’re talking about.
This is my ball of mud. There are many like it, but this one is mine.
This Is My Ball of Mud
In college I wrote a solution for the Knight’s Tour. Since then I’ve planned to build a full chess program for playing chess games (not to be confused with a chess engine, which is more like an artificial intelligence that plots and plans chess moves). Not only did I want to build a chess game, but I wanted to use it as an experiment to test what I’ve learned about object-oriented design. I’ve made a few trial runs at it over the last few months, but always hit a design wall. Every few weeks I pick it up again and eventually hit a wall that stops me dead in my tracks. I’ve rebuilt the project from scratch about ten times now. Picking it up again recently, I decided this time I’m going to build this damn thing once and for all. Guess what happened? Wall. All these walls are starting to look like a castle, and I don’t mean the fun bouncy kind. Continue reading
Reoriented
“Education is what remains after one has forgotten what one has learned in school.”
-Albert Einstein
What have I learned about programming, and OOP in general?
One of the biggest eye-openers is very simple. An idea that can easily get lost when using high level languages or discussing the philosophy of what’s right and wrong in programming. It’s also lost on anyone who doesn’t study computer science in school and only programming (/raisehand). Just like we don’t consciously think about tying our shoes, we don’t always think about the intricate roots of programming when we’re doing it.
The idea is that math is the basis for programming, and follows much of the same rules of mathematics. Math and programming both share certain protocols for operating on data sets. Those protocols include things like inputs, outputs, domains, ranges, abstractions, and functions. I’m no math whiz, but I’ll do my best to explain what I mean. Continue reading
Looking in the Mirror
What’s Going on Here?
Object-oriented programming concepts are almost universally problematic for new programmers (including myself). It’s easy enough to find information about these concepts, but my understanding of them always feels incomplete. If you search the Internet you’ll find lots of guidelines to correctly structure and write object-oriented code. There are also various concepts that are important to understand like abstraction, and encapsulation, etc. You’ve probably heard them all by now. If you haven’t heard of these concepts, then get a book on object-oriented programming. My goal is not to explain what’s already been explained elsewhere in great detail. My goal is to try to offer my perspectives on what I learn in order to help programmers on the same path avoid long periods of confusion and frustration. One of the things I hope to do here is analyze my own projects and show why I make specific design choices, what concepts and guidelines do I consider when making my choices, and what my alternative choices are and why I didn’t choose them. Continue reading