Тенденции современного программирования. Плюсы vs Минусы

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

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

В этом их прелесть.

Работу же связанную с поддержкой клиентских приложений никто никогда не отменит. Надоело поддерживать кучу различных платформ - используйте Java.

 

эээх-хе-хе. никому никакие тенденции не нужны.
вот "Мп3 обрезать" или "в Delphi вырвать имя из имени" другое дело. :D

 

Это к вопросу о том, есть ли в Волгограде современное программирование. Кто-то утверждает, что есть (но про него никто не знает), кто-то утверждает, что нет, и доказывает, что это правда. Так есть или нет? Вот в чем вопрос.

 

А разве есть какая-то альтернатива? Пожалуйста приведите ее. Так, что бы она удовлетворяла требованиям многоплатформенности, невысоким требованиям к транспорту. Хотя бы только эти.

 

"Это к вопросу о том, есть ли в Волгограде современное программирование"
не-а. Ваши слова нужно перефразировать, заменив Волгоград на forum.volgograd.ru.

"Пожалуйста приведите ее. Так, что бы она удовлетворяла требованиям многоплатформенности, невысоким требованиям к транспорту"
1. действительно ли стоит проблема многоплатформенности в пределах одной компании?
2. утверждение про невысокие требования к транспорту неверно.

AlTk добавил [date]1107347697[/date]:
а про Волгоград могу сказать, что есть и тендеции и современное программирование.

 

Что-то в моих предыдущих постах идет в разрез с этим утверждением?

Непонятно, чем xml, в данном контексте, лучше html? Почему с xml будет по -другому? Если разные браузеры по-разному рендерят одни и те же html-страницы, тоже самое будет и с xml. А в веб-сервисах, он, вообще, для других целей.

Вот это по-моему - заблуждение. Вырастет размер по сравнению с чем? По сравнению с html - с какой стати? С бинарными форматами - да, несомненно. Ну, так, это и не его епархия. По-моему, этот миф появился, когда, на волне моды, его стали засовывать туда, где ему не место. Как-то хранение и передача больших объемов данных. Отсюда и рассказы про немерянные тормоза и жручесть xml`ых парсеров.

Я в курсе, что такое WebServices. Но почему же иная? По сути, та же самая - появление новой платформы и необходимости иметь клиента на ней.

Java, .NET. Какая разница... Поменялась цифирь в версии и вперед - на мины.

Касательно веб-сервисов. Моё IMHO.
Попытка обобщить, унифицировать доступ разных клиентов (в широком смысле) к ресурсам удаленных приложений, сервисов. Идея хорошая. А как реализуется? Свалили в кучу клиент-серверную архитектуру, RPC, веб-технологии, взгромоздили на старый транспорт, добавили еще кучку новых спецификаций, чтоб не рассыпалось по дороге. Плюс новые средства разработки. А по сути? Притянули за уши к вебу, загримировали под объектность и заменили один язык разметки другим.
Опять же http. Он хорош там, для чего он придуман - передача гипертекста. Аргумент, что "везде есть и везде пролезет" как-то не перевешивает его недостатков в новом применении. Особенно, с учетом общей паранойи по поводу спама/вирусов/spyware/etc (это я про контент-фильтры, блэк/грей-листы и прочие антивирусы).

Несоответствие целей, средств и результата создания технологии наводит на мысли, что нужно все это только маркетоидам и разным "комитетам по выработке ...".
Заявлено, что используется много существующих, обкатанных технологий. Что должно снижать издержки внедрения. Хороший инженерный подход. Но на практике, переделывать надо все. Переделывать архитектуру. Переписывать и клиентскую, и серверную части. Кто от этого выиграет, кроме продавцов нового инструментария/технологий? Ничего принципиально нового эта технология не даёт, притом, что специализированные решают задачи лучше.
Где-то лучше применимы обычные CS системы, где-то веб и т.д. Если приложение решает какие критичные задачи, вряд ли кто-то будет пользоваться услугами сервиса "с трубки по http через кривой прокси опсоса". Будет и спец. клиент, и надежный канал. И там веб-сервис - ненужный оверхед. Если это какая-то массовая услуга - там нужен веб (браузер есть у всех, а клиента еще скачать надо. Хотя на сервере обработка будет идти схожим образом).
Короче говоря, как всесезонные шины. Задумка хорошая, а, по жизни, одинаково хреново и зимой и летом.

P.S. Топик вдруг ожил. Новые вопросы.

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

 

У одной компании одна платформа, у другой другая, у третьей их вовсе может быть три!!! Для компании-разработика программного обеспечения многоплатформенность прежде всего проявляется в "многоклиентности". Мы ведь говорим о тенденциях в профессинальном программировании?

 

Браузер примитивный, не обладает необходимыми элементами управления. Это был только один из примеров.

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

:D

 

1 Гость,
а чем Вас не устраивает протокол TCP/IP в случае многоклиентности?

2 Гость,
у Вас несколько неправильные представления о нефтяной отрасли.

 

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

форум есть отражение реальности Волгограда. Кривое или не очень, это уже второй вопрос. На форуме были утверждения, что ничего тут нет, поскольку нет СЕРЬЕЗНЫХ фирм разработчиков ПО и отделы разработки в государственных или нефтяных или каких-то иных компаниях тут не в счет. Тогда можно перефразировать вопрос: есть ли в Волгограде серьезные компании или люди, которые занимаются серьезным и современным программированием?

Поделитесь знаниями.

 

у Вас некоторые проблемы с логикой:

как связаны утверждения "тенденции современного программирования избыточны" - то есть не нужны и утверждение "могут позволить"?

"форум есть отражение реальности Волгограда. Кривое или не очень, это уже второй вопрос"
это вопрос первый - если Вам дать "кривую" карту Вы наверное откажетесь прокладывать по ней маршрут, не так ли?

"Тогда можно перефразировать вопрос: есть ли в Волгограде серьезные компании или люди, которые занимаются серьезным и современным программированием?" таки непонятно, с учетом "отделы разработки в государственных или нефтяных или каких-то иных компаниях " или нет.

можно я за Вас попробую перефразировать вопрос: "есть ли в Волгограде фирмы, профессионально занимающиеся разработкой ПО на заказ, и какого уровня их профессионализм". Вы это хотели сказать?

ПС. "Сейчас AlTk может поплакаться..." - это утверждение и моя скромная персона вобще какое отношение имеет к обсуждаемой теме?

 

Согласен

Добавлю второй вопрос. Есть ли отделы и/или люди в государственных, нефтяных и прочих компания занимающиеся серьезным и современным программированием.

 

ответы будут такими, опять же, насколько мне известно.
1. нет. (хотя все может быть - может они себя не афишируют, мне вот в свое время довелось в такой конторе поработать);
2. есть.

 

Гость

Да, есть. При чем уровень зарплат нередко на уровне московских. Раскрывать имена не буду. Давайте может уже про тенденции?

 

Гость

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

 

Она переживет отсутсвие этого специалиста. Она также может позволит себе взять двух похуже. У крупной компании много резервов, мощная кадровая служба, которая занимается комплектованием подразделений по принципу крупной компании.
Кроме того крупным компаниям практически всю работу производят подрядчики с которыми имеются договра на техобслуживание и пр. Вообще, это уже вопросы управления производством. Я тут пас.

 

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

"... Всеми нами любимые веб-сервисы, тоже поверх TCP, ..."
а веб-сервисы может мной как раз и не любимые. может мне больше .NET Remoting нравится.

про то, что вебсервисы несут ОО логику тоже не согласен на 100%. один из частных случаев - это stateless объекты - как бы не совсем ОО логика. сервис - он и есть сервис.
в случае с СУБД тоже не все однозначно, несмотря на то, что продвигается OCL, все равно до сих пор реляционные СУБД сильны, в отличие от ООСУБД и ОРСУБД.
даже если сказать, что ООСУБД не распространены пока из за недостатка мощности серверов, как это в свое время было с РСУБД, то это тоже будет не совсем верным. в отличие от ООСУБД за РСУБД стоит солидный многолетний математический аппарат.
но вообще с тем, что ООП тенденция, я согласен.

"Хотелось бы спросить, кто-нибудь использует для проектирования UML."
да, используют:
Use case
Activity
Deployment
Class
Sequence
Component
однако кроме этих еще используют и диаграммы стандарта IDEF1X .
и еще, если внимательно присмотреться к диаграммам UML, то можно заметить, что диаграммы Use case и Activity, в отличии от других имеют очень слабое отношение к ООП. так что тенденции предстоит пройти еще долгий путь.

"Еще интересно как обстоит дело с образованием в Волгограде в области UML"
я бы изменил этот вопрос так: "Еще интересно как обстоит дело с образованием в Волгограде в области ИТ", а ответ дал такой: "к моему великому сожалению очень и очень плохо".

 

Это как сказать. Точнее как спроектировать. Например, сервис покупки книги в магазинах А и B, с одного портала книг. Магазин A принимает к оплате кредитную карту, магазин B использует Web-Money. Сервис должен реализовывать различные механизмы биллинга. Вот вам и наследование и полиморфизм.

А вот какое влияние на ООП оказывает поддержка состояния я, честно, не понял. Может это описка?

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

Согласен, что эти диаграммы не моделируют напрямую объекты в смысле ООП. У них назначение другое. Но именно эти диаграммы позволяют усмотреть будущие классы и перейти к диаграмме классов.

А специализированные учебные центы имеются?

 

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

"что реляционных баз данных слишком много (и к ним привыкли"
не согласен. для РСУБД много математического аппарата и доказательной базы.

"позволяют усмотреть будущие классы" согласен, но ведь используя IDEF0 тоже никто не мешает усматривать эти самые классы.

"А специализированные учебные центы имеются?"
угу, один - филиал АйТи.

 

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

P.S. Я не знаком с .NET. Может это особенность именно этой платформы. В J2EE с этим проблем нет.

 

давайте я приведу пример. Вот так Вы можете написать:
MyObj := CreateObject(MyClass);
MyObj.Init(Name);
MyObj.Size := Size;
MyObj.Save;
MyObj.Free;

или Вы пишете так

MyObj := CreateObject(MyClass);
MyObj.SaveInfo(Name, Size);
MyObj.Free
при условии выполнения MyObj на сервере.

в первом случае объект statefull, а во втором stateless.

AlTk добавил [date]1107418092[/date]:
а Вы с 7 до 10 до работы добирались?

 

Похоже что Вы путаете персистентность с поддержкой состояния.

 

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

ПС. причем здесь .NET? это понятие существует безотносительно платформы.

 

OK.

Кажется даже разобрался с вашим примером (если MyObj.Save вызов метода без параметров).
Теперь возвращаемся к

В вашем примере про stateless:

myObj.saveInfo(bla,bla,bla);
Вы все равно работаете с объектом, а не с функцией. Метод saveInfo может быть и полиморфным, то есть в Вашем примере будет зависеть от метода createObject().

 

" Вы все равно работаете с объектом, а не с функцией "
а вот и ошиблись. _клиент_ работает с компонентом, которые предоставляет сервисы. если бы клиент работал с объектом, то он бы работал так как я указал в случае statefull.
т.е. если мы используем шаблон MVC, то контроллер _не может быть_ на сервере, то есть мы _прикручиваем_ объектность к выбранной архитектуре.

"Метод saveInfo может быть и полиморфным" да никто и не спорит, но ООП это не только полиморфизм, это и наследование и инкапсуляция. где в моем примере инкапсуляция?

AlTk добавил [date]1107429074[/date]:
т.е. можно сказать, что вебсервисы это не объектно-ориентироанное программирование, а компонентное программирование.

 

Ладно, начнем с начала:

Где тут переменная компонентного типа?

Не понял что написано. Пока оставим, потом вернемся к этому.

Полиморфизм, естественно, подразумевает и наследование. (именно полиморфизм, а не перегрузка (overload) метода).

А кто вам мешает определить поля у объекта MyObj во втором примере? А то что никто не поручится за их значения от вызова к вызову - это вопрос третий.

 

так, если Вы не знаете, что такое шаблон MVC,
считаете, что полиморфизм естественно подразумевает наследование
и считаете, что сохранение значения переменной от вызова к вызову вопрос третий и называете это инкапсуляцией, то
у меня больше нет особого желания беседовать с Вами.

ПС. можете думать про Волгоград что угодно.

 

Во первых, не Вам меня учить, что такое MVC. Во вторых, если в фразе

есть хоть какой-нибудь смысл то я идиот.

В третьих,

Вы спекулируете. И не ответили на мой вопрос

И, наконец, в четвертых,

Слишком выского о себе оговорите - Волгоград.

 

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