Это нежесткое ограничение. Мы каждый проект будем рассматривать индивидуально. Но если у проекта очень много звезд уже давно и у него до сих пор нет спонсора, то может быть стоит задуматься о его реальной ценности?
А Вы попробуйте и все поймете. Сделайте fork, сделайте pull request, добейтесь того, чтобы его приняли. И так раз 100. И возвращайтесь сюда с рассказом о том, как это было легко и ничего нового Вы в этом не нашли. А мы послушаем.
Вам может понравиться вот это выступление, где я анализировал разные определения объекта, от разных авторов. Если кратко, то называть объект «сервером» или «компьютером» мне кажется неправильным.
Нет, у меня нет такой идеи. Я не считаю, что все должны быть объектами. Я считаю, что объекты должны быть объектами, а не структурами данных. Вот про мое отношение к объектам.
Я не могу найти откуда первое высказывание и кто такой Scott McKay. Нашел только вот это. А вообще, если есть хорошие мысли о вреде ООП, пожалуйста пришлите, у меня вот коллекция есть.
Вы совершенно правы, у этого подхода очень мало отличий от FP, однако (это цитата из второго тома «Elegant Object»):
We do understand objects well, simply because they are real world entities and exist around of us. The function fibo(7) is exactly as understandable as the object Fibo(7), but objects are more convenient, because they take responsibility to know, what they are. A function lives within the confines of one statement and gives us a result as a successor. Probably a dumb one, which delegates a responsibility on knowing, what it is, to a programmer. This information gets lost in the code as soon as you leave a place of calling the function. In other words, an integer returned from fibo(7) cannot print itself as «Fibonacci number #7: 13» or find the subsequent Fibonacci number. An object (and an object composition) can be instantiated, passed to some function and expose its behaviour somewhere else. It has its own lifecycle, can be asked for its behaviour many times and knows exactly, what it is. Also, in some languages object interactions are way easier to test, thanks to interfaces and fake objects. I can’t remember a language, which allows to define such a separated schema for a function.
Android SDK рекомендует использовать статические методы и не использовать объекты. Стоит ли эту рекомендацию принимать как правильный стиль в ООП? Не будет ли правильнее считать частный конкретный случай просто временным затруднением аппаратной части? То же самое и у нас. Да, Java не умеет работать быстро с большим числом объектов. Она куда быстрее работает со статическими методами. Это беда Java, а не ООП. Придет время и место Java займет другая платформа, где ООП сможет работать правильно и красиво. И там не будет статических методов. Я предлагаю подумать об этой платформе уже сейчас. А еще почитайте вот это.
Книжку можно купить на территории РФ, Украины, Беларуси и ближайшего зарубежья минуя Амазон. Нужно написать емейл на shop@yegor256.com.
We do understand objects well, simply because they are real world entities and exist around of us. The function fibo(7) is exactly as understandable as the object Fibo(7), but objects are more convenient, because they take responsibility to know, what they are. A function lives within the confines of one statement and gives us a result as a successor. Probably a dumb one, which delegates a responsibility on knowing, what it is, to a programmer. This information gets lost in the code as soon as you leave a place of calling the function. In other words, an integer returned from fibo(7) cannot print itself as «Fibonacci number #7: 13» or find the subsequent Fibonacci number. An object (and an object composition) can be instantiated, passed to some function and expose its behaviour somewhere else. It has its own lifecycle, can be asked for its behaviour many times and knows exactly, what it is. Also, in some languages object interactions are way easier to test, thanks to interfaces and fake objects. I can’t remember a language, which allows to define such a separated schema for a function.