В смысле, «отдельно»? 0_о Код метода является частью объекта. И он в этом смысле хранится в самом объекте. В объектах, помимо методов, коду больше негде храниться…
Самое простое:
Test newOn: [true should be: false].
Test class >> newOn: aBlockClosure
^ self new code: aBlockClosure
Test >> code: aBlockClosure
code := aBlockClosure
Вы предлагаете для каждого метода сделать свой отдельный объект. Собственно в RSpec'е, если я не ошибаюсь, так и есть. И проблема с Rspec'ом в RoR-приложениях, в частности в том, что запуск прогона в крупных проектах отнимает довольно немало времени.
Ему, прежде чем начать тестирование, приходится проинициализировать все объекты, неговоря уже о том, что перед этим надо проинициализировать среду исполнения, то бишь приложение. И это порой может занимать десятки минут…
Это я и имел ввиду, когда говорил, что объекты — дорогостоящая структура.
Едва ли задержки вызваны самим фактом хранения тестов в отдельных объектах (если это действительно так реализовано в RSpec). По крайней мере, я не могу навскидку нафантазировать каких-либо возможных причин для этого. В крупных проектах и на стандартном xUnit прогон тестов отнимает немало времени — там тоже нужно проинициализировать все объекты и среду. Возможно, в RSpec время тратится на что-то еще, может быть, в тестах используется DSL, который транслируется в момент выполнения? Если у вас есть конкретная информация об эффекте — будет интересно узнать.
«Бодание» с проблемами используемой/-ого библиотеки/фреймворка вместо написания приложения — проблема, относящаяся к любому используемому в проекте стороннему (да и не только стороннему) коду. За все, в том числе и удобство, приходится платить. В данном случае за более развитые средства управления тестами, возможно, придется заплатить большей сложностью фреймворка.
Но не факт, на самом деле, что возникнут какие-то дополнительны сложности: более естественные вещи как раз обычно получаются более простыми. Представлять тест с помощью соответствующего объекта может (должно, на мой взгляд — насколько я успел это дело продумать) оказаться как раз более удачным решением, снимающим целый ряд проблем и ограничений. Именно поэтому мне и не очень нравится текущее решение: тест должен в себе содержать реализующий его код, а не наоборот. В конечном итоге, это просто вопрос хранения кода тестов: можно хранить их и в методах, как сейчас, а можно и отдельно. …А на простоте написания тестов это никак не скажется.
Про тесты-объекты не очень понятно? Вы предлагаете создавать объект на каждой тестируемой фичи?
Тогда объект будет состоять по сути из одного метода исполняющего тест… Идея выглядит не очень разумной. Объекты достаточно дорогостоящая структура. Или я что-то не понял?..
Именно это я и предлагаю.
В чем заключается «дорогостоимость» объекта? В очередной раз отмечу: я ведь не с проста Smalltalk беру в примеры, а там (почти) все — объекты.
Примеров, где объект имеет «по сути» один метод, можно набрать много: например, блок (замыкание)… или нить… Вообще, это признак хорошего объектного дизайна: один объект — одна ответственность.
… А если не «по сути», то у теста довольно много даже базовых обязанностей, кроме простого выполнения: хранить имя, связи с другими тестами, какие-нибудь комментарии, историю выполнения и много другой метаинформации. С тестами, лежащими как методы где-то в недрах класса, довольно сложно что-либо сделать в плане управления — это закрывает множество возможностей по развитию средств управления тестами и их более широкому использованию на различных этапах разработки ПО. Или, например, воспроизвести историю разработки — целая проблема. А насколько это было бы удобно в плане обучения других и самого себя?
В общем, есть целый ряд задумок, связанных с TDD/BDD и дальнейшим развитием существующих принципов разработки с использованием тестов, где тесты-объекты очень нужны.
Вообще, это довольно большая тема… поэтому тезисно:
1. Я не считаю, что Smalltalk-у будет на пользу увеличение количества реализаций. См., например, Smalltalk: Welcome to the Balkans. Лучше консолидировать усилия в плане развития существующих реализаций. А еще лучше попытаться избавится от некоторых недоработок, проблем и ненужных сложностей в языке и архитектуре, присущих (даже) Smalltalk-у.
2. Я не уверен, что популяризация Smalltalk-а будет на пользу и ему, и ИТ в целом. …Да, здесь очень много места для обсуждения «в кулуарах»
3. Рискну упомянуть, что у меня нет уверенности, что на JVM возможна хорошая реализация Smalltalk-а. Впрочем, я не специалист в этой области, так что это мнение просто «из общих соображений».
Впрочем, все это не значит, что я противник данного проекта. Я, скорее, отношусь к сочуствующим :)
На Smalltalk-е проекты делал, делаю и буду делать… пока что-то получше не придумаем. В целом, слухи о смерти Smalltalk-а сильно преувеличины. Но вообще согласен: то, что массы считают Smalltalk мертвым — это проблема… для масс.
А Джеймса немного знаю лично — мужик хороший. Хотя, я сам именно на этот проект свои кровные отдавать не хочу… не очень я верю в коммунизм и Smalltalk на JVM.
Если есть глобальные объекты (что плохо), разумеется надо самому заботится об правильной переинициализации. Перезапуск образа в «начальное состояние» ничего не сбрасывает — разве что почистит внешние ресурсы (что тоже не всегда удобно, но как иначе?). Можно создать новый образ (из чистого) и загрузить туда нужный код. В общем, работа с образами удобна, но требует определенной дисциплины управления образами.
Да, я в прошлом комментарии не упомямнул, что объекты из образа можно различными способами выгружать и загружать обратно. И, естественно, существует целый ряд инструментов для управления исходным кодом.
Да — все перечисленное не только возможно, но в том или ином виде уже реализовано.
Только методы добавляются не к индивидуальным объектам, а к классам — просто поведение объекта полностью определяется классом, к которому он принадлежит. Но при необходимости можно «на лету» создать новый класс с нужным методом и сделать объект его экземпляром. Это, конечно, не так уж и просто. Хотя не так уж часто такое требуется, но все равно особо не радует. И речь о желательности иметь бессклассовый объектный язык заходит в том числе и поэтому (среди прочих соображений).
Что понимается под «оно»? Если речь о всей системе в целом, то она сохраняется в «как есть» в виде т.н. образа. В частности, это означает (любимый пример смоллтокеров:), что можно в процессе отладки программы сохраниться, а потом открыть сохраненный образ на другом компьютере и продолжить отладку.
И есть ли там понятие «перезапустить программу», например (да и есть ли понятие программы вообще)?
А что такое программа? Вычисления запускаются передачей сообщения некоторому объекту, который для его обработки передает сообщения другим объектам и т.д. Соответственно «перезапуск» программы выполняется остановкой процесса, выполняющего такие вычисления, и запуск нового аналогичным способом.
Выше я показал два вида инспекторов объектов, доступных в Pharo (одной из реализаций Smalltalk). Да, они являются родственниками (а то и родителями) упомянутых инструментов в VS (или практически любой другой мейнстримовой среде). Только помощнее и поудобнее в некоторых аспектах. Но главное, позволяют работать с объектами напрямую в любой момент — но это не их личная заслуга. Просто в Smalltalk-ах нет разделения на время «редактирования», «выполнения» и «выполнения с отладкой» — любая программа выполняется в единой среде, в которой (если не отключены) живут все объекты, представляющие средства разработки, отладки, сами классы, методы… и вообще почти все, что есть в программной системе. Очень удобно и эффективно (с точки зрения разработчика, как миминимум).
Тем не менее, несмотря на свою относительную развитость, объектность и даже авангардность (да, я про систему, созданную более 30 лет назад!), среда Smalltalk все равно несет в себе, как очень точно подмечено, следы кодо-ориентированности. Программист даже в Smalltalk-е все равно значительную часть времени вынужден проводить, работая с кодом, а не с живыми объектами. Что уж говорить о «современных» «продвинутых» текстовых редакторах, которые по недоразумению кем-то были названы IDE :)
В принципе, это мое личное мнение, но автор, как мне кажется, говорил именно об этом. Так что, да: думаю, он хочет видеть реальные объекты в IDE… и как можно чаще. Тем, что это не удается делать чаще, он и недоволен. А про полное отсутствие он не говорит… даже упоминает кое-что (тот же Seaside).
Не пойму, почему (почти?) все воспринимают эту статью как негативную по отношению к объектному программированию?
Из-за слова «ненавижу»? Так, там рядом стоит «временами».
Из-за критики парадигмы? Но ее действительно не существует в том смысле, что нет единого мнения о том, что же это такое. Впрочем, мне кажется, это больше дискредитирует современное ИТ-сообщество (да и вообще людское общество), нежели саму идею объектности. …И сам термин ООП настолько заляпали грязными ручонками, что вот я, к примеру, стараюсь его максимально избегать. Да и изначально присутствие слова «ориентированный» не обещает ничего хорошего…
Подробный анализ перечисленных претензий требует времени. Но я готов подписаться практически подо всеми, являясь при этом убежденным объектником, считающим Smalltalk на сегодняшний день как минимум одним из лучших объектных языков. И критика, надо сказать, весьма конструктивна — вполне может рассматриваться как руководство к действию по созданию нового, лучшего чем Smalltalk объектного языка.
И, кстати, автор статьи — довольно известный Smalltalker.
Светский разговор об управляемой тестами выпечке… данный подход очень хорошо (по крайней мере, лучше всех известных мне мейнстримовых альтернатив) сочетается с использованием среды Smalltalk
Ни у хлеба, ни у кирпича до сих пор нет функциональности. Так что сводить их в единую иерархию нет ни необходимости, ни желания. Smalltalk, к счастью, не заставляет это делать — динамика, однако!
Как только будут предъявлены конкретные функциональные требования по процессу выпекания, и можно будет создать соответствующий(ие) тест(ы), вопрос будет решен.
Соображения «похожести на реальность» я стараюсь не привлекать при принятии проектных решений, так как сама необходимость принятия решения по таком критерию — это, скорее, признак недостатка информации и начала «фантазий». Да и не всегда «реальность» достаточно однозначна.
Чаще я использую сравнение с реальностью для валидации получающегося дизайна: если он получается похожим на реальные вещи, значит, скорее всего, все хорошо. Если нет — есть повод задуматься: не упущено ли что либо. В данном случае, конечно, что-то не так… Но я на это уже несколько раз пенял.
…А вот что я всегда слушаю, так это код. Каким-то волшебным способом он лучше знает, кто за что должен отвечать. Так что в данном случае ответственность за выполнение рецепта, в зависимости от того, куда выведут тесты и код, может быть возложена и на печку (так пока было проще написать, «код так захотел»), и на сам рецепт (это наиболее вероятный вариант на ближайшие несколько итераций)… другие варианты пока кажутся маловероятными, но кто знает, что там в голове у заказчика…
Самое простое:
Едва ли задержки вызваны самим фактом хранения тестов в отдельных объектах (если это действительно так реализовано в RSpec). По крайней мере, я не могу навскидку нафантазировать каких-либо возможных причин для этого. В крупных проектах и на стандартном xUnit прогон тестов отнимает немало времени — там тоже нужно проинициализировать все объекты и среду. Возможно, в RSpec время тратится на что-то еще, может быть, в тестах используется DSL, который транслируется в момент выполнения? Если у вас есть конкретная информация об эффекте — будет интересно узнать.
Но не факт, на самом деле, что возникнут какие-то дополнительны сложности: более естественные вещи как раз обычно получаются более простыми. Представлять тест с помощью соответствующего объекта может (должно, на мой взгляд — насколько я успел это дело продумать) оказаться как раз более удачным решением, снимающим целый ряд проблем и ограничений. Именно поэтому мне и не очень нравится текущее решение: тест должен в себе содержать реализующий его код, а не наоборот. В конечном итоге, это просто вопрос хранения кода тестов: можно хранить их и в методах, как сейчас, а можно и отдельно. …А на простоте написания тестов это никак не скажется.
Именно это я и предлагаю.
В чем заключается «дорогостоимость» объекта? В очередной раз отмечу: я ведь не с проста Smalltalk беру в примеры, а там (почти) все — объекты.
Примеров, где объект имеет «по сути» один метод, можно набрать много: например, блок (замыкание)… или нить… Вообще, это признак хорошего объектного дизайна: один объект — одна ответственность.
… А если не «по сути», то у теста довольно много даже базовых обязанностей, кроме простого выполнения: хранить имя, связи с другими тестами, какие-нибудь комментарии, историю выполнения и много другой метаинформации. С тестами, лежащими как методы где-то в недрах класса, довольно сложно что-либо сделать в плане управления — это закрывает множество возможностей по развитию средств управления тестами и их более широкому использованию на различных этапах разработки ПО. Или, например, воспроизвести историю разработки — целая проблема. А насколько это было бы удобно в плане обучения других и самого себя?
В общем, есть целый ряд задумок, связанных с TDD/BDD и дальнейшим развитием существующих принципов разработки с использованием тестов, где тесты-объекты очень нужны.
1. Я не считаю, что Smalltalk-у будет на пользу увеличение количества реализаций. См., например, Smalltalk: Welcome to the Balkans. Лучше консолидировать усилия в плане развития существующих реализаций. А еще лучше попытаться избавится от некоторых недоработок, проблем и ненужных сложностей в языке и архитектуре, присущих (даже) Smalltalk-у.
2. Я не уверен, что популяризация Smalltalk-а будет на пользу и ему, и ИТ в целом. …Да, здесь очень много места для обсуждения «в кулуарах»
3. Рискну упомянуть, что у меня нет уверенности, что на JVM возможна хорошая реализация Smalltalk-а. Впрочем, я не специалист в этой области, так что это мнение просто «из общих соображений».
Впрочем, все это не значит, что я противник данного проекта. Я, скорее, отношусь к сочуствующим :)
А Джеймса немного знаю лично — мужик хороший. Хотя, я сам именно на этот проект свои кровные отдавать не хочу… не очень я верю в коммунизм и Smalltalk на JVM.
Если есть глобальные объекты (что плохо), разумеется надо самому заботится об правильной переинициализации. Перезапуск образа в «начальное состояние» ничего не сбрасывает — разве что почистит внешние ресурсы (что тоже не всегда удобно, но как иначе?). Можно создать новый образ (из чистого) и загрузить туда нужный код. В общем, работа с образами удобна, но требует определенной дисциплины управления образами.
Да, я в прошлом комментарии не упомямнул, что объекты из образа можно различными способами выгружать и загружать обратно. И, естественно, существует целый ряд инструментов для управления исходным кодом.
Только методы добавляются не к индивидуальным объектам, а к классам — просто поведение объекта полностью определяется классом, к которому он принадлежит. Но при необходимости можно «на лету» создать новый класс с нужным методом и сделать объект его экземпляром. Это, конечно, не так уж и просто. Хотя не так уж часто такое требуется, но все равно особо не радует. И речь о желательности иметь бессклассовый объектный язык заходит в том числе и поэтому (среди прочих соображений).
Что понимается под «оно»? Если речь о всей системе в целом, то она сохраняется в «как есть» в виде т.н. образа. В частности, это означает (любимый пример смоллтокеров:), что можно в процессе отладки программы сохраниться, а потом открыть сохраненный образ на другом компьютере и продолжить отладку.
А что такое программа? Вычисления запускаются передачей сообщения некоторому объекту, который для его обработки передает сообщения другим объектам и т.д. Соответственно «перезапуск» программы выполняется остановкой процесса, выполняющего такие вычисления, и запуск нового аналогичным способом.
Тем не менее, несмотря на свою относительную развитость, объектность и даже авангардность (да, я про систему, созданную более 30 лет назад!), среда Smalltalk все равно несет в себе, как очень точно подмечено, следы кодо-ориентированности. Программист даже в Smalltalk-е все равно значительную часть времени вынужден проводить, работая с кодом, а не с живыми объектами. Что уж говорить о «современных» «продвинутых» текстовых редакторах, которые по недоразумению кем-то были названы IDE :)
В принципе, это мое личное мнение, но автор, как мне кажется, говорил именно об этом. Так что, да: думаю, он хочет видеть реальные объекты в IDE… и как можно чаще. Тем, что это не удается делать чаще, он и недоволен. А про полное отсутствие он не говорит… даже упоминает кое-что (тот же Seaside).
Из-за слова «ненавижу»? Так, там рядом стоит «временами».
Из-за критики парадигмы? Но ее действительно не существует в том смысле, что нет единого мнения о том, что же это такое. Впрочем, мне кажется, это больше дискредитирует современное ИТ-сообщество (да и вообще людское общество), нежели саму идею объектности. …И сам термин ООП настолько заляпали грязными ручонками, что вот я, к примеру, стараюсь его максимально избегать. Да и изначально присутствие слова «ориентированный» не обещает ничего хорошего…
Подробный анализ перечисленных претензий требует времени. Но я готов подписаться практически подо всеми, являясь при этом убежденным объектником, считающим Smalltalk на сегодняшний день как минимум одним из лучших объектных языков. И критика, надо сказать, весьма конструктивна — вполне может рассматриваться как руководство к действию по созданию нового, лучшего чем Smalltalk объектного языка.
И, кстати, автор статьи — довольно известный Smalltalker.
Ни у хлеба, ни у кирпича до сих пор нет функциональности. Так что сводить их в единую иерархию нет ни необходимости, ни желания. Smalltalk, к счастью, не заставляет это делать — динамика, однако!
Как только будут предъявлены конкретные функциональные требования по процессу выпекания, и можно будет создать соответствующий(ие) тест(ы), вопрос будет решен.
Соображения «похожести на реальность» я стараюсь не привлекать при принятии проектных решений, так как сама необходимость принятия решения по таком критерию — это, скорее, признак недостатка информации и начала «фантазий». Да и не всегда «реальность» достаточно однозначна.
Чаще я использую сравнение с реальностью для валидации получающегося дизайна: если он получается похожим на реальные вещи, значит, скорее всего, все хорошо. Если нет — есть повод задуматься: не упущено ли что либо. В данном случае, конечно, что-то не так… Но я на это уже несколько раз пенял.
…А вот что я всегда слушаю, так это код. Каким-то волшебным способом он лучше знает, кто за что должен отвечать. Так что в данном случае ответственность за выполнение рецепта, в зависимости от того, куда выведут тесты и код, может быть возложена и на печку (так пока было проще написать, «код так захотел»), и на сам рецепт (это наиболее вероятный вариант на ближайшие несколько итераций)… другие варианты пока кажутся маловероятными, но кто знает, что там в голове у заказчика…