One of the things that can make our codebase somewhat difficult to work with (making defects much too easy to create) is that we often lack locality of concept.
(Hmmm. Sounds like something Gold would say. But what the hell does it mean?)
Code both does things and decides how things are to be done. Is this valid? No? Kick it out! Is it red? Do this. Is it blue? Do this. Is it purple? Ah, that’s a special case, do this, this and this.
Despite the possible complexity of these decisions, it’s not too hard to keep all the business logic contained therein straight – at least so long as all of that business logic lives in the same place. Often, for what are good, pragmatic reasons at the time of writing, some of this logic ends up getting smeared about the codebase. And before long, some of the behavior associated with various objects becomes somewhat less clear, especially when new functionality is introduced.
So keep that in mind. No one really wants to have to do a deep code grovel to understand how an instance of a class behaves; besides, having to do such a grovel greatly enhances the chances of getting things wrong.
So keep it together, because locality matters!
make it simpler 