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

[whirlwind]

StUV ты видимо подводишь к тому, что это очень удобно? =)

 

[StUV]

whirlwind
что куда подвожу, чтобы показать что удобно ?

 

[svetasmirnova]

StUV
> т.е. trigger и if (...)/assert=>{...} - это "унылое г.", а throw и catch(...)=>{...} - это круто ?

Это ты сказал.

> семантически - просто разная форма записи
> точно так же и exception vs. assert-arg

Это неоднозначно.

>> А я хочу иметь возможность вообще не смотреть на возвращаемые значения
> а в catch() у тебя что ?

В catch у меня может быть Exception, а может быть UserException. Но дело не только в этом.

Пример и вопрос.

Имеем index.php, в котором у меня примерно то же самое, что whirlwind в качестве примера приводил. За одним исключением: конструкция в блоке

try { [1] } 
catch (Exception $e) {
// пишем в лог
echo "Этого не может быть! Что-то сломалось!"
}

Далее в [1] имеем в том числе какие-то try-catch c обработчиками для UserTypeNException и внутри их не паримся с проверкой значений/обработкой ошибок за исключением частных случаев.

Всё это прекрасно делается при помощи хэндлеров и в процедурном стиле.

И вот теперь представим, что в каком-то единичном месте мне нужно обработать перехватываюмую уже ошибку как-то по-особому. В моём объектном варианте я просто добавлю ещё один блок try-catch внутри большого блока. А что делать в процедурном варианте?

 

[fisher]

Автор оригинала: Lightning
Тимлид.
А к чему этот вопрос? Или это наезд аля "А ты кто такой?" ?

Не, "ты кто такой", это ты меня с другим участником нашей дискуссии перетутал Чтобы давать менеджерский ответ, нужно быть менеджером, увы - поэтому я и спросил. Увы. То есть вот отвечать жопой своей за то, что кому-то хочется красиво, правильно и так далее. Вопросы организации - они "фундаментальнее" XP и TDD. Это совершенно другая тем, но она чем-т похожа - так же и "программирование" фундаментальнее ОПП. Об этом был топик. О том, что ключевые навыки и рост, полезность программиста, качества - лежат в другой области и нельзя допускать подмены.

А все аргументы "оппонентов" свелись к следующему: проблем не будет, если следовать правилам (хотя я не понимаю - почему оппоненты?). В-общем, надо ли говорить, в чем тут возможно кроется ошибка? Ошибка в том, что принимая близко к сердцу какие-то правила, вы оказываетесь в ловушке. В ловушке этих правил - вы мыслите в категориях системы, когда нужно уметь выходить из неё.

Чтобы понять, на каком уровне возможна дискуссия по обозначенной теме, давайте представим себе, что вы играете в компьютерную игрушку. У вас есть какие-то персонажи, там, эльфы, тролли. Можно грабить корованы, да. У всех разные скиллзы. Для разных задач вам требутся разные войска, вы попробовали всё делать одной "расой" но быстро поняли, что так ничего не выйдет. Вы не можете улучшать сразу все показатели, развивать все расы - у вас не достаточно ресурсов. Вот теперть подумайте, "важен" ли в контексте выигрыша игрушки плач-вопрос конкретного эльфа: ну почему наши войска не состоят из одних волшебных приятных умных эльфов с пятым уровнем магии? Это если говорить о "производстве".

А если говорить только о программировании - AnToXa мне тут подкинул совершенно чумовую ссылку, всем советую ознакомиться
http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html
Это всё в той или иной степени было затронуто в дискуссии, только мне показалось, что вы не захотели на это обращать внимание.

 

[StUV]

svetasmirnova

А что делать в процедурном варианте?

если я правильно понял - нужно обработать ошибку и вернуть управление обратно, с возможным возникновением той же ошибки ниже ?

варианты:
1. вынести блок в новую функцию
2. добавить новый обработчик

фактически, это дублирует "более совершенное"
try {/*новая функция/*} catch (Exception) {/*новый обработчик*/}

ессно, в процедурном стиле из-за этого возможно появятся проблемы передачи вместе с управлением и local-env (контекста выполнения) в новую функцию или формирования нового пакета локальных данных для нового обработчика, но, в конечном итоге и злоупотребление вложенными try...catch в одном контексте "дурно пахнет"

--

+
для меня throw/try/catch в общем виде представляется чем-то вроде fireEvent/setEventHandler/handleEvent, что прекрасно работает в процедурном стиле в сколь угодно вложенных конструкциях - т.е. exception это не столько признак ошибки, сколько способ передачи состояния процесса по событию, сформулированный изначально в терминах "обработки ошибок"

--

но, выше я сразу отметил

другое дело, что ооп-шный вариант "удобоваримее"

 

[atv]

ну почему наши войска не состоят из одних волшебных приятных умных эльфов с пятым уровнем магии?

Так вот же она, магия пятого уровня - OOP, TDD, Agile dev и т.д.

 

[svetasmirnova]

StUV
Спасибо.

А что делать, если это временное решение типа workaround для бага third-party software? Убирать же потом замучаешься после того как баг пофиксят.

Также этот момент провоцирует непредсказуемое использование собак (как вариант 3), что не есть хорошо.

Кстати "более совершенное" опять не я сказала Мне интересно как это "прямо" делают при процедурном подходе.

 

[StUV]

грустная история =)

Это всё в той или иной степени было затронуто в дискуссии

история смазано, но каменты местами as is =)))

-~{}~ 18.03.09 23:01:

svetasmirnova

Убирать же потом замучаешься после того как баг пофиксят

#ifndef FIX_12345

--
за собаки - руки отрывать
если не помогло - устранять физически =)
--

Мне интересно как это "прямо" делают при процедурном подходе.

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

по реализации - глобальный граф сообщений (указателей на функции и колбэки - собсно блоки {...} внутри try {...} catch() {...}) + обвязка эмуляторов throw / try / catch

 

[svetasmirnova]

StUV
> #ifndef FIX_12345

это PHP, но с другой стороны ifndef можно эмулировать, но тогда лишний if добавится

> за собаки - руки отрывать

подобную вещь можно сказать и про фишеровскую

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

(само)дисциплина рулит

 

[Long]

HraKK, давай не будем сор из избы тащить?

svetasmirnova, формула "процедурный подход при умелом подходе - быстрый код" на самом деле звучит так - "процедурный подход при прочих равных - быстрый код". потому как в оо подходе легко можно получить случай объектного hello world. очевидно, что такой код будет тяжело поддерживать, а работать он будет медлено. я ратую за то, что не оо подход должен быть разумно ограничен. по крайней мере до того момента, пока в команде нет кого-то уровня Фаулера

 

[svetasmirnova]

Long
Я к тому, что в PHP это может быть так. А кое-где типа JavaScript - нет.

 

[StUV]

svetasmirnova

это PHP, но с другой стороны ifndef можно эмулировать, но тогда лишний if добавится

и там и там - 3 строчки - define, if (!defined) {, }
(ну или 4 в php)
=)

(само)дисциплина рулит

периодический find/grep кода на собаки/глобалсы - это фигня, а вот корректность уровней абстракций даже с нормальным рефакторинг-браузером автоматизировать сложно

+
к фишеровской проблеме
сегодня подумалось... когда-то мне и "мнеподобным" приходилось дома фигачить вечерами "ручкой в тетради" до нескольких сотен строк кода + дебажить с теми же средствами
а на вбить/протестить этот код на машине времени было крайне мало
(ну так сложилось, не было своего компа + указанные "средства разработки" в поздне-советской школе не вызывали удивления-типа-"фи!")

отсюда и самодисциплина, и, возможно, отсутствие потребности в тдд и тем более в тфд

но... сейчас, многие кодеры коммитят код не покрыв "ручным приводом" и 50% кейсов - поэтому и "хр рулит" и без авто-тестов никак

--
я не говорю, что "тогда" было лучше - очень даже хуже, но, "дисциплина страдает"

 

[svetasmirnova]

StUV
> без авто-тестов никак

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

 

[StUV]

svetasmirnova

По другой причине:

согласен, я утрирую

 

[john.brown]

fisher

ну почему наши войска не состоят из одних волшебных приятных умных эльфов с пятым уровнем магии?

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

 

[Lightning]

fisher
Ну хорошо. Какие ты сам видишь решения описанных тобой проблем? Не использовать ООП? Использовать ООП частично? Я думаю это не решение. И не с той стороны проблемы вообще рассматриваются.

-~{}~ 19.03.09 01:34:

john.brown
+1

 

[AmdY]

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

fisher как раз об этом говорил, что ООП помогает скрыть недостатки разработчиков. причём даже архимаги уровня фаулера иногда могут принимать не верные решения, а что может напагичить среднестатический маг с 1-2 годами ООП опыта?
средний уровень это 1, ну при всей натяжке 2. им совет ничего не делать самому, только по инструкции и желательно с готовыми решениями типо zf, symfony, CI.
из опыта, править кривой процедурный код значительно удобнее, чем недооопэшеный.

 

[StUV]

кстати, в контексте этой дискуссии и

http://steve-yegge.blogspot.com/200...m-of-nouns.html

примечателен камент

Like "Pants-Oriented Clothing" indeed -- both are for covering your ass.

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

 

[john.brown]

AmdY
Неверные решения принимать свойственно всем - и магам 5 уровня, и шалопаям 1. И независимо от того, пользует он ооп, или процедуры

что ООП помогает скрыть недостатки разработчиков

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

По поводу удобства править кривой процедурный код, ох, не соглашусь Хрен редьки не слаще...

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

П.С. А ты поставь этого "мага 1 уровня" писать процедурами, и он тоже тебе такого понапишет, что мама не горюй. При этом давать ему адекватные, не двухсмысленные, четко сформулированные задания, и контролировать результат, будет намного сложнее.

 

[AmdY]

а какой средний уровень руководителей? Глупость лежащую на поверхности найти намного легче, чем обёрнутую в интерфейсы, абстрактные классы и паттерны.
От того, что код написан на плохом ООП он не становится более грамотным, а вот последствие от плохой архитектуры значительно большие.
Но правильный ООП рулит, я не спорю.