Кстати, если Вам не нравится метафора с серверами… то есть ещё более удачная: объекты — это сотрудники завода, чётко следующие должностным инструкциям. А сама программа — это завод, который на вход принимает сырьё (пользовательский ввод), а на выход даёт готовую продукцию (результат вычислений на основе ввода)
Я понял, что Вам это кажется неправильным, но не понял почему Вам так кажется… Единственный аргумент, который Вы привели, что объект-сервер возвращает управление обратно серверу-инициатору сообщения или в main-loop… если быть точнее, то возможен ещё вариант передачи управления следующему объекту-серверу (аля конвеер). Что в этом неправильного? Да и как иначе, сделать 1 единственный объект на всю программу, который никому управление не отдаст, ну ok… вот это как раз и будет процедурное программирование :-)
it is an independent entity with its own life cycle, its own behavior, and its own habits.
Я полностью согласен с таким определением объекта (впрочем, точнее было бы называть это субъектом или актором). Но вот дальнейшие примеры в статье показывают профессиональную деформацию от долгого программирования на мейнстрим-языках. Взять тот же файл, это совершенно пасивная сущность, без какого-либо собственного поведения, по сути тупо набор байтов. А XmlParser — это очевидно активная сущность, представляет она человека, читающего и интерпретирующего файл. Другими словами, любая человеческая активность может быть выражена объектом. Похожая метафора с того же OOPSLA97: «An object is a virtual server».
Таким образом, годный объект — это виртуальный сервер, обеспечивающий выполнение/автоматизацию некоторой активности, которая могла бы быть выполнена человеком, над некоторым набором данных (состояние объекта), на основании обработки входящих сообщений (аля приказы начальника, просьбы коллеги и т.п.)
Фиговые объекты сразу видно по действиям, которые описываются возвратными глаголами (с постфиксом -ся). Например, файл открывается, строка пишется, файл закрывается.
По поводу источника «Java and C++ make you think that the new ideas are like the old ones. Java is the most distressing thing to happen to computing since MS-DOS.» — это из выступления на OOPSLA97
P.S. Лично я считаю, что ООП не вредно, как средство высокоуровневого проектирования. Вред приносят попытки искусственно сделать всё объектами… Во-первых, они довольно корявы во всех мейнстрим-реализациях. Во-вторых, это не даёт никаких практических преимуществ.
Поэтому мне ближе ООП в том виде, в котором оно существует в BEAM (где в роли объектов выступают легковесные процессы, внутренняя реализация которых насквозь функциональна), а не то, что может предложить JVM.
Вам же, насколько я понял, нравится придерживаться идеи, что всё является объектами… Поэтому интересно было бы почитать Ваше мнение на тему Smalltalk.
Автоформаттер — это про читаемость кода, но совсем не про выразительность языка… К тому же не так много языков страдает от наличия конкурирующих style guides. И тут я за более мягкие решения вопроса, типа Hound CI
если я правильно понял, в Go существует из коробки эдакий менеджмент зависимостей(я про import с git репозиториев) мне эта идея тоже нравится.
Поверьте, import тупо master-ветки с git репозиториев — это далеко не лучшая затея. Я давно не следил за прогрессом Go в этой области, но по крайней мере раньше у них даже не было штатного менеджера зависимостей. А когда у вас куча зависимостей на master-ветки репозиториев — это вообще не весело. Поэтому догадайтесь что там происходило пару лет назад… Правильно! Все, кому не лень, писали свои менеджеры зависимостей, коих было не меньше десятка.
Забавно, когда пытаются что-то объяснить на примерах, оторванных от реальности… Что самое главное в практической работе с числами Фибоначчи? Главное — это возможность мемоизации! Соответвенно, объект Fibo бесполезен чуть менее, чем полностью, и на практике нужен будет единственный на всю программу объект FiboServer, который не будет повторно считать уже вычисленные числа.
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.
Ахах, т.е. заглушки — это просто, а заменить функцию в pipeline — сложно?
Впрочем, спору нет, что благодаря IoC и железной дисциплине в команде можно добиться от объектов того же уровня тестопригодности, который в любом функциональном языке присутствует by design (с нулевыми усилиями).
Обоснуйте! Каким образом по-вашему это проявляется в масштабах экосистемы?
Например, я вижу в экосистеме Go большую тягу к велосипедостроительству… Это выражается в том, что для решения одной задачи создаются порой десятки вариантов решений, т.е. отсутвует консолидация усилий…
В языках, где можно легко и быстро включиться в разработку, наоборот преобладают тенденции к созданию де-факто стандартных пакетов под каждую задачу.
Да, если я ничего не путаю, ещё в первоисточнике (PoEAA) было примечание, что Active Record нарушает SRP и не рекомендуется использовать его в случаях сложнее, чем тривиальные.
Это во многом миф, удобство чтения кода в большей мере зависит от автора кода, чем от ЯП. При этом чем выше уровень автора кода, тем бессмысленные ограничения выразительности.
Да про многие так нельзя сказать… Дальше всех к дзен продвинулись Lisp и SQL.
Кроме них, на мой взгляд, хорошо сбалансированы Ruby, Elixir, Smalltalk, F#… Да даже C# тут Java явно обходит, начиная с 3-й версии.
Это не проблемы. Это та самая неограниченная выразительность, позволяющая хотя бы теоретически писать код, который идеально отражает намерения программиста.
Ну а если код получился трудночитаемым даже на нём, то это уже «разруха в головах» (с).
Многим программистам нравится, когда выразительность искусственно ограничена, это помогает им структурировать свои мысли. Дальше всего по этому пути пошёл Go.
Это уже есть, посмотрите на Erlang или Elixir, там это процессами называется, но по сути это и есть настоящие объекты.
Я уверен, что через 20 лет все актуальные ЯП (кроме самых low-level) будут придерживаться аналогичных подходов, потому что это позволит эффективно использовать все 1024 ядра (ну или сколько тысяч их там будет к тому времени) и управлять сотнями компонентов умного дома из одной программы.
Улучшат языки, которые перестанут тянуть идею «всё есть объект» куда не надо… Объектами останутся только те части программы, которые действительно обладают своим поведением и полностью изолированы от остальной программы. Между собой они будут общаться исключительно отправкой сообщений. А само поведение объекта будет реализовываться декларативно (в функциональном и/или логическом стиле).
Не думаю, что можно выделить что-то одно. Весь язык заслоняет собой программу и чтобы увидеть смысл написанного приходится продираться через бесконечные нагромождения синтаксиса, неуместных абстракций и т.д.
Конечно, к этому можно привыкнуть и даже начать считать удобным, если достаточно долго себя в этом убеждать… только какой в этом смысл?
public int max(int a, int b) {
return new If(
new GreaterThan(a, b),
a, b
);
}
Такие примеры кода просто показывают полное непонимание сути ООП и для чего вообще нужна эта парадигма. Недавно обсуждали ООП вдоль и поперёк, начиная от самых истоков и заканчивая практической пользой в настоящем, не охота повторяться…
Вот тут дело было.
Когда нужен максимальный охват, проще взять какой-нибудь jQuery 1.9.1 с CDN, и он с большой вероятностью в кеше браузера окажется даже при первом запросе.
Таким образом, годный объект — это виртуальный сервер, обеспечивающий выполнение/автоматизацию некоторой активности, которая могла бы быть выполнена человеком, над некоторым набором данных (состояние объекта), на основании обработки входящих сообщений (аля приказы начальника, просьбы коллеги и т.п.)
Фиговые объекты сразу видно по действиям, которые описываются возвратными глаголами (с постфиксом -ся). Например, файл открывается, строка пишется, файл закрывается.
В принципе, можно у него самого уточнить…
В Вашей коллекции не хватает:
I'm sorry that I long ago coined the term «objects» for this topic because it gets many people to focus on the lesser idea. © http://c2.com/cgi/wiki?AlanKayOnMessaging
Ну и несколько статей на тему (хотя возможно Вы их уже читали):
Ten Things I Hate About Object-Oriented Programming
The Deep Insights of Alan Kay
Object Oriented Programming is an expensive disaster which must end
Fifty Questions for a Prospective Language Designer
P.S. Лично я считаю, что ООП не вредно, как средство высокоуровневого проектирования. Вред приносят попытки искусственно сделать всё объектами… Во-первых, они довольно корявы во всех мейнстрим-реализациях. Во-вторых, это не даёт никаких практических преимуществ.
Поэтому мне ближе ООП в том виде, в котором оно существует в BEAM (где в роли объектов выступают легковесные процессы, внутренняя реализация которых насквозь функциональна), а не то, что может предложить JVM.
Вам же, насколько я понял, нравится придерживаться идеи, что всё является объектами… Поэтому интересно было бы почитать Ваше мнение на тему Smalltalk.
Поверьте, import тупо master-ветки с git репозиториев — это далеко не лучшая затея. Я давно не следил за прогрессом Go в этой области, но по крайней мере раньше у них даже не было штатного менеджера зависимостей. А когда у вас куча зависимостей на master-ветки репозиториев — это вообще не весело. Поэтому догадайтесь что там происходило пару лет назад… Правильно! Все, кому не лень, писали свои менеджеры зависимостей, коих было не меньше десятка.
Ахах, т.е. заглушки — это просто, а заменить функцию в pipeline — сложно?
Впрочем, спору нет, что благодаря IoC и железной дисциплине в команде можно добиться от объектов того же уровня тестопригодности, который в любом функциональном языке присутствует by design (с нулевыми усилиями).
«C++ is history repeated as tragedy. Java is history repeated as farce.»
– Scott McKay
«Java, the best argument for Smalltalk since C++»
– Frank Winkler
Например, я вижу в экосистеме Go большую тягу к велосипедостроительству… Это выражается в том, что для решения одной задачи создаются порой десятки вариантов решений, т.е. отсутвует консолидация усилий…
В языках, где можно легко и быстро включиться в разработку, наоборот преобладают тенденции к созданию де-факто стандартных пакетов под каждую задачу.
Кроме них, на мой взгляд, хорошо сбалансированы Ruby, Elixir, Smalltalk, F#… Да даже C# тут Java явно обходит, начиная с 3-й версии.
Ну а если код получился трудночитаемым даже на нём, то это уже «разруха в головах» (с).
Многим программистам нравится, когда выразительность искусственно ограничена, это помогает им структурировать свои мысли. Дальше всего по этому пути пошёл Go.
Я уверен, что через 20 лет все актуальные ЯП (кроме самых low-level) будут придерживаться аналогичных подходов, потому что это позволит эффективно использовать все 1024 ядра (ну или сколько тысяч их там будет к тому времени) и управлять сотнями компонентов умного дома из одной программы.
Конечно, к этому можно привыкнуть и даже начать считать удобным, если достаточно долго себя в этом убеждать… только какой в этом смысл?
“If Java had true garbage collection, most programs would delete themselves upon execution.”
— Robert Sewell
Вот тут дело было.