Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Работа Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 14 15 16 17 18 19 20 21 [22] 23   вперед  Ctrl
 Re: Переход с шарпа на яву  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 54505
Блог
Алексей К
Ещё есть методика - parameter object. С этим даже в продвинутом PL/SQL туго.

Не очень понимаю, кто мешает при желании. Вроде ещё в Oracle 7 можно было. Наверное и раньше, где-то с пятого, но там уже не уверен. Хотя сама по себе методика сомнительная.

Андрей Панфилов
нужно их (проверки) просто принудительно в сборку включать и фарша в коде не будет

Свинья грязь найдёт (ц) Имхо главный инструмент качества кода - программист. Такие инструменты - могут быть полезными, если не дают ложных срабатываний (бич подобных), но возможность описать в них всё "плохое", что встречается - утопия.
13 июн 12, 15:03    [12708143]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13631
softwarer
Не очень понимаю, кто мешает при желании. Вроде ещё в Oracle 7 можно было. Наверное и раньше, где-то с пятого, но там уже не уверен.
Да. Увидел уже.
13 июн 12, 15:06    [12708165]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13631
softwarer
Хотя сама по себе методика сомнительная.
Да не. Иногда сильно помогает.
13 июн 12, 15:07    [12708179]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 54505
Блог
Алексей К
softwarer
Хотя сама по себе методика сомнительная.
Да не. Иногда сильно помогает.

Я так пробежал по вариантам, пришедшим в голову, и у меня получилось, что такой parameter object должен где-то вылезать как самостоятельная сущность. Если это действительно устойчивый набор, и если мы прогнозируем такое в будущем - к примеру, при добавлении нового параметра он добавится во все подпрограммы - то это какие-нибудь "параметры расчёта", "настройки", "исходные данные эксперимента" итп - в общем, то, что где-то на отдельном экране редактируется, в отдельной таблице хранится итп. А вот так чтобы "методом пристального взгляда" выделить из кучи списков параметров... затруднился представить.
13 июн 12, 15:12    [12708207]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13631
softwarer
Я так пробежал по вариантам, пришедшим в голову, и у меня получилось, что такой parameter object должен где-то вылезать как самостоятельная сущность. Если это действительно устойчивый набор, и если мы прогнозируем такое в будущем - к примеру, при добавлении нового параметра он добавится во все подпрограммы - то это какие-нибудь "параметры расчёта", "настройки", "исходные данные эксперимента" итп - в общем, то, что где-то на отдельном экране редактируется, в отдельной таблице хранится итп. А вот так чтобы "методом пристального взгляда" выделить из кучи списков параметров... затруднился представить.
Бизнес-объект, как нынче "это" модно называть. :-)

Он может состоять из записей, хранящихся в нескольких таблицах, быть деревом, да всё что угодно. В SQL обычно принято передавать ID "корневой записи главной таблицы", по которому мы можем извлечь "это" из БД и как-то обработать результат.

А можно один раз извлечь и обрабатывать много-много раз. В пределах одной сессии.
13 июн 12, 15:28    [12708368]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13631
softwarer
А вот так чтобы "методом пристального взгляда" выделить из кучи списков параметров... затруднился представить.
Опять же может потребоваться делегировать вызов метода другому методу и передать туда все принятые параметры.
13 июн 12, 15:35    [12708427]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13631
softwarer
А вот так чтобы "методом пристального взгляда" выделить из кучи списков параметров... затруднился представить.
Или вернуть несколько значений из метода. Альтернатива группе out-параметров, которые не всегда удобны.
13 июн 12, 15:37    [12708454]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
jbond81
Member

Откуда:
Сообщений: 689
svenom
FatherSql
на шарпе максимум это сотка, на яве 150. Вот и все выводы.
Причем 150 - это один из нижних пределов для спецов с 3-4 годами нормального опыта.


позовите меня на чай, когда будетеиметь такую зарплату
13 июн 12, 16:05    [12708749]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
sphinx_mv
Member [заблокирован]

Откуда:
Сообщений: 1672
zeehond
sphinx_mv
Говорите, что знаете ООП?
Утверждаете, что ООП предполагает ограничение доступа к внутренним данным и сокрытие реализации методов?


о, новое слово в компьютер сайенсе
ООП в применении не только к ассемблеру, но и к SQL - на примере хранимых процедур
cool!
к вашему сведению, уважаемый пациент, ООП это не только (и не столько) сокрытие реализации и ограничение доступа
это прежде всего полиморфизм и наследование

Я тут покопался в загашниках... Точнее в документации... Вот пример:
CREATE TYPE Complex AS OBJECT ( 
   rpart REAL,  -- "real" attribute
   ipart REAL,  -- "imaginary" attribute
   MEMBER FUNCTION plus (x Complex) RETURN Complex,  -- method
   MEMBER FUNCTION less (x Complex) RETURN Complex,
   MEMBER FUNCTION times (x Complex) RETURN Complex,
   MEMBER FUNCTION divby (x Complex) RETURN Complex
);

Жду плевков в адрес Ларри Эллисона...

А вот вам "привет" на тему эффективности "чиста канкретного ООП"
zeehond
sphinx_mv
И кто Вам мешает это же самое обеспечивать через вызов хранимых процедур и функций непосредственно с сервера базы данных, который, к тому же, справится с этим гораздо лучше и прозрачнее?


мешает - та самая чудовищная вермишель, которая внутри этих самых хранимых процедур и функций со временем образуется
а так как новый запрос =! перекомпиляция проекта, чем вы тут недавно гордились
то на сервере очень быстро образуется нечто типа
myProcedure
myProcedure1
myProcedureOld
myProcedure2008
myProcedureForThatSpecificCaseOnlySphinxMvKnowsAbout
и так далее

Вот и примерчик того, как кое-кто работает с базами данных...

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

Ну, что тут сказать... Как Вы написали, так Вам и читать...
zeehond
SQL - не тот язык, на котором можно что-то серьёзное и большое писать и без приложения нечеловеческих усилий поддерживать
в нём нет ни внутренней, ни внешней дисциплины

Дисциплина нужна разработчику, а не молотку, которым он забивает гвозди... Или Вы предпочитаете гвозди бить мобильным телефоном?
13 июн 12, 16:37    [12709100]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 54505
Блог
Алексей К, Вы отвечаете по сути тавтологиями: это нужно потому, что иногда это нужно. Я со своей стороны могу сказать только одно: я никогда не натыкался на ситуацию, при которой, глядя на "десятки похожих параметров в вызовах" соображал бы, что их было бы удобно сгруппировать. Допускаю, что такое может возникнуть при рефакторинге очень-старого-и-плохого-чужого-кода, но у меня всегда получалось наоборот: сначала понял, что есть некая структура данных (объект, итп), потом развивается api работы с ним.
13 июн 12, 16:50    [12709214]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
zeehond
Member [заблокирован]

Откуда:
Сообщений: 2535
sphinx_mv
Дисциплина нужна разработчику, а не молотку, которым он забивает гвозди... Или Вы предпочитаете гвозди бить мобильным телефоном?


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

вот такой
Картинка с другого сайта.

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

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

возможно в паре мест забивалка не дотянется и нужно таки будет достать ваш молоток
но вы же предлагаете своим молотком делать вообще всё, включая и шурупы и гайки
13 июн 12, 17:05    [12709321]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13631
softwarer
Вы отвечаете по сути тавтологиями: это нужно потому, что иногда это нужно.
Ну хорошо. :-)

Благодаря этой методике программа может оказаться гораздо компактнее. Для меня это большое преимущество, конечно, при отсутствии других недостатков, которые могут быть вызваны применением этого подхода. :-)
13 июн 12, 17:19    [12709422]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20318
Ed Post
Настоящий Программист может написать фортрановскую программу на любом языке.
А может точно так же написать что-то более пристойное на любом языке.
13 июн 12, 17:26    [12709475]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
AlexeiK
Member

Откуда:
Сообщений: 2830
ребят, почитал последнюю страницу, да вам реально, быдлокодинг.
картинки уже соотвестующии стали появлятся, как раз для рабочего, который не думает, а тупо шпоняет гвозди в доску.

фу позор.
спустили хорошо завершенную тему, в полный шлак.
13 июн 12, 17:26    [12709478]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13631
softwarer
но у меня всегда получалось наоборот: сначала понял, что есть некая структура данных (объект, итп), потом развивается api работы с ним.
И этот объект "кочует" между методами, содержащими логику по его обработке. Как правило удобнее передать ссылку на весь объект, чем перечислять в параметрах методов все его поля.
13 июн 12, 17:32    [12709525]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
zeehond
Member [заблокирован]

Откуда:
Сообщений: 2535
AlexeiK
ребят, почитал последнюю страницу, да вам реально, быдлокодинг.
картинки уже соотвестующии стали появлятся, как раз для рабочего, который не думает, а тупо шпоняет гвозди в доску.

фу позор.
спустили хорошо завершенную тему, в полный шлак.


AlexeiK, вы не догоняете
картинка отнюдь не для рабочего, "который не думает"
а вовсе даже для руководителя стройки, который как раз очень хорошо думает и выбирает - каким инструментом снабдить рабочих для их наилучшей производительности
13 июн 12, 17:46    [12709661]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13631
softwarer
Допускаю, что такое может возникнуть при рефакторинге очень-старого-и-плохого-чужого-кода, но у меня всегда получалось наоборот: сначала понял, что есть некая структура данных (объект, итп), потом развивается api работы с ним.
Мне не всегда на этапе проектирования удаётся сразу продумать структуру всех объектов. Некоторые вещи приходится добавлять "на ходу", по мере написания. Несколько методов с одинаковым набором параметров явный кандидат на такой рефакторинг. Конечно - это не единственный способ, а один из многих. :-)
13 июн 12, 17:48    [12709676]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
sphinx_mv
Member [заблокирован]

Откуда:
Сообщений: 1672
zeehond
sphinx_mv
Дисциплина нужна разработчику, а не молотку, которым он забивает гвозди... Или Вы предпочитаете гвозди бить мобильным телефоном?


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

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

Хранение текста запросов в приложении, а не на сервере БД в виде представлений и хранимых процедур - прошлый век, однако...
Сразу вспоминаются дбф, парадокс, акцесс, фокспро, "файловые БД", каменные топоры и охота на мамонтов...
zeehond
им забивать гвозди намного быстрее, и получается ровнее

Ну, как "быстро", и, тем более, насколько "ровно" Вы забиваете гвозди Ваши примеры уже продемонстрировали...
С мусором на производственной системе.
zeehond
ну а вы, уважаемый пациент, предпочитаете старомодный молоток, напропалую хвалите своё умение им владеть, и придумываете 100500 причин, почему молоток лучше промышленной гвоздезабивалки

Вам просто (очень мягко) намекают, что закручивать гвозди отверткой сложнее, чем забивать шурупы молотком.
zeehond
возможно в паре мест забивалка не дотянется и нужно таки будет достать ваш молоток
но вы же предлагаете своим молотком делать вообще всё, включая и шурупы и гайки

Тогда можете добавить себе строку в резюме - сопровождением и обслуживание информационных систем не занимаюсь...

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

Ну, и обратно к теме "преимуществ ООП" - кланц
13 июн 12, 18:16    [12709865]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20318
Алексей К
softwarer
но у меня всегда получалось наоборот: сначала понял, что есть некая структура данных (объект, итп), потом развивается api работы с ним.
И этот объект "кочует" между методами, содержащими логику по его обработке. Как правило удобнее передать ссылку на весь объект, чем перечислять в параметрах методов все его поля.
Ага. Страуструп в "Дизайне и эволюции C++" так и ответил на вопрос, будут ли в C++ когда-нибудь именованные аргументы функций, чтобы много параметров удобно передавать. Не будет такого, ибо удобнее запинать один объект "потолще".
13 июн 12, 18:43    [12709993]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13631
sphinx_mv
Ну, и обратно к теме "преимуществ ООП" - кланц
Не понравилось.

Тут одно нытьё за "динамическое мышление". Перечисляются только недостатки, а преимущества умалчиваются, как будто их и не было. Ежу понятно, что строгая типизация требует от программиста некоторых усилий, но и даёт определённые преимущества.
автор
Я уверен, что ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, лишь тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой
Странная аналогия. Удивило, что автор путает понятия аксиомы и теоремы.
автор
Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы приходите к тому, что вы в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг — из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле».
А как развивать алгоритмы, если не понятно с какими данными они будут работать. Это всё равно, что сначала написать хранимые процедуры, а потом сделать структуру таблиц в БД.
автор
«ООП ради самой ООП уже давно превратилось в замкнутый круг. Конечно, можно считать C# в .NET 3.5 с более чем 50,000 реализованных классов „венцом эволюции“. Добавить в следующей версии .NET ещё миллион классов — что может быть более правильным и более вожделенным, с точки зрения ООП-программиста? Говорите, это и есть то самое бегство от сложности?» (на этом месте интервью Ричард демонстративно делает паузу и выкашливается от приступа смеха).
10 000 000 методов, никак не сгруппированных в классы, конечно, были бы удобнее.
автор
Наследование — это самая большая провокация в индустрии. Ни в каком моделировании наследования не существует (и в реальной жизни его нет тоже) — ни в электронике, ни в бухгалтерии, ни в политике, ни где бы то ни было еще. Есть лишь одна область, где наследование теоретически встречается — генеалогия (эй, парни, лучше не путать это с гинекологией). Но это не имеет ни малейшего отношения к тому, что называется наследованием в программировании. Все эти многоэтажные иерархии классов только усложняют жизнь программиста, вместо того, чтобы упрощать по своему замыслу.
Сомнительное утверждение. В любом случае, от неправильно применённого инструмента всегда вред.
автор
ООП — не более чем тривиальная надстройка над структурным программированием
Я бы назвал структурное программирование частным случаем ООП.
14 июн 12, 06:59    [12711150]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13631
Диагноз: у автора запоздалый кризис среднего возраста. :-)
14 июн 12, 07:02    [12711153]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 54505
Блог
Алексей К
автор
ООП — не более чем тривиальная надстройка над структурным программированием
Я бы назвал структурное программирование частным случаем ООП.

Меня восхищает, сколько человек в современном мире рассуждает о структурном программировании, вообще не понимая, что это такое.
14 июн 12, 09:03    [12711403]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Mishau
Member

Откуда: Россия
Сообщений: 355
Про аксиомы, что вытекают из доказательств - бред какой-то.
14 июн 12, 09:12    [12711437]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
iv_an_ru
Member

Откуда: Новосибирск
Сообщений: 20318
Ares_ekb
Очень обнадеживающе выглядит Vertica, но пока не получилось увидеть ни комьюнити, ни триальную версию.
Прям на главной странице сайта ссылочки, если что. Уж что-что, а впаривать HP умеет хорошо, как зарегистрируетесь, так качественным спамом в виде приглашений на рекламные вебинары вы будете обеспечены надолго.
14 июн 12, 09:46    [12711598]     Ответить | Цитировать Сообщить модератору
 Re: Переход с шарпа на яву  [new]
Алексей К
Member

Откуда: Новосибирск
Сообщений: 13631
softwarer
Алексей К
пропущено...
Я бы назвал структурное программирование частным случаем ООП.

Меня восхищает, сколько человек в современном мире рассуждает о структурном программировании, вообще не понимая, что это такое.
Не важно что это означало когда-то для кого-то. Важно что это означает сейчас и для нас. :-)
14 июн 12, 10:02    [12711683]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 14 15 16 17 18 19 20 21 [22] 23   вперед  Ctrl
Все форумы / Работа Ответить