shelsoftigor250973У-у-у как всё запущено ... Структурное программирование основано главным образом на теоретическом ...
1) так вот откуда "тот вал просто говняного бизнес-софта, который производят российские компании"
2) В детский сад ... однозначно учиться пользоваться лопаткой чтобы копать, ведерком чтобы носить песок и формочками чтобы делать куличики. Ибо каждый конкретный подход хорош для конкретных вещей.
3) и причем тут UML IDEF0 например тоже неплохо справляется


^{______________________________________________________
Давайте считать обступившее нас со всех строн коричневое море шоколадным}


Ага, увидели знакомое слово ("теоретический") и обрадовались :-)
Типа щас то мы его в реал погрузим (хе-хе).
Рад вам сообщить, что всяческой практической деятельности должно предшествовать теоретическая подготовка. В конце концов и лопаткой мона себе и окружающим увечие нанести, если слабо преставлять её место среди вещей в мире.
ООП в принципе более продвинуто по сравнению с процедурным подходом тока уже потому, что инкапсулирует в себе этот подход на уровне поведения классов. Зато оно естесственным образом реализует такие вещи, как высокую связность программного кода внутри и низкую сцепленность вне классов, как основных программных структур (кстати, если вам незнакомы термины "сцепленность" и "связность", то идите в.. сад, о чём тада с вами говорит!).
Ну а UML, органично реализующий и развивающий ООП концепции, ценен не сам по себе, а как основа для инструментальных средств его использующих. Слышали ли вы что нибудь об MDA (архитектура управляемая моделью)? Если нет, то, знайте, что то, что вы будете реализовывать месяц при процедурном подходе, может быть реализовано за день.
Ну а насчёт моего неведения мира практики, то не волнуйтесь, у меня за плечами не одна разработка сложных бизнес-систем.

P.S. просьба не придираться к опечаткам, поскока посты пишу в перерывах между боями.

Belyigor250973Есть и более сложные правила, неведомые тем, кто слишком часто спрашивает у гугля ;-)Понятно - ничего нового, просто придумали свое название старым прописным истинам.
Да и к оформлению кода это не имеет никакого отношения.

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

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

Bely ... по моим наблюдениям, если человек не может нормально писать процедурный код, то при использовании ООП он не станет выдавать гениальные программы...
ну вы даёте, речь об этом и не идёт.

Bely...
Я вам всё про "лес" пытаюсь рассказать, а вы мне всё ветками деревьев тычете. Я отнюдь не отрицаю их существования.
Вот так оно и есть "за деревьями не видим леса".

Petro123авторMDA (архитектура управляемая моделью)? Если нет, то, знайте, что то, что вы будете реализовывать месяц при процедурном подходе, может быть реализовано за день
мечты, мечты...
Нашли очередную "серебрянную пулю"?

______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!
А вы потеряли ...

shelsoft
1) Не надо за меня думать ... просто не люблю оверквотинг
2) Хотите я вам пришлю курс лекций по ООП которые я читаю .. или идите в "Программирование"
3) Еще Bold вспомните ...
4) Читаем здесь по эту "лопатку" которой "мона себе и окружающим увечие нанести, если слабо преставлять её место среди вещей в мире" (кстати как вы используете наполезнейшую весч такую как аctivity и package diagram. или все ограничивается use case
5) Не хватает слов "успешный, промышленный, тиражируемый"
6) Я считаю это простой горой литературы различных авторов предпочитая в работе использовать понятия типа проект, диаграмма, требование желательно представленное в коде а не в виде каши в голове
7) "Извиняем за неровный почерк"

1) упаси боже, слово "думать" по отношению к вам я и не использовал :-)
2) да нет уж, парьте своих студентов
3) ... о да, хорошие воспоминания, ребята молодцы, и не их вина, что пришёл борланд и всё загубил, хотя вот мелкософт пообещала поднять упавший флаг на достойную высоту
4) я по ленности своей, честно говоря, больше диаграммами классов балуюсь, но када припирает приходится и всё остальное использовать
5) вот я пишу: "успешный, промышленный" (один из проектов уже 4 года работет без моего вмешательства), врать не буду, не "тиражируемый", поскольку область специфичная
6) представление требований (типа сам требования разработал и сам тут же не отходя от кассы систему написал, оставив кодеров без хлеба) в коде оставим на вашей совести как ваше же ноу хау.

Petro123
<sup>История программных революций от Microsoft, вкратце:

Сначала были Windows API и DLL Hell. Революцией N1 было DDE - помните, как ссылки позволили нам создавать статусные строки, отражающие текущую цену акций Microsoft? Примерно тогда же Microsoft создала ресурс VERSION INFO, исключающий DLL Hell. Но другая группа в Microsoft нашла в DDE фатальный недостаток - его писали не они!

Для решения этой проблемы они создали OLE (похожее на DDE, но другое), и я наивно вспоминаю докладчика на Microsoft-овской конференции, говорящего, что скоро Windows API перепишут как OLE API, и каждый элемент на экране будет ОСХ-ом. В OLE появились интерфейсы, исключающие DLL Hell. Помните болезнь с названием <по месту>, при которой мы мечтали встроить все свои приложения в один (возможно, очень большой) документ Word? Где-то в то же время Microsoft уверовала в религию С++, возникла MFC решившая все наши проблемы еще раз.

Но OLE не собиралась, сложа руки смотреть на это, поэтому оно заново родилось под именем COM, и мы внезапно поняли, что OLE (или это было DDE?) будет всегда - и даже включает тщательно разработанную систему версий компонентов, исключающую DLL Hell. В это время группа отступников внутри Microsoft обнаружила в MFC фатальный недостаток - его писали не они! Они немедленно исправили этот недочет, создав ATL, который как MFC, но другой, и попытались спрятать все замечательные вещи, которым так упорно старалась обучить нас группа COM. Это заставило группу COM (или это было OLE?) переименоваться в ActiveX и выпустить около тонны новых интерфейсов (включая интерфейсы контроля версий, исключающие DLL Hell), а заодно возможность сделать весь код загружаемым через броузеры, прямо вместе с определяемыми пользователем вирусами (назло этим гадам из ATL!).

Группа операционных систем громким криком, как забытый средний ребенок, потребовала внимания, сказав, что нам следует готовиться к Cairo, некой таинственной хреновине, которую никогда не могли даже толком описать, не то, что выпустить. К их чести, следует сказать, что они не представляли концепции <System File Protection>, исключающей DLL Hell. Но тут некая группа в Microsoft нашла фатальный недостаток в Java - её писали не они! Это было исправлено созданием то ли J, то ли Jole, а может, и ActiveJ (если честно, я просто не помню), точно такого же как Java, но другого. Это было круто, но Sun засудило Microsoft по какому-то дряхлому закону. Это была явная попытка задушить право Microsoft выпускать такие же продукты, как у других, но другие.

Помните менеджера по J/Jole/ActiveJ, стучащего по столу туфлей и говорящего, что Microsoft никогда не бросит этот продукт? Глупец! Все это означало только одно - недостаток внимания к группе ActiveX (или это был COM?). Эта невероятно жизнерадостная толпа вернулась с COM+ и MTS наперевес (может, это стоило назвать ActiveX+?). Непонятно почему к MTS не приставили <COM> или <Active> или <X> или <+> - они меня просто потрясли этим! Они также грозились добавить + ко всем модным тогда выражениям. Примерно тогда же кое-кто начал вопить про <Windows DNA> (почему не DINA) и <Windows Washboard>, и вопил некоторое время, но все это почило раньше, чем все поняли, что это было.

К этому моменту Microsoft уже несколько лет с нарастающей тревогой наблюдала за интернет. Недавно они пришли к пониманию, что у Интернет есть фатальный недостаток: ну, вы поняли. И это приводит нас к текущему моменту и технологии .NET (произносится как <doughnut (пончик по-нашему)>, но по-другому), похожей на Интернет, но с большим количеством пресс-релизов. Главное, что нужно очень четко понимать - .NET исключает DLL Hell.

В .NET входит новый язык, C#, (выясняется, что в Active++ Jspresso был фатальный недостаток, от которого он и помер). .NET включает виртуальную машину, которую будут использовать все языки (видимо, из-за фатальных недостатков в процессорах Интел). .NET включает единую систему защиты (есть все-таки фатальный недостаток в хранении паролей не на серверах Microsoft). Реально проще перечислить вещи, которых .NET не включает. .NET наверняка революционно изменит Windows-программирование... примерно на год.</sup>

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

Petro123shelsoft
1) Этот што-ли ADO.NET Entity Framework

прикольная ссылка :)
авторДругим способом уйти в EDM от строгого взаимно-однозначного сопоставления модели хранилищу является сопоставление одной сущности в модели нескольким таблицам в хранилище. Между таблицами Contacts и ContactNameSplit в базе данных Northwind есть взаимно-однозначная связь, и можно объединить их в одну сущность в модели. Для примера я создам в модели сущность, включающую все поля таблицы Contacts и поля Title и Name из таблицы ContactNameSplit.
вместо вьюхи в БД та же фигня только на XML
Вот опять вы ничего не поняли.
Раз уж понимание механизма не доходит, то поймите хоть следствие - это принципиальное решение отказаться от сиквельных запросов в коде программы, что позволит вам не лопатить код при переходе на другой сервер БД раз, во вторых размер кода уменьшится, в третьих будет меньше ошибок , поскольку ошибки в сиквельном коде всплывают только в рантайме.
В своё время мне пришлось затратить усилие на создание библиотеки, проецирующей ОО модель на реляционную. Зато выигрыш во времени разработки новых проектов был кардинальный.

Petro123igor250973
Всё что вы тут напостили говорит о том, что вы даже не удосужились попользовать эти технологии.

ну почему, пользовал. Разница в том, что я знаю их недостатки и не делаю щенячьего восторга по поводу очередной (см.выше)
Так объясните мне непонятливому, что вас не устраивает, к примеру в OLE, и чем взамен этого вы пользуетесь???

Алексей Морозов
igor250973
Вот опять вы ничего не поняли.
Раз уж понимание механизма не доходит, то поймите хоть следствие - это
принципиальное решение отказаться от сиквельных запросов в коде программы,
что позволит вам не лопатить код при переходе на другой сервер БД раз, во
вторых размер кода уменьшится, в третьих будет меньше ошибок , поскольку
ошибки в сиквельном коде всплывают только в рантайме.
В своё время мне пришлось затратить усилие на создание библиотеки,
проецирующей ОО модель на реляционную. Зато выигрыш во времени разработки
новых проектов был кардинальный.


Ну и :)

Я тоже предлагаю решение которое позволит нам не лопатить код при переходе
на другой сервер БД раз, во вторых размер кода уменьшится, в третьих будет
меньше ошибок, поскольку ошибки в сиквельном коде всплывают сразу после
того, как автор написал запрос. Только я позволяю на отказываться от SQL
сосем, а использовать его часть поддерживаемую всеми популярными СУБД.
(Популярность определяю я.)



на самом деле нет такой части, которая бы позволяла её использовать на практике. Так, к примеру, в параметрическом запросе для MSSQL вам придётся исполдьзовать "@", а в MySQL "?".
Более того, предположим в своём классе, некоторые поля которого вы храните в базе, вы хотите завести новое хранимое поле, тогда при традиционном подходе вам придётся внести изменения во все запросы, где это поле будет использоваться, при предлагаемом, никаких изменений делать не надо, они отобразятся автоматически.