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

[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С, а уж тем более для независимой среды разработки, которую как говорят ваши коллеги скоро начнут с руками отрывать на международном рынке, не ограничивается учетными задачами. И такие понятие как Документ и Регистр уже не будут являться в них основополагающими.

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

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

[brahma]

Цитата:

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

1С заточена для решения довольно узкого круга учетных задач...

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