проблемы объектного сознания

[jahson]

fisher
Согласен. Но формулировка изначально сильно хромала.
Йегги хорошо пишет, но не без передёргивания. Но в целом - он прав, относительно явы.

Также там есть некоторое количество хороших комментариев, например со ссылкой на Алана Кея http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html
Это тоже стоит прочитать.

-~{}~ 19.03.09 12:26:

Чтобы не создалось впечатления, что я ограничил правоту Йегги явой (а изначально там тема про то, что ява не даёт функциям существовать свободно) - он также прав во многом другом, и это уже относится к другим языкам.

-~{}~ 19.03.09 12:36:

И забава из комментов там:
VSO vs SVO
(S)You can (V)kiss (O)my ass.
(V)kiss (S)you (O)my ass.

Кстати, если уж уходить так глубоко - у каждого ли глагола есть источник?

 

[fisher]

Автор оригинала: john.brown
fisher

Можно иметь одного, двух гуру пятого уровня магии, а остальных просто дисциплинированных магов, уровнем пониже.

нельзя вот так отдельно рассматривать проблему. тут мы приходим к наставничеству и к вопросу, а что собственно должен делать наставник. а на мой взгляд наставничества больше должно быть в архитектуре, в программировании на мета-уровне. в больших проектах ОО архитектуры нет - ОО это уже дизайн кода, компонент. эта магия дизайна компонент важна но вторична(!) - я писал об этом выше. все знания о подсистемах формулируятся в терминах данных, передачи данных, общения между серверами и сервисами - потому что фундаментально программа это данные и работа над ними. базовый язык другой - это сильно отличается от клепания типовых сайтов на фреймворках или создания себе или коллегам инструмента для такого клепания. 80% работы в большом проекте - саппорт, причем чаще всего задачи заведомо некорректные - разобраться в проболеме по подземному стуку, и если разработчик будет выебываться "не понимаю, что хотите, поставьте мне корректну задачу" - ему объяснят, что в этом мире правила такие, что надо либо разбираться, либо работать где-то ещё. поэтому существует такой поток задач, такие внешние условия, когда с точки зрения процессов ООП это вообще дело десятое, и чем проще и "тупее" код тем лучше. и выгоднее иметь полностью самостоятельных ребят, чтобы каждый вел свой кусок - и не потому что шалопаи, можете попробовать пройти у нас собеседование

тут пробегала фраза мол ооп мне помогает какой-то там язык создать и разговаривать на нем на интутивно понятном бла-бла. вот для распределенных проектов базовый язык - он вообще другой, а ооп привносит ещё и какую-то свою "сложность" (не в смысле веса, а в смысле бритвы оккама). это не проблема ООП, но я просто вижу по опыту как это влияет на метод "думания". я для себя выработал простой принцип - cost oriented development. я не знаю, наверняка этот термин кто-то придумал и обсосал раньше. суть очень простая - моделирование не затрагивает ооп вообще. данне, работа над ними, что как куда едет. это архитектура. ооп включать можно только в тот момент, когда архитектура понятна со всех сторон рассмотрена и принята - надо задизайнить компоненты. но тут появляется связывание и целая магия избавиться от связывания. у меня есть знакомый один, довольно опытный разработчик, он как-то мне сказал, что для того чтобы не искушать себя дизайном и игрушечками он в какой-то момент стал делать чаще классы исключительно со статическими методами. понятно что это крайность, но вспомните, что я писал про объединение "состояния" и "поведения", а также пост про "королевство существительных". так вот ооп как язык мысли 1) с большой вероятностью "замоет" физический уровень 2) усложнит код там, где его можно было упростить. скроет красиво косяки и вылезут они потом тебе боком в том же саппорте. это к вопросу "что делать", который мне тут с завидной регулярностью задают. то есть ооп только для дизайна компонент, причем без излишеств типа "на каждую сущность делаем объект".

вы меня обвиняли в "неправильности" темы. я считаю все эти обвинения были исключительно эмоциональны, провокация сработала - разрушала ваш тоннель. так выйдите из него и посмотрите на проблему со стороны.

 

[HraKK]

А у меня сайт попал под фильтр гугла

 

[fixxxer]

fisher

слушай, ну ты все правильно говоришь про решение задач, про потоки данных, getting things done дада, но это же никак не проблема объектного мышления. это проблема увлечения одной стороной архитектуры забивая на другую. перекос. просто вопрос то в том что любая методология, она увлекает. на месте ооп может быть аоп какой нибудь, или любая другая аббревиатура на вкус. я видел точно так же увлеченных архитектурой сишников, вводивших стопицот абстракций в течение 3 месяцев, когда задача то по сути плевая и решается за неделю. это не проблема конкретной парадигмы, а общая проблема увлечения процессом забывая о цели.

 

[whirlwind]

На текущий момент я сделал для себя следующие выводы:

1) Для строительства больших мостов нужно просто ложить кирпичи друг на друга. Если применить сварку, то в последствии будет очень трудно изменить результат (например переложить кирпичи елечкой). Неиспользование сварки позволит сэкономить на действиях низкого уровня, то есть на легкости перекладывания кирпичей. При этом так же экономится время на продумывание архитектуры, так как в больших мостах архитектуры нет.

2) Для использования сварки нужны более продвинутые работники (то есть нужно учиться и это какбе ненормально, потому что нигде в других профессиях наставничество не практикуется и практически любой профессии можно научиться самостоятельно)

3) Более сложная технология (в плане освоения) никогда не даст выигрыш по оношению к более простой по таким критериям скорость производства, надежность, переработка. Кроме того, сварка требует дополнительных затрат на электроэнергию и электроды.

Вывод: сварка - зло!

 

[john.brown]

fisher
Имхо, ты путаеш в одну кучу две разные вещи - то, что в умл описывается диаграммами прецедентов, деятельности, с тем, что описываеться диаграммами объектов, пакетов, зависимостей. Но это две весьма разные области, и язык для их описания тоже разный. Понятно, что проуедурами можно тупо копировать прецеденты и деятельность, и любой начинающий программист в своем спагети коде именно так и поступает. Надеюсь, не надо объяснять, к чему это приводит?

выгоднее иметь полностью самостоятельных ребят, чтобы каждый вел свой кусок

Так, имхо, ооп как раз для этого и предназначен. Или я что то не понимаю?

Излишества всегда плохи, и понятно, что хэло ворлд не надо писать так, как в известном примере ( ), но на то и те гуру, котрые должны присутствовать в команде.


whirlwind
+1

 

[fisher]

>>просто вопрос то в том что любая методология, она увлекает. на месте
>>ооп может быть аоп какой нибудь, или любая другая аббревиатура на вкус
точно! и статистически "увлекания" у оопэшников больше всего

 

[x-yuri]

whirlwind неправильные выводы, читай внимательнее ;-)

точно! и статистически "увлекания" у оопэшников больше всего

а откуда статистика?

 

[флоппик]

а откуда статистика?

Британские ученые.

 

[fixxxer]

>> точно! и статистически "увлекания" у оопэшников больше всего

ну это потому что ооп наиболее распространено. с таким же успехом можно обвинять php в низком пороге вхождения и вытекающих проблемах.

вообще проблема делится на две. на самосознание отдельно взятого девелопера и на вопрос управления процессом разработки. если второе можно конструктивно обсуждать, то первое ничем кроме холивара не закончится. а так то любую парадигму можно использовать и на пользу, и во вред. "все есть яд и все есть лекарство".

 

[atv]

а ооп привносит ещё и какую-то свою "сложность" (не в смысле веса, а в смысле бритвы оккама)

Я всё-таки не понимаю, о чём речь, об Объектно-Ориентированном Проектировании (OOD), или об Объектно-Ориентированном Программировании (OOP)

точно! и статистически "увлекания" у оопэшников больше всего

У не зрелых "оопэшников", юных, так сказать, которые только что освоили OOD мышление. Но это проходящее. Оно основывается на неоднозначности классификации (как это описано у Гради Буча), и, соответственно, неоднозначном выборе абстракций при OOD. С накоплением опыта, программист всё лучше и лучше начинает владеть своим новым инструментом под названием OOD.

 

[fisher]

ну вот опять скатились к "а у меня всё работает"

 

[whirlwind]

Автор оригинала: atv С накоплением опыта, программист всё лучше и лучше начинает владеть своим новым инструментом под названием OOD.

полностью подтверждаю =)

раз http://phpclub.ru/talk/showthread.php?postid=652817#post652817
два http://phpclub.ru/talk/showthread.php?postid=781482#post781482

 

[john.brown]

fisher
Ну а куда еще скатываться, если работает? Притом, в подавляющем большинстве случаев. Понятно, что у кого то не работает. Из тех, одни ищет проблемы в своей организации производства, а другие обобщает свое "неработает" на глобалный маштаб, и заявляют, что зло в технологиях. Ты, извини, принадлежиш к последним

 

[fisher]

john.brown

1) я не писал что у меня не работает. и я знаю что делать чтобы работало. и я оцениваю кост этого "делать" - не с позиции прости кодера, а с позиции предприятия. ты как будто не читаешь что я пишу.

2) выше я объяснил почему твоя точка зрения ошибочна. ты говоришь - мы напряжемся, и всё станет хорошо. а я говорю, что если _того_же_ результата можно достигнуть не напрягаясь - то напрягаться не нужно! потому что это напряжение сут усложнение, и если в деньгах результат один и тот же, то мы проигрываем потому что любое "усложнение" приводит к повышению вероятности отказа - это такой глобальный закон мироздания.

-~{}~ 19.03.09 18:52:

>>Я всё-таки не понимаю, о чём речь, об Объектно-Ориентированном >>Проектировании (OOD), или об Объектно-Ориентированном Программировании (OOP)
обо всём. ещё раз - любое "оо" - оно должно быть только про кодинг, про компоненты. и это всё вторично.

-~{}~ 19.03.09 18:56:

точка приложения усилий должна быть в архитектуре, в прозрачности аналитической модели - но не в кодинге. кодинг это уже относительно тупое занятие, и превращать его в сложные сопли нет никакой необходимости! впрочем, я снова рискую нарваться на очередной тоннель

 

[whirlwind]

fisher Вот тут я с тобой полностью согласен. Но мне кажется ты не учитываешь очень важной детали - все мы оцениваем субъективно. Кост в том числе. Ну не станешь же ты утверждать, что мы ("фанатики" ООП) настолько глупые, что за прошедшие годы (см. ссылки выше) не смогли уяснить то, о чем ты говоришь не в первый раз. Раз мы до сих пор в деле, это может означать как минимум - проблемы, по крайней мере, не стоят настолько остро, что невозможно работать.

 

[fisher]

Автор оригинала: whirlwind
fisher Вот тут я с тобой полностью согласен. Но мне кажется ты не учитываешь очень важной детали - все мы оцениваем субъективно. Кост в том числе. Ну не станешь же ты утверждать, что мы ("фанатики" ООП) настолько глупые, что за прошедшие годы (см. ссылки выше) не смогли уяснить то, о чем ты говоришь не в первый раз. Раз мы до сих пор в деле, это может означать как минимум - проблемы, по крайней мере, не стоят настолько остро, что невозможно работать.

1) разве ты в этом треде не писал вначале про то, что мол объект всегда лучше ассоциативного массива?
2) я не писал, что невозможно работать

 

[john.brown]

fisher
Да не говорю я, что "мы напряжемся, и всё станет хорошо"ю Я говорю, что сделам так, чтоб без всякого напряжения все было хорошо. Системой, так сказать.

Следуя твоей логике (я оцениваю кост этого "делать"), надо переходить на пользование индуских пуре пхтмлшиков, и будет щастье. Но ведь не будет, и ты сам это знаеш, иначе незатеял бы этот тред.

Вопрос о том, что ооп усложняет продукт весьма спорный - на примере "хелло ворлд" это, конечно, так. Но на больших проектах, это, имхо, в корне не так. Как раз на оборот - это упрощает как код, так и его сопровождение.

точка приложения усилий должна быть в архитектуре, в прозрачности аналитической модели

Так об этом, на протяжении хрен знает скоко страниц, все тебе и толкуют. И хорошо спроектированная ооп архитектура по любому прозрачнее процедурной - это как собирать мост из готовых сварных конструкций, или складывать из отдельных кирпичиков.
На самом деле, я так понимаю, все упирается в то, что хорошему оопешнику, который может хорошо спроектировать, надо приличные деньги платить, а процедурами что нибудь напишет и дешевый индус. Или опять я не прав?

 

[whirlwind]

Автор оригинала: fisher
1) разве ты в этом треде не писал вначале про то, что мол объект всегда лучше ассоциативного массива?

Писал, а при чем здесь это? В плане цены чтоле? Тут надо понимать, что 1000 массивов, которые молчат на ошибки программиста, нервно курят в сторонке перед 1 классом, который дает тебе тотальный контроль над данными (например кидает эксепшены). Теперь посчитай кост поиска бага а-ля - буковку забыли, и время написания класса состоящего из 70 строк кода (мой вариант). Как по мне так кост 1000 массивов несоизмеримо больше =)

ЗЫ. а если добавить всякие полиморфизмы и прочие прелести так вапще

 

[fisher]

Автор оригинала: john.brown
Так об этом, на протяжении хрен знает скоко страниц, все тебе и толкуют. И хорошо спроектированная ооп архитектура по любому прозрачнее процедурной - это как собирать мост из готовых сварных конструкций, или складывать из отдельных кирпичиков.
На самом деле, я так понимаю, все упирается в то, что хорошему оопешнику, который может хорошо спроектировать, надо приличные деньги платить, а процедурами что нибудь напишет и дешевый индус. Или опять я не прав?

Прав отчасти. Риски велики. Риски зарыться, увлечься, запрутаться в красоте языка, и не решить исходную задачу исходя из минимума затрат. Насчет хорошего оопешника - ты будешь смеяться, я вообще думаю, что чем он "лучше" (в плане желания сделать всё правильно) - тем выше эти риски И кстати перестаньте с процедурщиной сразу сравнивать и с пуре пхтмлщиками.

-~{}~ 19.03.09 19:42:

Автор оригинала: whirlwind
Тут надо понимать, что 1000 массивов, которые молчат на ошибки программиста, нервно курят в сторонке перед 1 классом, который дает тебе тотальный контроль над данными (например кидает эксепшены). Теперь посчитай кост поиска бага а-ля - буковку забыли, и время написания класса состоящего из 70 строк кода (мой вариант).

о, а давай конкретный пример рассмотрим. какие 1000 массивов и 1 класс и 70 cтрок кода?