Цитата:
Сообщение от
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
Культуру надо развивать...одной технологической платформы мало для написания качественных прикладных решений...А для этого нужна методология, правила, жесткая сертификация решений и т.д и т.п.
Не спорю, и отметил в своем исходном сообщении, что проблема сейчас ключевая не в платформе, а в специалистах.