Вроде как нет  . Если да, то просьба привести пример.


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

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

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

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

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


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

Это сообщение отредактировал(а) Zloxa - 6.6.2011, 10:58

Тут я с тобой согласен   


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


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


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


Может через bpl что-то отдалённо подобное и можно реализовать, вот только они чего-то не прижились. А через dll всё это выйдет такими геморроями, что и расширяемости не захочется   


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

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


Да. Много мух не может ошибаться. Это тезис.   


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


Я о том, собственно, и толкую. Полезность продемонстрированного тобой подхода - сомнительна.


Тут ты не прав. Очень даже прижилось, даже сильнее чем следует, со всеми вытекающими. А вытекает, поверь мне, столько, что только успевай подтирать.   

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

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

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

Это сообщение отредактировал(а) Zloxa - 6.6.2011, 12:50

От синтаксиса C, C++, C# в глазах рябит. Я имел ввиду от этих всех скобочек. Я смотрю на код C# и вижу, что несколько строчек кода приходтся размазывать на пол экрана по вертикали и горизонтали, чтобы код был более мнее читалбельным и нормально воспринимался мозгом.

Тогда я не понимаю в чём проблема? Какая им разница что эксплуатировать, они всё равно не понимают что там


Тут, имхо, дело в другом. Сложный софт стоит очень дорого, простой софт - очень дёшево или вообще ничего не стоит. Но разрабатывать сложный софт очень тёжело, и чтобы пойти на его разработку нужно много чем вооружится: хорошая среда разработки, хороший набор библиотек, хороший набор паттернов и возможности системы их использовать, ну и список можно продолжать... .net + vs + m$ даёт набор куда покруче чем делфи. Или фирма, которая за ним стоит


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


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


Ну а тебя это удивляет?  Это было бы идеально, если бы мы в точности обладали знаниями всех требований, но: 
требования заказчика могут меняться даже во время разработки, 
зачастую заказчик хочет несколько новых фич, когда система готова, 
софт нужно развивать


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

Добавлено через 2 минуты и 13 секунд

Это дело привычки. Мне наоборот Делфи кажется расфуфыренным и мало информативным   

  
И окажется она где-то в районе стыка. При накате версии кто-то где-то накосячил. Опыт показывает что 80% говна сочится именно в местах стыков. ))

То то и оно, что я так понимаю, этот опыт с Делфи. А вот эти "стыки" в .нете очень хорошо продуманы и проблема несостыковки весьма незначительна. Вот за что мне и нравится .нет, что ты можешь сконцентрироваться на разработки функционала, а всю срань за тебя делает инфраструктура .нет. Однако, среди делфистов находится много умников, которые считают, что они будут управлять памятью лучше чем это делает GC и  реализовывать прочую "крутизну" которая уже реализованная грамотными разработчиками серьёзных компаний. Однако эти навороченные делфисты считают что они всё сделают лучше. Вот откуда это говнище и течёт   

Это сообщение отредактировал(а) Rohoss - 6.6.2011, 13:35

В чем же выражается расфуфыренность и малоинформативность?

Добавлено @ 14:13
ты просто хотел сказать что-то плохое, но нужных слов не нашёл   ?

Добавлено @ 14:14

Я ПОНЯЛ         в  дотнте стыки - это самое главное ,чтобы ### не сочилось  

Добавлено @ 14:15
Потому что там его столько, что программы на дотнете тормознутее. Вот у меня программа Samsung Kies, мне непривычно с ней работать, т.к. она подторможивает.

Добавлено через 5 минут и 13 секунд
даже при том, что проц двухъядерный и памяти 2 гига

  
  


Я сейчас говорил ни о делфи, ни о доднете. Я сейчас говорил исключительно о подходе. И целью имел не что либо дискредетировать, а предупредить и уберечь, заставить задуматься, скорректировать свою позицию относительно полезности универсальности. В профильных разделах я постоянно остерегаю новичков от использования EAV - с первого взгляда офигенно универсальной концепции хранения данных. Однако фиг кто убережется. Все предпочитают отгрести самостоятельно. Зато потом таки безумно приятно читать нечто вроде "А Злоха таки был прав - через это таки надо пройти", от своих былых опонентов.

Ещё один считающий что .нет тормозит


Хочешь на делфи программу которая будет тормозить на 10Гб оперативы?


Это когда уже нечего сказать   


В том, что место {} пол экрана занимают begin end :bed но думаю эту тему развивать не стоит, так как у каждого свои предпочтения. Я лишь хочу сказать, что привыкше к синтаксису C# делфистский синтаксис кажется плохим...


Похоже приехали    Решили что это и нафиг не надо, ну понятно, раз не можем - значит это никому не надо  . Главное себя хорошо убедить в этом  

Добавлено через 5 минут и 26 секунд

А я говорю о делфи и о дотнете, и говорю о том, что в местах в которых в делфи течёт говнище в дотнете всё прекрасно работает


При чём тут универсальность?   Я говорю о модульности

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


Мне показалось, или ты уже припомнил что bplками предложенный тобой подход реализуется просто и не принужденно. Подход схожий,решения схожи. Проблемы - одинаковы. И, в своей сути, не имеют отношение к платформе. Исключительно к паттерну проектирования.

Это сообщение отредактировал(а) Zloxa - 6.6.2011, 15:13

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


Возможно наши с тобой понятия об универсальности не совпадают. Я не считаю что я создал универсальный калькулятор, я считаю что я создал расширяемый калькулятор. Да, и я полагаю что это удобно. Может это и по неопытности, но видишь ли, я использовал подход (точнее подобии шаблона подхода), который используется разработчиками мирового уровня. По большому счёту это не моё изобретение (как в делфи постоянно изобретают велосипед) и поэтому обвиняя меня в неопытности - ты обвиняешь в неопытности специалистов которые создали эти паттерны, поздравляю   

И потом, никакого "унифицированного интерфеса" я не создавал. Это всё с делфи. В .нете это просто интерфейс. И "унифицированный" от слова уникальный а не универсальный.

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

Ну и на счет аппеляции к мировым бестпрактис.... Сразу чувствуется, мало тебе доводилось в них окунатсья  

Добавлено через 4 минуты и 21 секунду

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

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


Не о том ли что не нужно использовать петтерны для написания hello, world? Или о том что слишком много свободы - это зло? Это всё мы знаем  


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