In training a developer new to object orientation, the discussion of encapsulation took a turn into composition. It all started with the developer attempting to make an object completely stand alone. When he was done, the object was so bloated with code that you practically had to use a wheelbarrow to move it around. Rather than drowning the boy in design patterns I tried a different approach. I tried to explain that although his intentions were good, how he went about it was not. In his efforts to encapsulate everything relevent to the object, he had also begun to encapsulate functionality in such a way as to make the object a composition of functionality. When we first learn to develop, our throughts tend to be sequential and subsequently, we lay our code down the same way. What that does is to combine the code into streams of functional activity. The coder sees what they want to put in and what they want to get out and think that the gigantic mound of code in the middle ‘encapsulates’. It does not. Say it with me: segregate, segregate, segregate. To keep our code agile we must break out functionality in the same way that we break out the changable v/s non-changable portions of our code. What I did to help the developer was to help him see the individual pieces of functionality and help him begin to move those out into separate classes that will manage that functionality for him (I didn’t break it to him that he had just started his journey down ‘behaviorial programming’! 🙂

When you’re teaching or training or simply helping another developer, don’t show off how many technical or OO or DP terms you know. Rather help them by guiding them to the point where they can discover how best to architect their code. They’ll learn more, appreciate and respect you more and you’ll have a much better developer.