Lecture
Это окончание невероятной информации про недостатки ооп.
...
,
Java is the most annoying thing that has happened to computers since MS-DOS.
Alan Kay , inventor of object-oriented programming
Alan Kay , inventor of OOP
Alan Kay coined the term "object-oriented programming" in the 1960s. He had experience in biology and tried to get computer programs to communicate like living cells. The main idea was for independent programs (cells) to communicate by sending messages to each other. The state of independent programs would never open to the external environment (encapsulation). Here it is. OOP has never been intended for inheritance, polymorphism, the new keyword, and many design patterns.
“In C ++, only 2 things went wrong: the initial design and implementation.” - Bertrand Meyer
“Inside C ++ sits a more compact and understandable language, desperately trying to get out.” - Björn Straustrup
“C ++ is a story repeating itself as a tragedy. Java is a story repeating itself as farce. ” - Scott Mackay
“Java, the best argument for SmallTalk after C ++.” - Frank Winkler
Thanks to object-oriented programming languages, computer software is becoming more verbose, less readable, less visual and more difficult to modify and maintain.
Richard Mansfield
The most important aspect of software development is to reduce code complexity. None of the features matter if the code base becomes impossible to maintain. In this case, even one hundred percent test coverage does not cost anything.
What makes the code base complex? There are many things to watch out for. In my opinion, the main reasons are: general mutable state, erroneous abstractions and low signal-to-noise ratio (boilerplate). All of them are common in OOP.
“If Java had a real garbage collector, most programs would delete themselves at runtime.” - Robert Sewell
C ++ is a terrible [object-oriented] language ... Limiting your project to C means that people will not screw up with any idiotic "object model".
Linus Torvalds , creator of Linux
Linus Torvalds is widely known for his open criticism of C ++ and OOP. One thing in which he was 100% right was the need to limit programmers to choose. In fact, the less choice programmers have, the more stable their code becomes. In the quote above, Torvalds strongly recommends having a good framework on which your code will be based.
Many do not like the speed limits on the roads, but they are necessary to prevent people from breaking to death. Similarly, a good programming environment should provide mechanisms that prevent you from doing stupid things. A good environment helps write reliable code. First of all, this should help reduce complexity by providing the following things:
OOP provides developers with too many tools and options without the right restrictions. Despite OOP promises to consider modularity and improve reusability, it does not fulfill its promises (more on this later). OOP code encourages the use of a shared mutable state, which may be unsafe from time to time. OOP usually requires a large amount of boilerplate (low signal to noise ratio).
I think that large object-oriented programs struggle with complexity, which increases with the construction of a large graph of mutable objects. You see, this is how to try to understand and keep in mind what will happen when the method is called and what the side effects will be.
Rich Hickey , creator of Clojure
The condition itself is pretty harmless. But a volatile state is a big threat to stability. Especially if you distribute it. What exactly is a volatile state? Any state that may change: variables or fields in OOP.
Consider an example from the real world. You have a blank piece of paper, you write a note on it. As a result, you get the same piece in a different state (text). You actually changed his condition. This is quite normal in the real world, since no one cares about this piece of paper. If only this is not the original painting "Mona Lisa."
And perhaps the most comprehensive sentence:
“There are only 2 types of languages: those that everyone complains about and those that no one uses.” - Björn Straustrup
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 world around us. And it would be natural to classify everything in object-oriented programs.
However, in the real world there are only objects. Classes exist only in our minds. 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 here is the problem. Have you ever wondered why a program in an object-oriented language is so much more difficult to understand than a procedural one?
In procedural programs, procedures call other procedures. The procedural code shows ... procedures that invoke other procedures. Everything is fine and simple, right?
In object-oriented programs, objects send messages to other objects. Object-oriented code shows ... classes that inherit from other classes. Oh. In OOP, there seems to be no connection between the source code and the executable program. Our tools do not help us well: IDEs show classes, not objects.
I think that’s why SmallTalkers love programming in the debugger so much: the latter gives them a sense of control over executable objects and allows them to be programmed directly.
Here is what I would like to say to the tool developers: please give us an IDE that will show objects instead of classes!
Methods or properties that provide access to certain fields are no better than directly changing the value of a field. It does not matter if you change the state of the object using an unusual property or method, the result is the same - the changed state.
Honestly, I also hate methods.
There are no methods in the real world. Does the sheet of paper you are writing on have a “recording” method? Not. You just take an empty sheet of paper, take a pen and write the text. You, as a person, also do not have a “recording” method - you decide to write some text based on external events or your internal thoughts.
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 is the problem?
We will take into account the fact that we spend more time reading object-oriented code than writing it. This is called performance: instead of writing a large amount of code for hours to add new functionality, we write only a few lines, but at the same time trying to figure out exactly which lines you need to write!
One of the reasons we spend so much time is that we have to flip code back and forth ... through a lot of small methods.
This is also known as syndrome.Lost in space and this has been said since the creation of the PLO. Quoting Adele Goldberg, “In SmallTalk, everything happens elsewhere.”
I’m sure that today's code-based IDEs are to blame for this - given that the object-oriented code does not give an idea about the executable application, the IDE stands in our way instead of helping. Another reason SmallTalkers are so fond of programming in the debugger is that it helps them to see clearly which objects interact with which . Therefore, I think, development through testing (test-driven development, TDD) , which allows you to see the interaction of objects during development , is popular today .
And the point is not OOP itself - we just have not yet understood (after more than 40 years) how to develop programs for it. We must ask ourselves: why does the source code remain the predominant mapping in the IDE?
I want an IDE that allows me to switch between code and an executable application. (To get an idea of this idea, check out the Seaside web development platform website, which allows you to switch directly from an executable application to 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, “typeless” languages do not exist — they exist statically and dynamically typed. Statically typed ones prevent you from writing code in some cases. In principle, there is nothing wrong with that.
The problem is with the types themselves, as we know them. First, they give lead to a sense of false security. Just because your Java program is compiling does not mean that there are no errors (and even errors with types) in it.
Secondly and chiefly, typing assumes that the world is constant, and the programs in it consist of constant parts, but this is not so.. Because of this, some useful types of programs (especially reflective) become harder to write.
Finally, typing does not get along well with the fact that there are different types of concepts . There is no one omnipotent system. Recall the suffering we experienced with Java generalizations. Many useful type systems are being developed now, but we cannot extend Java to fit them all. Gilad Braha suggested making typing not only optional so that programs can be launched even if typing is incorrect, but also plugin, so that we can connect different type systems in different parts of our programs. We should think about this proposal, and at the same time how to adapt programming languages and development environments to various type systems.
“Change is inevitable - unlike little things from a vending machine.” - Robert Galager
We all don't like to change, right? And if so, then why complain if things don't get better? We know that useful programs must change, or they will get worse over time.
(By the way, do you know what the difference between hardware and software is? Hardware worsens if you don't keep it working.)
Given that real programs should change, it is fair to assume that languages and IDEs should support this. I suggest you, however, name at least one mechanism in programming languages that supports variability. Those mechanisms that work with volatility are more likely to limit and control it.
Our world is fickle, but we feel good about it. Context- this 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 if the context changes.
I want to see this idea in object oriented languages and IDEs. Both the source code and the executable application must be able to adapt to a changing context. I am sure that many design patterns and ideas (such as the visitor and the implementation of addiction) are just crutches that will disappear after the implementation of the context mechanism in the NLO.
Some argue that mutable state is the decision of developers in OOP, not a given. But this is not so. This is not the choice of developers, but almost the only option. Yes, immutable objects can be passed to Java / C # methods. But this is rarely done, since most developers use data modification by default. Even if developers try to use immutability in their OOP programs, languages do not provide built-in mechanisms for immutability and for working effectively with immutable data (i.e., persistent data structures).
You can make objects communicate only by transmitting immutable messages and never transmit any links (which is actually a rarity). Such programs will be more reliable than the main ones in OOP. But objects still need to change their own state after receiving a message. Communication is a side effect and its sole purpose is to bring about change. Messages would be useless if they could not change the state of other objects.
Cannot use OOP without causing a state change
Patterns I can’t with them, I can’t live without them.
Each design pattern makes your project more confusing.
OOP provides a set of recommendations that theoretically should allow developers to gradually grow larger and larger systems: the SOLID principle, dependency injection, design patterns, etc. Unfortunately, design patterns are nothing more than crutches. They exist solely to address the shortcomings of OOP. Many books have been written on this subject. And they would not be so bad if they did not introduce enormous complexity into the codebases.
Although easily changing the code to a well-known pattern can simplify the understanding of the code, according to Steve McConnell, there are two difficulties that can be associated with using patterns. Firstly, blindly following some chosen pattern can complicate the program. Secondly, the developer may want to try some pattern in business without any special reason. [2]
Many design patterns in object-oriented design can be considered as idiomatic reproduction of elements of functional languages [3]. Peter Norvig claims that 16 out of 23 patterns described in the book “Gangs of Four” in dynamically typed languages are implemented much easier than in C ++, or they are invisible [4]. Paul Graham considers the very idea of design patterns to be an antipattern, a signal that the system does not have a sufficient level of abstraction, and its thorough processing is necessary [5]. It is easy to see that the very definition of a template as “a ready-made solution, but not a direct appeal to the library ” essentially means refusing reuse in favor of duplication. This can obviously be inevitable.for complex systems when using languages that do not support combinators and type polymorphism, and this can in principle be excluded in languages that have the property of homo-conicity (although not necessarily effective), since any template can be implemented as executable code
It is virtually impossible to write good and maintained object-oriented code.
On one side of the spectrum there is a code base that is inconsistent and does not adhere to any standards. On the other side there is a tower with overly constructed code, a bunch of erroneous abstractions built one on top of the other. Design patterns are very helpful in building such towers of abstractions.
Soon, adding new functionality and even understanding the complexity is getting harder and harder. The codebase will be full of things like SimpleBeanFactoryAwareAspectInstanceFactory, AbstractInterceptorDrivenBeanDefinitionDecorator, TransactionAwarePersistenceManagerFactoryProxy or RequestProcessorFactoryFactory.
We need to spend precious intellectual resources trying to understand the tower of abstractions that the developers themselves created. Lack of structure is in many cases better than poor structure.
Figure 6 Perfect pre-salting and real OOP implementation
“All methodologies are based on fear.” - Kent Back
It looks like some of my students are working on Agile methodology in the style of Chuck Norris:
“Chuck Norris is not iterative. Everything comes out the first time, every time. ”
“Chuck Norris is not writing documentation. He looks at the code until it says everything you need to know. ”
Bertrand Meyer talks about how he was surprised at why schematic programming languages were always so popular until one day it dawned on him: “Bubbles don't break!” . (Another statement by Meyer: “All you need is code” )
It seems that with what is usually understood as development through modeling, something is also wrong: the code should not be generated from the model — the model should be code .
Incidentally, FORTRAN was marketed as a high-level language from which source code was generated . And now for us a high-level language is the source code.
I hope one day when we grow up, the model will be considered considered source code.
And finally, the catchphrase, which sounds very clever: “Objects are not enough. We need more ... " .
All these years, we needed frameworks, components, aspects, services (which, it seems, curiously brought us back to procedural programming!)
If there were never enough objects , why did they serve us properly all these years?
Automated testing is an important part of the development process and helps a lot in preventing regressions (errors introduced into existing code). Unit testing plays a huge role in the process of automatic testing.
Some may disagree, but OOP is notoriously difficult for unit testing. Unit testing involves isolation, and to create a method for this type of testing, you need to:
How many more hurdles do you need to overcome to make a piece of code testable? How much time was wasted? In addition, you need to instantiate the entire class to test one method. This will pull the code from all of its parent classes. With OOP, writing tests for legacy code is even more difficult, almost impossible. Entire companies were created (TypeMock) due to the problem of testing legacy code.
The boilerplate code is the biggest problem when it comes to signal to noise ratio. Template code is the noise for compiling a program. Such code takes time to write and makes the code base less readable.
Although OOP promotes a “program for an interface, not an implementation,” not everything should become an interface. We should resort to using interfaces in the entire code base for the sole purpose of testing. You would also probably have to use dependency injection, which would subsequently lead to unnecessary complexity.
Some argue that private methods should not be tested. I am inclined to disagree, unit testing is called “unit testing,” since small, isolated blocks of code are tested. However, testing private methods in OOP is almost impossible. Private methods should not be made internal just for testing.
To achieve testability of private methods, they are usually extracted into a separate object. This, in turn, introduces unnecessary complexity and boilerplate code.
Refactoring is an important part of the development work. Ironically, the OOP code is difficult to reorganize. Refactoring should make the code less complicated and more understandable. In contrast, reorganized code in OOP becomes significantly more complex. To make code testable, you need to use dependency injection and create an interface for the reorganized class. And even then, OOP code refactoring is complicated without special tools like Resharper.
// Before refactoring:
public class CalculatorForm {
private string aText, bText;
private bool IsValidInput (string text) => true;
private void btnAddClick (object sender, EventArgs e) {
if (! IsValidInput (bText) ||! IsValidInput (aText)) {
return
}
}
}
// After refactoring:
public class CalculatorForm {
private string aText, bText;
private readonly IInputValidator _inputValidator;
public CalculatorForm (IInputValidator inputValidator) {
_inputValidator = inputValidator;
}
private void btnAddClick (object sender, EventArgs e) {
if (! _inputValidator.IsValidInput (bText)
|| ! _inputValidator.IsValidInput (aText)) {
return
}
}
}
public interface IInputValidator {
bool IsValidInput (string text);
}
public class InputValidator: IInputValidator {
public bool IsValidInput (string text) => true;
}
public class InputValidatorFactory {
public IInputValidator CreateInputValidator () => new InputValidator ();
}
In this simple example, the number of rows more than doubled only to retrieve one method. Why does refactoring create even more complexity when the code is refactored, which is needed primarily to reduce complexity?
Compare this with similar non-OOP refactoring in JavaScript:
// Before refactoring:
// calculator.js:
const isValidInput = text => true;
const btnAddClick = (aText, bText) => {
if (! isValidInput (aText) ||! isValidInput (bText)) {
return
}
}
// After refactoring:
// inputValidator.js:
export const isValidInput = text => true;
// calculator.js:
import {isValidInput} from './inputValidator';
const btnAddClick = (aText, bText, _isValidInput = isValidInput) => {
if (! _isValidInput (aText) ||! _isValidInput (bText)) {
return
}
}
The code literally remains the same. The isValidInput () function simply moved to another file and one line was added to import this function. _IsValidInput () has also been added to the function signature for ease of testing.
This is a simple example, but in practice, the complexity of the OOP code increases exponentially as the code base grows. And that is not all. OOP code refactoring is extremely risky. Sophisticated dependency and state graphs scattered throughout the OOP code base do not allow the human brain to consider all potential problems.
I don’t think there is a “silver bullet”, so I’ll just describe how it usually works in my code today.
In short, some technological ekletkita and a reasonable combination of all software development methodologies are used.
First of all, I study the data and talk very well with the customer. Since we are not writing a code, we are solving a certain problem of the customer. So first you need to use OOA (object-oriented analysis). I analyze what comes to the input and the outputs, the data format, their volume. I figure out how the data should be stored at runtime and how it is stored: what operations should be supported and at what speed (processing speed, delay), etc. I create a conceptual database model in a combination of short and clear CRUD matrix + Use case UML.
Usually if the data is significant, my structure is close to the database. That is, I will have some kind of object, for example, a DataStore with an API that provides access to all the necessary operations to execute queries and save data. The data itself will be contained in the form of structures ADT / PoD ( Simple data structure (English plain old data, POD) abstract data type ( ADT), and any links between data records will be presented in the form of ID (number, uuid or deterministic hash). In terms of internal design, this usually resembles strongly or actually has support for a relational database: Vectors or HashMap store the bulk of the data by Index or ID, other structures are used as “indexes” needed to perform a quick search, and so on. Other data structures, such as LRU caches and the like, are also located here.
The main part of the program logic receives a link to such DataStore and performs the necessary operations with them. For the sake of concurrency and multithreading, I usually connect different logical components through messaging like actors. Actor example: stdin reader, input handler, trust manager, game status, etc. Such "actors" can be implemented as pools of subprocesses, elements of pipelines, etc. If necessary, they can have their own or shared with other "actors" DataStore.
This architecture gives me convenient testing points: a DataStore can have various implementations using polymorphism, and messaging instances of actors can be created separately and managed through test message sequences.
Sometimes a system shrinks just to use services, models, certain entities, views, controllers (so that each of them does not become bold).
The main idea is this: only because my software works in an area where there are concepts, for example, customers and orders, it does not necessarily have the Customer class and methods associated with it. The opposite is true: the Customer concept is just a dataset in tabular form in one or more DataStore, and the “business logic” code directly manipulates this data. and do not forget that SQL and the relational data are much more developed and time-tested than xDD.
Alternatively, you can philosophize on the topic of functional or logical programming
Now we know that OOP is an experiment that failed. It is time to move on. It is time for us, as a community, to recognize this idea as a failure and abandon it.
Lawrence Krabner
Functional programming seems complicated due to the presence of complex names of the main ideas, such as functors and monads , closures, lambda functions. Functors are something that can be transformed using a function, such as list.map. Monads are just a chain of related calculations!
Functional programming will make you a better developer. You will finally start writing code that solves the problems of the real world, instead of wasting time thinking about abstractions and design patterns.
You may not have realized yourself as a functional programmer. Do you use features in your daily work? Yes? Then you are already a functional programmer! It remains to learn how to use functions effectively.
Two good functional languages with easy learning are Elixir and Elm. They allow the developer to focus on what is really important - on writing reliable software and removing the complexity of traditional functional languages.
Alternatives? Does your organization use C #? Try F #, a cool, functional, .NET compatible language. Using Java? Then Scala and Clojure are good options for you. Using javascript? With the right guidance and linting, JavaScript turns into a good functional language.
. The immortal words of Edsger Dijkstra read:
“Object-oriented programming is an extremely bad idea that only California could come up with.”
Do not forget that programming is creative work, therefore, relate to each methodology critically, and use all the tools that are necessary to implement these tasks.
In the last century, we did not expect the “new” OOP phenomenon to live so long. We thought that OO conferences such as ECOOP, OOPSLA will last 5 years, and then get lost in the mainstream. But it’s 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, which we still do not fully understand.
Despite the fact that OOP has many drawbacks, and even methods for solving these drawbacks also have drawbacks, OOP allows us to simplify complex things through modeling, but we still have not mastered this, perhaps because we do not distinguish between significant and non-essential difficulties.
To move on, we need to focus on variability and how OOP can contribute to variability. After so many years, we are still at the very beginning, trying to understand what the PLO can offer us.
The response from the defenders of the PLO is expected. They will say that this article is full of inaccuracies. Some may even start to name names. They might even call me a junior developer without real OOP experience. Someone may say that my assumptions are wrong, and the examples are useless. It does not matter.
They have the right to their opinion. However, their arguments for defending the PLO are usually rather weak. Ironically, most of them have never programmed in this functional language. How can a comparison be made between two things if you have never tried both of them? Such comparisons are not very good.
Demeter’s law is not very useful - it does nothing to solve the problem of non-determinism. A shared mutable state is still a shared mutable state, regardless of how you access or change it. The a.total () method is not much better than a.getB (). GetC (). Total (). It just sweeps the problem under the carpet.
Subject oriented design? This is a useful development methodology; it helps a bit with complexity. But she still does nothing to solve the fundamental problem of a common mutable state.
Thus
the only solution to the problem of increasing healing, connectivity and connectedness is to reduce the number of elements and layers;
forget about the concept of optima when making architectural decisions;
Also, do not forget that we are developing a software ARCHITECTURE, and do not use a totally imperfect approach (there can NOT be an ideal approach)!
Recall what software architecture is - a collection of the most important decisions about the organization of a software system.
The architecture includes:
The Software Engineering Institute website provides over 150 definitions for this concept.
Software architecture usually contains several types that are similar to various types of drawings in building construction. In the ontology established by ANSI / IEEE 1471-2000, views are instances of a point of view where a point of view exists to describe an architecture from the point of view of a given set of interested parties.
The architectural view consists of 2 components:
Architectural types can be divided into 3 main types:
To satisfy the designed system with various quality attributes, it is reasonable to apply various architectural patterns (patterns). Each template has its own tasks and its shortcomings.
Examples of architectural patterns:
Like so much in software design, criticism of OOP is not an easy topic. Perhaps I could not clearly convey my point of view and / or convince you. But if you are interested, here are a few more links:
Dissatisfied with something? Wellcome express everything in the comments below
Часть 1 Disadvantages of OOP, DDD (Domain-driven design) and patterns. OOP Alternative
Часть 2 An alternative to OOP or what approach to use instead
Да если Рисунок 3 повернуть на 80 градусов против часовой стрелки то реально)) внизу грешные люди, пользователи, а вверху божества и ангелы, сверхвозможностями
Comments
To leave a comment
Object oriented programming
Terms: Object oriented programming