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

[Reaper]

Щас нам начнут про плохую нормализацию БД долбить...

[Lemming]

Цитата:

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

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

[off]Scala гибридный язык, там с ООП все более чем в порядке.[/off] А что касается Х++, то все его объектно-ориентированные преимущества существенно теряются из-за практически полного отсутствием документации по основным прикладным модулям. А в локализации в некоторых случаях это особенно бросается в глаза, кто разбирался, например, с RLedgerSheet* или копался в коде с магическим заклинанием ANVA inventory reports тот поймет о чем я

upd: А еще всегда веселит как тут на форуме многие любят вспоминать про паттерны, ООП и прочие эфемерные понятия. Или я один такой "везучий", или те товарищи, которые про это рассуждают, редко копаются в коде соседей по кабинету, да и вообще в чужом коде написанном не в стенах микрософт. Потому как там, картинка резко меняется...

[Raven Melancholic]

Цитата:

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

Щас нам начнут про плохую нормализацию БД долбить...

С чего бы вдруг? По отношению к 7.7 это было бы справедливо (как хранились периодические реквизиты, отборы, документы напоминать, думаю, не нужно). В восьмерке с этим все в порядке.
С точки зрения выхода на зарубежные рынки, на мой взгляд, проблема 1С в том, что для каждого их этих рынков 1С делает свою конфигурацию, а не общую, с возможностью настройки под конкретную страну (отставание тех же конфигураций для Украины от аналогичных Российских конфигураций заметно). Хотя, если смотреть на появление так называемого "управляемого приложения", что-то у 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]

Цитата:

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

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



Например, QuickBooks. Я уж не знаю на чем эта самописка написана, но вроде как стандарт де-факто для бухгалтерских программ в США и Канаде.


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



Думаете выкрали исходники Exel'я из Редмонда?

Цитата:

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

Ошибаетесь.

Цитата:

Сообщение от Сисой

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

Не уверен что в 1С с ее ORM-ом корректно оперировать физическими таблицами в БД. Как я писал выше, для анализа сложности системы можно сравнивать количество и связи между классами-сущностями. В Аксапте ими являются объекты метаданных типа таблица. В 1С - справочники, документы, планы счетов, регистры...Ну про таблицы я написал навскидку, что пришло в голову...По функционалу тут уже не раз пытались сделать battlecard, но они явно не отличались объективностью, ввиду заинтересованности обеих сторон ... По-моему опыту, с чем я сталкивался и там и там - планирование потребностей и ценообразование (не в смысле расчета цен а в смысле их настроек) в Акс гораздо навороченей.

[SolNik]

Цитата:

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

А что касается Х++, то все его объектно-ориентированные преимущества существенно теряются из-за практически полного отсутствием документации по основным прикладным модулям.

Если вы про документацию к коду, то хочу заметить, что одним из принципов ООП является написание самодокументируемого кода. Ну и помимо самого ООП весь BP направлен на это. А по базовым классам типа InventUpdate или LedgerVoucher документация есть.

Цитата:

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

А в локализации в некоторых случаях это особенно бросается в глаза, кто разбирался, например, с RLedgerSheet*

А что, нормальный класс, не иделаьный конечно, но мы на проектах часто делаем от него наследников для реализации оборотки по банку и кассе. Хороший пример реализации паттернов Polymorphism, Low coupling, High cohesion и разделения логики и представления. "Вы просто не умеете их готовить"

Цитата:

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

upd: А еще всегда веселит как тут на форуме многие любят вспоминать про паттерны, ООП и прочие эфемерные понятия. Или я один такой "везучий", или те товарищи, которые про это рассуждают, редко копаются в коде соседей по кабинету, да и вообще в чужом коде написанном не в стенах микрософт. Потому как там, картинка резко меняется...

Можно интимный вопрос? Вы работали(работаете) когда-нибудь у партнера? В скольких проектах вы участвовали?...Мы на своих проектах (компания-партнер) четко следуем методологии и всегда есть выделенный Senior Developer, который жестко пресекает всякие антипаттерны и smell code. И эта практика в большинстве случаев продолжает поддерживаться клиентами в своих командах.

[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 и Бухгалтерия предприятия КОРП.

[konopello]

Цитата:

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

честно сказать я настолько привык к ООП и насмотрелся на задачи которые решались без него (слава богу в SAP много таких примеров), мне тяжело просто это представить, или вы просто делаете просто формочки с функциональностью да и отчеты (у меня в голове не укладывается как в современном мире можно обходится без принципов OOA/OOD/OOP)

[Lemming]

Цитата:

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

А что, нормальный класс, не иделаьный конечно, но мы на проектах часто делаем от него наследников для реализации оборотки по банку и кассе. Хороший пример реализации паттернов Polymorphism, Low coupling, High cohesion и разделения логики и представления. "Вы просто не умеете их готовить"

ок, я понял, стало быть мне не повезло... Если у вас такая классная команда или отдельные люди, напишите пошаговый туториал как сделать свою оборотку на базе RLedgerSheet* и ваши доводы будут ясны и приняты + всячески респектированны участниками форума. Пример "как писать подобный пост/доку" очень дурацкий, но какой есть, можно его превзойти в сотни раз! А пока я вижу ваш контент только в разделе "рынок", мне сложно оценить потенциал и компетенцию вашей команды

Цитата:

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

Можно интимный вопрос? Вы работали(работаете) когда-нибудь у партнера? В скольких проектах вы участвовали?...

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

[Сисой]

Пять копеек в дискуссию (для старожилов форума эта информация ничем новым не является).
Работал я до Оптимы в компании Цефей. Там была разработана в начале века замечательная штука - Эталон. В 90-е годы это была учетная ORM на базе FoxPro (с отчетами а-ля 1С 8). При создании Windows-версии решили не мелочиться и создали мощную систему разработки, реализующую ORM в сочетании с ООП (т.е. при желании наследовались целые группы таблиц).
Язык программирования был похож по нотации на C++. СУБД: MS SQL и Oracle (но в отличие от 1С, с развитыми возможностями управления БД, использованием констрейнтов, триггеров, низкоуровневых операций с таблицами).
Казалось бы, все есть, чего еще надо? А споткнулись на простой вещи. Штат Цефея в эпоху DOS-овского Эталона состоял из специалистов, подобных 1Сникам. "Все в одном". Многие в прошлом были бухгалтерами или финдирами, т.е. консалтинг вели достаточно квалифицированно, а скриптовый язык на базе конструкций FoxPro освоить было несложно.
И вот всех начали переводить на ООП...
Через несколько лет компания практически потеряла свою долю рынка. Потому что вновь написанные решения отличались невиданной кривизной, базовые классы проектировались как бог на душу положит, производительность упала. Выяснилось, что быть одновременно хорошим аналитиком и программистом ой как нелегко (даже мне с многолетним опытом разработки на С++). Да и в самой платформе появлялись глюки из-за сложности продукта.
Пока перестраивались, пока учились, поезд ушел.
Я потом на 1С 7 перешел, долго плевался от ее куцых возможностей.
Потом 1С 8 появилась, стало легче. Но ко всем призывам внедрить полноценное ООП в платформу отношусь настороженно. Не готовы многие к нему. И похоже, не будут готовы никогда.

[Raven Melancholic]

Цитата:

Сообщение от Сисой

Пока перестраивались, пока учились, поезд ушел.

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

[Сисой]

Цитата:

Сообщение от Raven Melancholic

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

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

[Logger]

Цитата:

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

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

А не надо этого делать.
Оборотку надо переписывать с нуля.

[ibc]

Цитата:

Но ко всем призывам внедрить полноценное ООП в платформу отношусь настороженно. Не готовы многие к нему. И похоже, не будут готовы никогда.

Почему никогда? DELPHI в свое время любой студент 1-го курса способен был освоить!
Тут причина в другом, скорее всего!

[Lemming]

Цитата:

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

Почему никогда? DELPHI в свое время любой студент 1-го курса способен был освоить!
Тут причина в другом, скорее всего!

Ага, ту его часть которая касается процесса кинуть контрол на форму, ткнуть в свойствах на onClick и записать в этот метод бизнес логику. К ООП это никакого отношения не имеет и столь же успешно осваивается тогда в Visual Basic или Access, а сегодня в 1С. Достаточно большое количество таких программистов плохо понимает процессы, происходящие между выводом кнопки на экран и событием ее нажатия. Поскольку автор один, вся эта братия плавно перетекает в .NET. Да и вообще, насколько я помню ООП в Object Pascal муторное, Хейлсберг еще толком не понимал с кого копировать модель, так что взял что-то от С++, выдумал модификаторам новые имена и забил. Никому в Delphi это ООП не нужно, на фоне его возможностей программировать мышкой. Так что да, причина в другом

[brahma]

Цитата:

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

Никому в Delphi это ООП не нужно, на фоне его возможностей программировать мышкой. Так что да, причина в другом

Практически вся визуальная библиотека (если не изменяет память VCL) написана на самой Delphi. И там ООП к месту. А вот программировать формочки, на мой взгляд, и правда хватит скриптового языка. Просто нет одного универсального решения на все задачи. ООП тоже нужно с умом применять и там где ему место.
А "кривое" решение можно сделать и с ООП и с без него. Для ООП, кроме паттернов, существует целая коллекция антипаттернов.

[ibc]

Цитата:

Для ООП, кроме паттернов, существует целая коллекция антипаттернов.

Что бы это значило?