Let me say right off the bat that the features we will discuss here are pure poison brought to object-oriented programming by those who desperately needed a lobotomy, just like David West suggested in his Object Thinking book. These features have different names, but the most common ones are traits and mixins. I seriously can't understand how we can still call programming object-oriented when it has these features.
During nearly every presentation in which I explain my view of object-oriented programming, there is someone who shares a comment like this: "If we follow your advice, we will have so many small classes." And my answer is always the same: "Of course we will, and that's great!" I honestly believe that even if you can't consider having "a lot of classes" a virtue, you can't call it a drawback of any truly object-oriented code either. However, there may come a point when classes become a problem; let's see when, how, and what to do about that.
This is a real story, and it's not only about Google. I'm getting emails from recruiters at Amazon, Facebook, and smaller Silicon Valley startups. They find me somehow, most likely through this blog, my books, or my GitHub account. They always start with "We're so impressed by your profile" and finish with "Let's schedule an interview." I always reply with the same text, and they always disappear, only to come back in a few months under a different name. Let me explain my reasons; maybe you will do the same and we can change this situation in the industry.
I've said before that your StackOverflow reputation is very important to us when we make a decision on how much we should pay a software developer. However, there were many complaints about this metric. Take, for example, the ones here and here. In a nutshell, so many of you disagreed and said that the number of StackOverflow up-votes was nothing more than a measurement of the amount of time someone spent answering stupid questions asked by clueless programmers. Let me disagree and explain why your activity on this platform is so important to your career.
Do you have private static methods that help you break your algorithms down into smaller parts? I do. Every time I write a new method, I realize that it can be a new class instead. Of course, I don't make classes out of all of them, but that has to be the goal. Private static methods are not reusable, while classes are—that is the main difference between them, and it is crucial.
Sometimes Very often I need a class that implements an interface by making an instance of another class. Sound weird? Let me show you an example. There are many classes of that kind in the Takes Framework, and they all are named like *Wrap. It's a convenient design concept that, unfortunately, looks rather verbose in Java. It would be great to have something shorter, like in EO for example.
I get questions like this all the time: How does one become a senior software developer or an architect? How does one grow from a junior just starting to write Java code to the leader of a software team that is driving a BMW and making $150K+ per year? What are the exact steps that won't waste time and will get you there faster? Let me share what I think might be helpful.
You know what thread safety is, right? If not, there is a simple example below. All classes must be thread-safe, right? Not really. Some of them have to be thread-safe? Wrong again. I think none of them have to be thread-safe, while all of them have to provide synchronized decorators.
In outsourcing, very often a customer is an idiot doesn't really know what he needs—not only in terms of functionality, but also on a technical level. What makes the situation even worse is that the customer very often always thinks he knows and understands enough. The question is how do you teach a customer? How do you train, educate, and help him? You don't!