Ten things I can't stand in OOP
God, at times I just hate object-oriented programming.
I guess I'm not the only one. Edsger Dijkstra's immortal words read:
I usually don’t complain, but now I think it's time to look back and see what’s wrong with the PLO. In this spirit, I prepared a modest list of ten things that I can not stand in the PLO.
What is the paradigm of object-oriented programming? Is there a direct answer to this? I heard so many different versions that I myself do not know now.
')
If we look at Smalltalk's ideas, we will encounter the mantra: “Everything is an object”. In addition to variables. And packages. And primitives. Numbers and classes are also not exactly objects, and so on. Obviously, “everything is an object” cannot be the basis of a paradigm.
What is fundamental to OOP? Peter Wegner once suggested that object-based programming is based on objects, classes, and inheritance . However, each programming language supports them differently, or does not even support some of them by default. Clearly, this is also not the paradigm of the PLO.
Others assert that OOP is Encapsulation, Abstraction, and Data Hiding . True, different sources will tell you that these are just different words to describe the same idea. But others will say that these are three fundamentally different concepts.
Since the mid-80s, several myths have been walking about OOP. One of them, the Reuse Myth , says that OOP makes development more productive, so it allows you to inherit and extend the current code instead of writing it again each time. Another is the Design Myth, which implies that analysis, design, and implementation smoothly follow from each other, because all of them are objects . Of course, none of these myths can be the paradigm of the PLO.
Let's take a look at other paradigms that allow solving programmer tasks in a certain way. Procedural programming is often described as programs = data + algorithms . Logical programming says: programs = facts + rules . Functional programming, apparently, programs = functions + functions . This suggests that OOP means programs = objects + messages . Is it so? I think that the main thing is lost here. And the main thing is that OOP is not a paradigm, such as procedural, logical or functional programming. Instead, the PLO says: “for each individual task you must develop your own paradigm”. In other words, the paradigm of object-oriented design is: “Programming is modeling”.
I also do not like the way everyone likes not to like other people's languages. We like to divide the world into camps: braces versus square versus round ones.
Here are some things that were said about our beloved SADN:
And perhaps the most comprehensive sentence:
Classes drive me crazy. This may seem strange, so let me explain.
Classes seem to be convenient. Our brain perfectly classifies the information we receive from the outside world. And it would be quite natural to classify everything in object-oriented programs.
However, in the real world there are only objects. Classes exist only in our mind. Can you give at least one example from the real world that a class is a real, physical entity? No I do not think so.
And that's the problem. Have you ever wondered why an object-oriented language program is so much more difficult to understand than a procedural one?
In procedural programs, procedures call other procedures. The procedural code shows ... procedures that call other procedures. Everything is good and simple, right?
In object-oriented programs, objects send messages to other objects. Object-oriented code shows ... classes that inherit other classes. Oh. It seems that in OOP there is no connection between the source code and the executable program. Our tools help us badly: IDEs show classes, not objects.
I think this is why SmallTalkers like to program in debugger so much: the latter gives them a sense of control over the executable objects and allows them to be programmed directly.
This is what I would like to say to the developers of the tools: please give us an IDE that will display objects instead of classes!
Honestly, I also hate methods.
As we all understand, methods in good object-oriented programs should be short and elegant. Many small methods are more convenient for development, understanding, reuse, and so on. So what's the problem?
We take into account the fact that we spend more time reading object-oriented code than writing it. This is called performance: instead of spending hours writing a large amount of code, in order to add new functionality, we write only a few lines, but at the same time spend hours trying to figure out exactly which lines you need to write!
One of the reasons why we spend so much time is because we have to scroll the code back and forth ... through a lot of small methods.
This is also known as the Lost in Space syndrome and has been spoken of since the creation of the PLO. To quote Adel Goldberg, “In SmallTalk, everything happens somewhere else.”
I’m sure that today's code-oriented IDEs are to blame for this - given that object-oriented code doesn’t give any idea of the executable application, the IDE stands in our way instead of helping. Another reason why SmallTalkers like to program in the debugger is that it helps them see well what objects they interact with. Therefore, I think today test-driven development (TDD) is popular, allowing you to see the interaction of objects during development.
And the matter is not in the PLO itself - we just did not understand (after more than 40 years) how to develop programs for it. We have to ask ourselves: why does the source code remain the predominant mapping in the IDE?
I want an IDE that will allow me to switch between code and executable application. (For an idea of this idea, take a look at the Seaside web development platform site, which allows you to switch directly from the executable application to the editable source code)
Okay, I admit: I am impatient and hate repeating words twice. Types make me do it.
Someone now probably thought: “But how can you write in a typeless language. You will never be sure that your code is correct. ”
Of course, there are no “typeless” languages - they exist statically and dynamically typed. Statically typed interfere with writing code in some cases. In principle, there is nothing wrong with that.
The problem with the types themselves, as we know them. First, they give rise to a sense of false security. The fact that your Java program is compiled does not mean that there are no errors in it (and even type errors).
Secondly and most importantly, typification assumes that the world is constant, and the programs in it consist of unchanged parts, and this is not so . Because of this, some useful types of programs (especially reflexive) become more difficult to write.
Finally, typing does not do well with the fact that there are different notions of types . There is no one omnipotent system. Recall the suffering we experienced with generalizations in Java. Many useful type systems are being developed, but we cannot extend Java to fit them all. Gilad Brakha proposed to make the typing not only optional to run programs even if the typing is incorrect, but also plug-in , so that we can connect different type systems in different parts of our programs. We need to think about this proposal, and at the same time how to adapt programming languages and development environments to a variety of type systems.
We all don't like to change, right? And if so, why complain if things do not get better? We know that useful programs must change, or they deteriorate over time.
(By the way, do you know what the difference is between hardware and software? Iron worsens if you don’t keep it working.)
Given that real programs must change, it is fair to assume that languages and IDEs should support this. I suggest you, however, to name at least one mechanism in programming languages that supports variability. Those mechanisms that work with variability rather limit and control it.
Our world is impermanent, but we feel good in it. The context is what allows us to cope with change. We adjust our behavior, our expectations to the context in which we are, but for some reason our programs break down if the context changes.
I want to see this idea in object-oriented languages and IDE. Both the source code and the executable application must be able to adapt to the changing context. I am sure that many design patterns and ideas (such as a visitor and dependency injection ) are just crutches that will disappear after the implementation of the context mechanism in the SNMP.
Patterns. I can not with them, I can not without them.
Each design pattern makes your project more confusing.
I said everything.
It seems that some of my students are working on the Chile Norris style Agile methodology:
“Chuck Norris is not engaged in iterative development. Everything works out the first time, every time. ”
“Chuck Norris does not write documentation. He stares at the code until he says everything he needs to know. ”
Bertrand Meyer talks about what surprised him about why schematic programming languages were always so popular, until one day it dawned on him: “The bubbles do not break!” . (Another saying belonging to Meyer: “All you need is code” )
It seems that with what is usually understood by development through modeling, something is also wrong: the code should not be generated from the model - the model should be code .
By the way, FORTRAN was sold as a high-level language from which source code was generated. And now the high-level language for us is the source code.
I hope one day when we grow up, the model will be considered as source code.
And finally, the catchphrase I hate: “Objects are not enough. Need more ... ” . All these years we needed frameworks, components, aspects, services (which, it seems, in a curious way brought us back to procedural programming!)
If there have never been enough objects, why have they served us well all these years?
25 years ago, we did not expect the “new” phenomenon of the PLO to live so long.
We thought that OO-conferences such as ECOOP , OOPSLA will exist for 5 years and then get lost in the mainstream.
But it is too early to ignore OOP as part of the mainstream. And the fact that scientific and industrial research in the field of object-oriented programming is still ongoing suggests that something important is happening that we do not fully understand.
OOP allows you to simplify complex things through modeling, but we still haven't mastered it , perhaps because we can hardly distinguish between significant and insignificant difficulties.
To move on, we need to focus on volatility and how OOP can contribute to volatility. After so many years, we are still at the very beginning, trying to understand what the PLO can offer us.
Thanks for reading!
Little about the author
Oscar Nierstrasz is a professor of Computer Science at the University of Bern, founder of the Software Composition Group , which explores the mechanisms that allow computer systems to be more flexible and better adapted to changing conditions. (hence the author’s desire to introduce the mechanisms of variability in PL)
An active participant in the PLO research community, participant and chairman of conferences such as ECOOP , ESEC and MODELS . (This article is just the speech of Oscar at the ECOOP 2010 conference). Also chief editor of The Journal of Object Technology .
He co-authored over 200 publications and 2 books: Object-Oriented Reengineering Patterns and Pharo by Example . (both books, apparently, are not translated into Russian, but free and available for download at the links)
I guess I'm not the only one. Edsger Dijkstra's immortal words read:
“Object-oriented programming is an extremely bad idea that only California could think of.”
I usually don’t complain, but now I think it's time to look back and see what’s wrong with the PLO. In this spirit, I prepared a modest list of ten things that I can not stand in the PLO.
1. The paradigm
What is the paradigm of object-oriented programming? Is there a direct answer to this? I heard so many different versions that I myself do not know now.
')
If we look at Smalltalk's ideas, we will encounter the mantra: “Everything is an object”. In addition to variables. And packages. And primitives. Numbers and classes are also not exactly objects, and so on. Obviously, “everything is an object” cannot be the basis of a paradigm.
What is fundamental to OOP? Peter Wegner once suggested that object-based programming is based on objects, classes, and inheritance . However, each programming language supports them differently, or does not even support some of them by default. Clearly, this is also not the paradigm of the PLO.
Others assert that OOP is Encapsulation, Abstraction, and Data Hiding . True, different sources will tell you that these are just different words to describe the same idea. But others will say that these are three fundamentally different concepts.
Since the mid-80s, several myths have been walking about OOP. One of them, the Reuse Myth , says that OOP makes development more productive, so it allows you to inherit and extend the current code instead of writing it again each time. Another is the Design Myth, which implies that analysis, design, and implementation smoothly follow from each other, because all of them are objects . Of course, none of these myths can be the paradigm of the PLO.
Let's take a look at other paradigms that allow solving programmer tasks in a certain way. Procedural programming is often described as programs = data + algorithms . Logical programming says: programs = facts + rules . Functional programming, apparently, programs = functions + functions . This suggests that OOP means programs = objects + messages . Is it so? I think that the main thing is lost here. And the main thing is that OOP is not a paradigm, such as procedural, logical or functional programming. Instead, the PLO says: “for each individual task you must develop your own paradigm”. In other words, the paradigm of object-oriented design is: “Programming is modeling”.
2. Object-oriented programming languages
I also do not like the way everyone likes not to like other people's languages. We like to divide the world into camps: braces versus square versus round ones.
Here are some things that were said about our beloved SADN:
“C makes it easy to shoot yourself in the foot; with C ++, it's harder to do, but when you do, you shoot your whole leg. ”That said Bjorn Straustrup, so all is well.
“I came up with the term 'object-oriented', and here’s what I’ll tell you: I didn’t mean C ++.” - Alan Kay.
“In C ++, only 2 things turned out wrong: the initial design and implementation.” - Bertrand Meyer
“Inside C ++, there is a more compact and understandable language that is desperately trying to get out.” - Bjorn Straustrup
“C ++ is a story repeated like a tragedy. Java is a story repeated like a farce. ” - Scott McKay
“Java, the best argument for SmallTalk after C ++.” - Frank Winkler
“If Java had a real garbage collector, most programs would remove themselves during execution.” - Robert Suel
And perhaps the most comprehensive sentence:
“There are only 2 types of languages: those that everyone complains about and those that nobody uses.” - Bjorn Straustrup
3. Classes
Classes drive me crazy. This may seem strange, so let me explain.
Classes seem to be convenient. Our brain perfectly classifies the information we receive from the outside world. And it would be quite natural to classify everything in object-oriented programs.
However, in the real world there are only objects. Classes exist only in our mind. Can you give at least one example from the real world that a class is a real, physical entity? No I do not think so.
And that's the problem. Have you ever wondered why an object-oriented language program is so much more difficult to understand than a procedural one?
In procedural programs, procedures call other procedures. The procedural code shows ... procedures that call other procedures. Everything is good and simple, right?
In object-oriented programs, objects send messages to other objects. Object-oriented code shows ... classes that inherit other classes. Oh. It seems that in OOP there is no connection between the source code and the executable program. Our tools help us badly: IDEs show classes, not objects.
I think this is why SmallTalkers like to program in debugger so much: the latter gives them a sense of control over the executable objects and allows them to be programmed directly.
This is what I would like to say to the developers of the tools: please give us an IDE that will display objects instead of classes!
4. Methods
Honestly, I also hate methods.
As we all understand, methods in good object-oriented programs should be short and elegant. Many small methods are more convenient for development, understanding, reuse, and so on. So what's the problem?
We take into account the fact that we spend more time reading object-oriented code than writing it. This is called performance: instead of spending hours writing a large amount of code, in order to add new functionality, we write only a few lines, but at the same time spend hours trying to figure out exactly which lines you need to write!
One of the reasons why we spend so much time is because we have to scroll the code back and forth ... through a lot of small methods.
This is also known as the Lost in Space syndrome and has been spoken of since the creation of the PLO. To quote Adel Goldberg, “In SmallTalk, everything happens somewhere else.”
I’m sure that today's code-oriented IDEs are to blame for this - given that object-oriented code doesn’t give any idea of the executable application, the IDE stands in our way instead of helping. Another reason why SmallTalkers like to program in the debugger is that it helps them see well what objects they interact with. Therefore, I think today test-driven development (TDD) is popular, allowing you to see the interaction of objects during development.
And the matter is not in the PLO itself - we just did not understand (after more than 40 years) how to develop programs for it. We have to ask ourselves: why does the source code remain the predominant mapping in the IDE?
I want an IDE that will allow me to switch between code and executable application. (For an idea of this idea, take a look at the Seaside web development platform site, which allows you to switch directly from the executable application to the editable source code)
5. Types
Okay, I admit: I am impatient and hate repeating words twice. Types make me do it.
Someone now probably thought: “But how can you write in a typeless language. You will never be sure that your code is correct. ”
Of course, there are no “typeless” languages - they exist statically and dynamically typed. Statically typed interfere with writing code in some cases. In principle, there is nothing wrong with that.
The problem with the types themselves, as we know them. First, they give rise to a sense of false security. The fact that your Java program is compiled does not mean that there are no errors in it (and even type errors).
Secondly and most importantly, typification assumes that the world is constant, and the programs in it consist of unchanged parts, and this is not so . Because of this, some useful types of programs (especially reflexive) become more difficult to write.
Finally, typing does not do well with the fact that there are different notions of types . There is no one omnipotent system. Recall the suffering we experienced with generalizations in Java. Many useful type systems are being developed, but we cannot extend Java to fit them all. Gilad Brakha proposed to make the typing not only optional to run programs even if the typing is incorrect, but also plug-in , so that we can connect different type systems in different parts of our programs. We need to think about this proposal, and at the same time how to adapt programming languages and development environments to a variety of type systems.
6. Variability
“Change is inevitable - unlike the little things from a vending machine.” - Robert Galaguer
We all don't like to change, right? And if so, why complain if things do not get better? We know that useful programs must change, or they deteriorate over time.
(By the way, do you know what the difference is between hardware and software? Iron worsens if you don’t keep it working.)
Given that real programs must change, it is fair to assume that languages and IDEs should support this. I suggest you, however, to name at least one mechanism in programming languages that supports variability. Those mechanisms that work with variability rather limit and control it.
Our world is impermanent, but we feel good in it. The context is what allows us to cope with change. We adjust our behavior, our expectations to the context in which we are, but for some reason our programs break down if the context changes.
I want to see this idea in object-oriented languages and IDE. Both the source code and the executable application must be able to adapt to the changing context. I am sure that many design patterns and ideas (such as a visitor and dependency injection ) are just crutches that will disappear after the implementation of the context mechanism in the SNMP.
7. Design Patterns
Patterns. I can not with them, I can not without them.
Each design pattern makes your project more confusing.
I said everything.
8. Methodologies
“All methodologies are based on fear.” - Kent Beck
It seems that some of my students are working on the Chile Norris style Agile methodology:
“Chuck Norris is not engaged in iterative development. Everything works out the first time, every time. ”
“Chuck Norris does not write documentation. He stares at the code until he says everything he needs to know. ”
9. UML
Bertrand Meyer talks about what surprised him about why schematic programming languages were always so popular, until one day it dawned on him: “The bubbles do not break!” . (Another saying belonging to Meyer: “All you need is code” )
It seems that with what is usually understood by development through modeling, something is also wrong: the code should not be generated from the model - the model should be code .
By the way, FORTRAN was sold as a high-level language from which source code was generated. And now the high-level language for us is the source code.
I hope one day when we grow up, the model will be considered as source code.
10. Another new thing
And finally, the catchphrase I hate: “Objects are not enough. Need more ... ” . All these years we needed frameworks, components, aspects, services (which, it seems, in a curious way brought us back to procedural programming!)
If there have never been enough objects, why have they served us well all these years?
Conclusion?
25 years ago, we did not expect the “new” phenomenon of the PLO to live so long.
We thought that OO-conferences such as ECOOP , OOPSLA will exist for 5 years and then get lost in the mainstream.
But it is too early to ignore OOP as part of the mainstream. And the fact that scientific and industrial research in the field of object-oriented programming is still ongoing suggests that something important is happening that we do not fully understand.
OOP allows you to simplify complex things through modeling, but we still haven't mastered it , perhaps because we can hardly distinguish between significant and insignificant difficulties.
To move on, we need to focus on volatility and how OOP can contribute to volatility. After so many years, we are still at the very beginning, trying to understand what the PLO can offer us.
Thanks for reading!
Little about the author
Oscar Nierstrasz is a professor of Computer Science at the University of Bern, founder of the Software Composition Group , which explores the mechanisms that allow computer systems to be more flexible and better adapted to changing conditions. (hence the author’s desire to introduce the mechanisms of variability in PL) An active participant in the PLO research community, participant and chairman of conferences such as ECOOP , ESEC and MODELS . (This article is just the speech of Oscar at the ECOOP 2010 conference). Also chief editor of The Journal of Object Technology .
He co-authored over 200 publications and 2 books: Object-Oriented Reengineering Patterns and Pharo by Example . (both books, apparently, are not translated into Russian, but free and available for download at the links)
Source: https://habr.com/ru/post/169601/
All Articles