Показать сообщение отдельно
Старый 17.12.2010, 19:25   #14  
SolNik is offline
SolNik
Участник
 
58 / 36 (2) +++
Регистрация: 22.10.2003
Цитата:
Сообщение от 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 относительно других платформ.
Культуру надо развивать...одной технологической платформы мало для написания качественных прикладных решений...А для этого нужна методология, правила, жесткая сертификация решений и т.д и т.п.
За это сообщение автора поблагодарили: sukhanchik (2).