I need help. I want to find sponsors for my Software Quality Award, but don't have time and connections to do that. Would you be interested to volunteer and help me? We need more money for the award, to better motivate programmers. Please, email.
At Webinar #19 we'll discuss the role of a project manager in a software project, join us on December 7, at 11am PST.
It's time to do it! We've started work on a new programming language. Its name is EO (as in Elegant Objects or in Esperanto): eolang.org. It's open source and community driven: yegor256/eo GitHub repo. It's still in very early draft form, but the direction is more or less clear: It has to be truly object-oriented, with no compromises. You're welcome to join us.
Encapsulation is the core principle of object-oriented programming that makes objects solid, cohesive, trustworthy, etc. But what exactly is encapsulation? Does it only protect against access to private attributes from outside an object? I think it's much more. Encapsulation leads to the absence of naked data on all levels and in all forms.
Very often readers of my books ask me why I don't publish them in digital format as e-books for Amazon Kindle, EPUB, FB2, or simply PDF. There are a few reasons. It's time to summarize them all and explain why dead trees are the only way to go if you want to read my content.
Command and control has worked effectively in military units across the world for thousands of years. But apparently we've just discovered that the best companies are built on different verbs, which are inspire, delegate, trust, lead, innovate, etc. The question is whether we really uncovered something new that our predecessors failed to understand for ages or something else is going on.
I interviewed David West, the author of the Object Thinking book, a few weeks ago, and he said that classes were not meant to be in object-oriented programming at all. He actually said that earlier; I just didn't understand him then. The more I've thought about this, the more it appears obvious that we indeed do not need classes.
We all know that inheritance is bad and that composition over inheritance is a good idea, but do we really understand why? In most all articles I've found addressing this subject, authors have said that inheritance may be harmful to your code, so it's better not to use it. This "better" part is what bothers me; does it mean that sometimes inheritance makes sense? I interviewed David West (the author of Object Thinking, my favorite book about OOP) a few weeks ago, and he said that inheritance should not exist in object-oriented programming at all (full video). Maybe Dr. West is right and we should totally forget extends keyword in Java, for example.
Good objects are immutable, but not necessarily constants. I tried to explain it here, here, and here, but now it's time to make another attempt. Actually, the more I think about it, the more I realize that immutability is not black or white—there are a few more gradients; let's take a look.
Objects responsible for too many things are a problem. Because their complexity is high, they are difficult to maintain and extend. Decomposition of responsibility is what we do in order to break these overly complex objects into smaller ones. I see two types of this refactoring operation: vertical and horizontal. And I believe the former is better than the latter.