позволю себе аргументированно вам возразить (очередное сравнение с 1С)

[kuntashov]

**** выделено отсюда Промежуточные итоги 1С ****

Цитата:

Сообщение от SolNik

Покрывающего по функционалу НАВ или Аксапту (простой показатель - количество таблиц в БД. Аксапта - больше 3000, УПП (справочники+документы) - меньше 600).

Кажется, количество таблиц в БД (безотносительно того, о какой системе идет речь) некорректно использовать в качестве аргумента в пользу преимущества функционала (как по количеству, так и по качеству).

Цитата:

Сообщение от SolNik

Об одной из причин я уже писал как-то. Самобытная структура метаданных 1С,

Что вы понимаете под "самобытностью"? В NAV или Ax структура метаданных не "самобытна"?

Цитата:

Сообщение от SolNik

отсутствие ООП, не позволяет при проектировании сложного, глубоко взаимосвязанного функционала полноценно использовать паттерны,

Вы конечно же знаете, что ООП и "паттерны проектирования" - вполне себе независимые области знания, и отсутствие ООП ни коим образом не отменяет возможности применения паттернов проектирования, как на уровне "кода", так на уровне архитектуры.

А по поводу ООП... Если вы адепт этого подхода, то вас наверняка уже задолбали фанаты хаскела, скалы и прочей функциональщины, разве нет?

Если у вас есть минутка, ответьте мне, как специалист, какие принципы ООП наиболее часто применяются вами на практике? Какие при этом с помощью этих принципов проблемы решаются?

Цитата:

Сообщение от SolNik

методики, наработанные за десятилетия в области инженерии ПО.

Архитектура "клиент-сервер", взаимодействие с СУБД через ORM-слой, декларативный язык запросов, декларативная система описания отчетов (СКД) - разве это не примеры использования в 1С "методик, наработанных за десятиления в области инженерии ПО"?

А встроенные открытые средства интеграции с другими приложениями, поддержка открытых протоколов XDTO, SOAP? Средства сериализации в XML? COM? Кросс-платформенный NativeAPI для разработки внешних компонент?

Или я не правильно вас понял и вы имеете в виду что-то другое?

Цитата:

Сообщение от SolNik

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

Кажется, это не является исключительной спецификой для 1с-ников. Среди технарей и программистов описанная вами черта очень часто встречается. 1с-ники просто такие же .

Наводящий на понимание моей мысли вопрос (отвечать не обязательно): вы уверены, что тот же самый специалист, который наделал костылей в 1С, переориентировавшись внедрять Ax, вдруг изменит себе и начнет разбираться, как там все устроено, чтобы внедрить типовой функционал?

Возможно, вы имели в виду то, что среди специалистов 1С такое можно чаще такую ситуацию встретить.

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

Да, это показательно, и именно это, по моему мнению, главная проблема и фирмы 1С и профессионального сообщества 1С, а уж никак не технологическая отсталость платформы 1С:Предприятия 8.2 относительно других платформ.

[mazzy]

Цитата:

Сообщение от kuntashov

Кажется, количество таблиц в БД (безотносительно того, о какой системе идет речь) некорректно использовать в качестве аргумента в пользу преимущества функционала (как по количеству, так и по качеству).

корректно использовать, если число отличается в разы.
некорректно использовать, если число отличается на проценты.

потому что: информацию хоть так, хоть эдак, но хранить где-то надо. число сущностей-хранилищ дает грубую оценку числа информации.

Цитата:

Сообщение от kuntashov

Наводящий на понимание моей мысли вопрос (отвечать не обязательно): вы уверены, что тот же самый специалист, который наделал костылей в 1С, переориентировавшись внедрять Ax, вдруг изменит себе и начнет разбираться, как там все устроено, чтобы внедрить типовой функционал?

Уверен. И мало того - убежден. О чем неоднократно говорил.
Это феномен 1Сников. Из-за которого типичного 1Сника нужно обучать на полгода дольше. Люди, пришедшие из других систем, как правило начинают сначала разбираться.

Цитата:

Сообщение от kuntashov

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

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

то же самое относится и к аксапте с навижином, в которых некоторые места в коде (особенно в локализациях) являются антипаттернами.

Цитата:

Сообщение от kuntashov

Да, это показательно, и именно это, по моему мнению, главная проблема и фирмы 1С и профессионального сообщества 1С, а уж никак не технологическая отсталость платформы 1С:Предприятия 8.2 относительно других платформ.

Царь-батюшка хороший, это бояре ему не докладывают

технологическая отсталось - врожденное качество платформы 1С.
(точно такое же как врожденные характеристики франчайзинга)

технологическая отсталось обусловлена ориентацией на "собственные силы", на подчеркнутую "самобытность" и несовместимость с общими ИТ-стандартами.
свой data mining, свой olap, свой интерфейс, свой формат базы данных, свой sql, свой язык запросов, своя система отчетов, своя картографическая система, свой workflow, свой веб и т.п.

Да, они увернулись от гонки http://russian.joelonsoftware.com/Ar...AndMotion.html
да, сейчас 1С напряглась и рванула.
но передовые технологии нужно поддерживать. изо дня в день.

достаточно вспомнить тот же САП.
они придумали свой интерфейс лет 15 назад. Тогда это казалось таким замечательным прорывом. Сейчас это выглядит так архаично.

[kuntashov]

Цитата:

Это феномен 1Сников. Из-за которого типичного 1Сника нужно обучать на полгода дольше. Люди, пришедшие из других систем, как правило начинают сначала разбираться.

Не готов с вами спорить, и даже склонен верить вашему мнению, поскольку у вас есть опыт работы с командами внедренцев 1С, у меня нет опыта работы с командами внедрения Ax.

Но я все же склонен считать, что дело не в системе, а в том, что низкий порог вхождения в "специальность" (программирование 1С) привело к этому "феномену".

Цитата:

несовместимость с общими ИТ-стандартами

О каких "общих ИТ-стандартах" идет речь?

[brahma]

Цитата:

Сообщение от mazzy

корректно использовать, если число отличается в разы.
некорректно использовать, если число отличается на проценты.

Для корректной оценки, неплохо бы было привести корректные числа.

Цитата:

Сообщение от mazzy

технологическая отсталось обусловлена ориентацией на "собственные силы", на подчеркнутую "самобытность" и несовместимость с общими ИТ-стандартами.
свой data mining, свой olap, свой интерфейс, свой формат базы данных, свой sql, свой язык запросов, своя система отчетов, своя картографическая система, свой workflow, свой веб и т.п.

Это вы сейчас про Microsoft и семейство его продуктов Dynamics?

[sukhanchik]

Цитата:

Сообщение от brahma

Для корректной оценки, неплохо бы было привести корректные числа.

Дык ж... приведены:

Цитата:

Сообщение от SolNik

Покрывающего по функционалу НАВ или Аксапту (простой показатель - количество таблиц в БД. Аксапта - больше 3000, УПП (справочники+документы) - меньше 600).

Цитата:

Сообщение от brahma

Это вы сейчас про Microsoft и семейство его продуктов Dynamics?

Тут смысл не в том, что Dynamics смотрит на технологии своего же производителя и это есть хорошо, а в случае с 1С-ом, который смотрит на свои технологии - плохо.
А смысл в том, что есть конкретный продукт (язык SQL в частности или OLAP-продукт), который принят де-факто за стандарт обработки данных в БД (это про язык SQL). Есть OLAP-продукты (и это совершенно не обязательно SQL Server Analysis Services). И если бы 1С не пыталась бы все это заменить на нечто свое, а пыталась бы использовать существующие технологии - она бы гораздо дальше шагнула бы вперед по технологиям. Та же MS не создавала Reporting Services, не создавала SQL Server, не создавала Dynamics AX, NAV. Она все это купила. Просто финансовые возможности 1С несравнимы с MS и она не может себе позволить купить технологии, поэтому нужно давать возможности для интеграции.

Например, смогла же 1С использовать "движок" от Excel для своих отчетов. Это кстати - одно из сильных ее преимуществ. А если бы они писали бы что-то свое и сваяли бы что-то а-ля отчеты в АХ - то они бы не получили этого преимущества, как не получила АХ (из-за чего кстати и затеялась вся эта интеграция с Reporting Services и т.д.)

[kuntashov]

Цитата:

Сообщение от sukhanchik

Например, смогла же 1С использовать "движок" от Excel для своих отчетов. Это кстати - одно из сильных ее преимуществ.

Не очень понятно, в каком месте 1С использует "движок" Excel? Если речь идет о табличных документах 1С, т.е. "мокселях" (mxl), то это не так.

[sukhanchik]

Цитата:

Сообщение от kuntashov

Не очень понятно, в каком месте 1С использует "движок" Excel? Если речь идет о табличных документах 1С, т.е. "мокселях" (mxl), то это не так.

Цитата:

Сообщение от sukhanchik

Например, смогла же 1С использовать "движок" от Excel для своих отчетов.

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

[brahma]

Цитата:

Сообщение от sukhanchik

Дык ж... приведены:

Я заметил, что хорошо бы привести корректные числа.

Цитата:

Сообщение от sukhanchik

Тут смысл не в том, что Dynamics смотрит на технологии своего же производителя и это есть хорошо, а в случае с 1С-ом, который смотрит на свои технологии - плохо.
А смысл в том, что есть конкретный продукт (язык SQL в частности или OLAP-продукт), который принят де-факто за стандарт обработки данных в БД (это про язык SQL). Есть OLAP-продукты (и это совершенно не обязательно SQL Server Analysis Services). И если бы 1С не пыталась бы все это заменить на нечто свое, а пыталась бы использовать существующие технологии - она бы гораздо дальше шагнула бы вперед по технологиям. Та же MS не создавала Reporting Services, не создавала SQL Server, не создавала Dynamics AX, NAV. Она все это купила. Просто финансовые возможности 1С несравнимы с MS и она не может себе позволить купить технологии, поэтому нужно давать возможности для интеграции.

Не очень понятно какая разница куплены технологии или разработаны самими с нуля. Например технология .Net была разработана с нуля при уже имеющейся Java.
ReportService вместо CristalReport, Silvelight вместо Flash и HTML 5, свой сбственный стандарт офисных документов и так далее. Язык запросов в Axapta тоже отличается от стандарта.

Цитата:

Сообщение от sukhanchik

Например, смогла же 1С использовать "движок" от Excel для своих отчетов. Это кстати - одно из сильных ее преимуществ. А если бы они писали бы что-то свое и сваяли бы что-то а-ля отчеты в АХ - то они бы не получили этого преимущества, как не получила АХ (из-за чего кстати и затеялась вся эта интеграция с Reporting Services и т.д.)

Он тоже самовитый. В нем тоже есть возможности, которые не поддерживаются "общими ИТ-стандартами".

[sukhanchik]

Цитата:

Сообщение от brahma

Я заметил, что хорошо бы привести корректные числа.

Скажем так. По 1С я не знаю корректных чисел. Но разница на порядок (если она существует) - роль играет. Как правильно заметил mazzy:

Цитата:

Сообщение от mazzy

потому что: информацию хоть так, хоть эдак, но хранить где-то надо

Цитата:

Сообщение от brahma

Не очень понятно какая разница куплены технологии или разработаны самими с нуля

Разница примерно такая же, как между самопиской на Access-е / Delphi / ... и поставляемым функционалом от 1С / MS / ...
Т.е. когда написано нами - то а) нет широкой распространенности => тяжело претендовать на стандарт и б) высока вероятность частого изменения этих технологий нами (баги/совместимости/усовершенствования и пр.) и как следствие - отсутствие устоявшегося функционала

Цитата:

Сообщение от brahma

Он тоже самовитый. В нем тоже есть возможности, которые не поддерживаются "общими ИТ-стандартами".

Ну не совсем же с нуля его писали

[SolNik]

Цитата:

Сообщение от brahma

Для корректной оценки, неплохо бы было привести корректные числа.

По DAX за эти числа отвечаю ...а в 1С я посчитал количество элементов конфигурации типа Справочник и Документ. Если ошибся - поправьте...

[brahma]

Цитата:

Сообщение от SolNik

По DAX за эти числа отвечаю ...а в 1С я посчитал количество элементов конфигурации типа Справочник и Документ. Если ошибся - поправьте...

Ошибаетесь.

[Reaper]

Все относительно. Представьте картину - внезапно (по воле Бога, или еще какому-то чуду) собираются ведущие специалисты консалтинговых компаний и интеграторов для проектирования функционала прикладного решения, а потом коллектив специалистов уровня "1С: Эксперт по технологическим вопросам" проектируют и реализовывают прикладное решение. И вот, готова бомба. И что? Да ничего - маркетологов нанять забыли. ИМХО нет сейчас проблем с технологиями у 1С. Есть проблема в уровне коллективов разработчиков тиражных решений. А еще есть темные лошадки. Господа, проживая в провинции я таких зверей как "Инталев: корпоративные финансы" и "ИТРП:Процессное производство" даже не видел. Максимум - УПП. А кто-нибудь из вас на тендерах соперничал с ними, переходили с них на продукты MS? Есть хоть какие-то слухи об этих решениях в вашей среде?

[SolNik]

Цитата:

Сообщение от kuntashov

Кажется, количество таблиц в БД (безотносительно того, о какой системе идет речь) некорректно использовать в качестве аргумента в пользу преимущества функционала (как по количеству, так и по качеству).

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

Цитата:

Сообщение от kuntashov

Что вы понимаете под "самобытностью"? В NAV или Ax структура метаданных не "самобытна"?

Под самобытностью я понимаю наличие в среде разработки 1С таких понятий, как Документ, Справочник, Регистр, План счетов и т.п.. И отсутствие таких понятий как класс, таблица, тип данных и т.п....За НАВ не скажу, но в Аксапте среда разработка гораздо более похожа на классические RAD-среды.

Цитата:

Сообщение от kuntashov

Вы конечно же знаете, что ООП и "паттерны проектирования" - вполне себе независимые области знания, и отсутствие ООП ни коим образом не отменяет возможности применения паттернов проектирования, как на уровне "кода", так на уровне архитектуры.

Абсолютно не согласен. Эти понятия не отделимы. GRASP, UML, RUP, рефакторинг - все эти паттерны, методологии в той или иной степени оперируют такими понятиями, как класс и объект.

Цитата:

Сообщение от kuntashov

А по поводу ООП... Если вы адепт этого подхода, то вас наверняка уже задолбали фанаты хаскела, скалы и прочей функциональщины, разве нет?

ФП - это пока андеграунд...имхо мейнстрим в проектировании ПО сейчас по-прежнему ООП.

Цитата:

Сообщение от kuntashov

Если у вас есть минутка, ответьте мне, как специалист, какие принципы ООП наиболее часто применяются вами на практике? Какие при этом с помощью этих принципов проблемы решаются?

Ну принципы используются все (если вы про инкапсуляцию, наследование и полиморфизм) в них собственно суть разработки на ООП языках...кроме того активно использую GRASP и методы рефакторинга.

Цитата:

Сообщение от kuntashov

Архитектура "клиент-сервер", взаимодействие с СУБД через ORM-слой, декларативный язык запросов, декларативная система описания отчетов (СКД) - разве это не примеры использования в 1С "методик, наработанных за десятиления в области инженерии ПО"?

А встроенные открытые средства интеграции с другими приложениями, поддержка открытых протоколов XDTO, SOAP? Средства сериализации в XML? COM? Кросс-платформенный NativeAPI для разработки внешних компонент?

Или я не правильно вас понял и вы имеете в виду что-то другое?

Нет, я не имел ввиду внутренности самой платформы - я про среду разработки 1С (злосчастный ООП )

Цитата:

Сообщение от kuntashov

Наводящий на понимание моей мысли вопрос (отвечать не обязательно): вы уверены, что тот же самый специалист, который наделал костылей в 1С, переориентировавшись внедрять Ax, вдруг изменит себе и начнет разбираться, как там все устроено, чтобы внедрить типовой функционал?

Понятно, что в семье не без урода . Но в DAX это будет сделать сложней .
Тут есть такая замечательная вещь, как Best Practices для разработки. Солидный документик, в котором регламентирован каждый чих разработчика. Причем проверку следованию некоторым правилам Best Practices можно настроить на уровне компиляции. Вплоть до того, что запретить помещать в систему контроля версий элементы, не проходящие проверки Best Practices.
Есть методология внедрения SureStep, которая требует проведения CodeReview старшим разработчиком по всем модификациями...так что такому нерадивому 1С-нику тут будет трудно развернуться .

Цитата:

Сообщение от kuntashov

Да, это показательно, и именно это, по моему мнению, главная проблема и фирмы 1С и профессионального сообщества 1С, а уж никак не технологическая отсталость платформы 1С:Предприятия 8.2 относительно других платформ.

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

[kuntashov]

Цитата:

Сообщение от SolNik

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

Ок. Коллега в этой ветке уже привел цифру, которая показывает, что по данному показателю 1C:УПП не уступает Ax.

Цитата:

Сообщение от SolNik

Под самобытностью я понимаю наличие в среде разработки 1С таких понятий, как Документ, Справочник, Регистр, План счетов и т.п.. И отсутствие таких понятий как класс, таблица, тип данных и т.п....За НАВ не скажу, но в Аксапте среда разработка гораздо более похожа на классические RAD-среды.

1С - предметно-ориентированная среда разработки. Объективно, любая учетная система оперирует названными вами понятиями. Чтобы специалистам раз за разом не приходилось изобретать этот велосипед, их выделили в специальные классы структур данных.

Это просто такая парадигма разработки. Ее назначение - сместить акценты от технологической составляющей к предметной области.

Цитата:

Сообщение от SolNik

Абсолютно не согласен. Эти понятия не отделимы. GRASP, UML, RUP, рефакторинг - все эти паттерны, методологии в той или иной степени оперируют такими понятиями, как класс и объект.

Если в каком-то языке программирования нет понятия "класс" или "объект", это не значит, что программируя на этом языке, нельзя использовать те или иные паттерны проектирования.

Например, в Библиотеке Стандартных Подсистем реализована возможность вывода печатных форм в документ MS Word или в OpenOffice Writer.

Работа с каждым типом документов (Word или Writer) представлена отдельным модулем УправлениеПечатьюMSWordКлиент и УправлениеПечатьюOOWriterКлиент соответственно.

Но в месте с ними, реализован отдельный модуль - УправлениеПечатьюКлиент, который реализует унифицированный интерфейс и скрывает особенность реализации по работе с конкретным видом документов.

Это пример применения паттерна Facade. Я могу привести еще кучу примеров из типовых конфигураций. Применение многих паттернов поддерживается уже на уровне технологической платформы, просто это надо понимать и видеть.

Например, модули менеджеров объектов 1С - ни что иное, как реализация паттерна Singelton.

Цитата:

Сообщение от SolNik

Ну принципы используются все (если вы про инкапсуляцию, наследование и полиморфизм) в них собственно суть разработки на ООП языках...кроме того активно использую GRASP и методы рефакторинга.

Как часто приходится применять на практике наследование и полиморфизм? Приведете примеры?

Цитата:

Сообщение от SolNik

Понятно, что в семье не без урода . Но в DAX это будет сделать сложней .
Тут есть такая замечательная вещь, как Best Practices для разработки. Солидный документик, в котором регламентирован каждый чих разработчика. Причем проверку следованию некоторым правилам Best Practices можно настроить на уровне компиляции. Вплоть до того, что запретить помещать в систему контроля версий элементы, не проходящие проверки Best Practices.
Есть методология внедрения SureStep, которая требует проведения CodeReview старшим разработчиком по всем модификациями...так что такому нерадивому 1С-нику тут будет трудно развернуться .

В среде 1С также накапливаются и применяются Best Practices.

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

Есть база знаний ПрофКейс, которая содержит регламенты, методики управления проектами внедрения, шаблоны документов, кейсы.

Цитата:

Сообщение от SolNik

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

Не спорю, и отметил в своем исходном сообщении, что проблема сейчас ключевая не в платформе, а в специалистах.

[sukhanchik]

Цитата:

Сообщение от kuntashov

Как часто приходится применять на практике наследование и полиморфизм? Приведете примеры?

Ээээ для АХ (в частности) без этого также нельзя жить, как в 1С без написания хоть каких-нибудь процедур/функций

Цитата:

Полиморфи́зм (в языках программирования) — возможность объектов с одинаковой спецификацией иметь различную реализацию.
...
Полиморфизм позволяет писать более абстрактные программы и повысить коэффициент повторного использования кода.

Полиморфизм, как и наследование - позволяет чаще повторно использовать уже написанный код.

Цитата:

Насле́дование — позволяет описать новый класс на основе уже существующего (родительского), при этом свойства и функциональность родительского класса заимствуются новым классом.

Пример. В АХ журналы документов делятся на журналы складских документов и журналы финансовых документов. В свою очередь - журналы складских (равно как и финансовых документов делятся по типу документа. Для склада - это приход / списание / спецификация / инвентаризация и т.д. Для финансов - это клиентские / поставщиковые платежи, журналы для операций с ОСами и т.д.

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

Другой пример. Работа с Excel. Для разных версий Excel (конкретно для 2000, XP и 2007) есть свои классы-наследники, про которых программист может и не знать, однако вызывает он методы общего родительского класса, а там уже на уровне конструирования класса - система сама, в зависимости от версии инициализирует нужного наследника. Без этого было бы неприятно узнать, что код, который работал в 2003-м офисе перестал работать в 2007-м (к примеру).

Конечно - никто не говорит, что без этого нельзя обойтись. Всегда можно создать большой метод (процедуру в 1С) и внутри нее делать кучу if нв предмет - версии, на предмет типа журналов и т.д. Но речь-то идет и максимальном использовании уже написанного кода и (как следствие) уменьшение количества кода в котором нужно разбираться. Собственно для этого и нужны ООП-принципы

[kuntashov]

Цитата:

Сообщение от sukhanchik

Пример. В АХ журналы документов

В 1С, если речь идет о списках документов одного вида - они реализуются декларативно (формы списка конкретного вида документа).

Если речь идет о сводных списках журналов, то для этих целей есть специальный объекты метаданных - журналы документов.

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

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

Приведенный пример не показывает преимущества подхода с наследованием.

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

[SolNik]

Цитата:

Сообщение от kuntashov

Как часто приходится применять на практике наследование и полиморфизм? Приведете примеры?

Я так понимаю, кроме 1С, у вас нет опыта разработки на современных ЯП с поддержкой ООП? Иначе было бы странно слышать такой вопрос...Да вообще, о чем мы спорим? Что процедурные\модульные языки не менее эффективны чем ООП при разработки логики сложных бизнес-приложений, и что эволюция ЯП прошла зря? Ну посмотрите вокруг - даже брутальный PHP обзавелся ООП...
А 1С я думаю намеренно не вводит ООП в свою платформу. Потому, как это увеличит порог входа для разработчиков на этой платформе. Уже на каждый ПТУ-ник сможет сваять простенькую конфу. Отсюда у вас будет вечная проблема:

Цитата:

Сообщение от kuntashov

Не спорю, и отметил в своем исходном сообщении, что проблема сейчас ключевая не в платформе, а в специалистах.

И вообще, имхо, невозможно одинаково эффективно использовать одну платформу для разработки бизнес-приложений для малого бизнеса и для корпораций. Посмотрите на SAP и его BO, на Dynamics и его NAV...1С как всегда идет своим путем...посмотрим на сколько его хватит...

[kuntashov]

Цитата:

Сообщение от SolNik

Я так понимаю, кроме 1С, у вас нет опыта разработки на современных ЯП с поддержкой ООП?

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

Цитата:

Сообщение от SolNik

Иначе было бы странно слышать такой вопрос...

Вы просто не поняли его подоплеки.

Цитата:

Сообщение от SolNik

Да вообще, о чем мы спорим?

Я не спорил. Кажется, я вопросы задал, разве нет? Я пытаюсь понять, в чем преимущество, скажем так, "пути Ax", в чем его недостатки, и соответственно, в чем преимущества "пути 1С", и в чем их недостатки.

Для этого пытаюсь узнать, как те или иные задачи решаются средствами Ax, чтобы сравнить с тем, как решаются в 1С. Вы сказали, что для решения используются "полиморфизм, инкапсуляция, наследование" и что преимущества очевидны.

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

Цитата:

Сообщение от SolNik

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

Нет, я не утверждал этого.

Но, кажется, что оба пути (Ax и 1С) различаются в том, что Ax предоставляет более низкоуровневые средства разработки (таблицы вместо ORM, ООП со всеми его вкусностями вместо слоя с готовыми классами объектов, "заточенных" под решение учетных задач определенного класса и т.п.).

Это просто другой подход к решению тех же самых задач. Да, очевидно, что более низкоуровневые средства Ax - гибче. Но да, очевидно, более высокоуровневые средства 1C позволяют быстрее вести разработку. В таком ключе я продолжать дискуссию готов.

Цитата:

Сообщение от SolNik

Ну посмотрите вокруг - даже брутальный PHP обзавелся ООП...

Язык 1С не является самодостаточным и неотделим от технологической платформы. Он императивен и его предназначение - манипуляция объектами технологической платформы.

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

Цитата:

Сообщение от SolNik

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

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

Цитата:

Сообщение от SolNik

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

Речь идет о технологической платформе? С точки зрения сопровождения наоборот как раз удобнее поддерживать одну платформу.

А вот уже решения на этой платформе позиционировать в соответствующих сегментах. Но у 1С все так и есть: Управление небольшой фирмой и УПП, Бухгалтерия предприятия 8 и Бухгалтерия предприятия КОРП.

[SolNik]

Цитата:

Сообщение от kuntashov

Но, кажется, что оба пути (Ax и 1С) различаются в том, что Ax предоставляет более низкоуровневые средства разработки (таблицы вместо ORM, ООП со всеми его вкусностями вместо слоя с готовыми классами объектов, "заточенных" под решение учетных задач определенного класса и т.п.).

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

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

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

[Сисой]

В УПП прримерно 3700 таблиц.