|
Про провал ООП | ☑ | ||
---|---|---|---|---|
0
izekia
23.07.12
✎
16:41
|
http://blogerator.ru/page/oop_why-objects-have-failed
забавная статья, правда немного скомкана, и мало что по сути, но если задуматься: насколько оправдана эта парадигма? Она скорее как 1С, легка для понимания и применения, но в итоге ее простота оказывается мнимой, так же как и остальные преимущества. Не говоря уже о дополнительных конструкциях делающих код менее выразительным. |
|||
1
Liova
23.07.12
✎
16:50
|
Опять про свой эфир пишут... Модная штука, видимо.
|
|||
2
Ненавижу 1С
гуру
23.07.12
✎
16:51
|
(0) баян по-моему это
|
|||
3
izekia
23.07.12
✎
16:51
|
(1) да про эфир там не в тему, лучше бы тему раскрыли шире)
|
|||
4
Ахиллес
23.07.12
✎
16:51
|
Цитата из статьи:
"На самом деле, в то время имелись как положительные эксперименты и опыты, подтверждающие существование эфира, так и отрицательные. Первые были полностью проигнорированы и исключены административными мерами из всех учебников физики После чего эфир был незаслуженно «закрыт» и отправлен в отставку, и вот, уже нынешнее поколение студентов-физиков даже и не знает о тех весьма успешных опытах по обнаружению эфирного ветра." ...мать, мать, мать, это, что же получается, те кто отрицают ООП, заодно и ТО отрицают? Однозначно в дурку тогда. |
|||
5
izekia
23.07.12
✎
16:53
|
(2) да просто отправная точка для рассуждений
(4) дада, ваши доводы зато отличаются здравым суждением |
|||
6
Ненавижу 1С
гуру
23.07.12
✎
16:53
|
(0) что конкретно тебя лично не устраивает в ООП?
|
|||
7
Ахиллес
23.07.12
✎
16:54
|
(5) Если бы тебе, кто-то сказал, что он отрицает ТО, а затем сказал, что ему не нравится ООП, что бы ты о нём подумал?
После первого заявления ко второму уже относится серьёзно не получится. |
|||
8
Bugmenot
23.07.12
✎
16:57
|
(0) - все верно написано.
Настоящие программисты обходятся вообще только с GOTO/GOSUB и глобальными переменными. А ООП - это навязанная зловещими мегакорпорациями технология. Да. |
|||
9
izekia
23.07.12
✎
16:58
|
(7) да мне пофиг на ТО и все что про эфир там пишут, по сути сама статья скомкана, но как отправная точка вполне подходит
(6) помнишь свою тему про ссылки друг на друга и еще что-то про наследование, по сути тема характерная только для ООП когда читаешь теорию, тебя захватывает идея и ее красота, а по сути когда начинаешь писать возникают проблемы с проектированием, избыточным кодом, взять тот же синглтон - это по сути класс-костыль по своей реализации |
|||
10
Ахиллес
23.07.12
✎
16:58
|
«Я уверен, что ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, лишь тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой.
Ээээ... вот это, я понимаю крутой чувак, со стальными яйцами. Аксиомы доказал. |
|||
11
Ненавижу 1С
гуру
23.07.12
✎
16:59
|
(9) ну там больше было ограничение языков конкретных, серебряной пули то конечно нет
типобезопасность, например |
|||
12
izekia
23.07.12
✎
17:00
|
(10) не надо к деталям придираться, тем более все верно написано, он не про доказательство, а про вывод
|
|||
13
izekia
23.07.12
✎
17:00
|
(11) что типобезопасность?
|
|||
14
Stagor
23.07.12
✎
17:01
|
ООП - фигня, каждый студент, заваливший программирование это знает!
|
|||
15
Ненавижу 1С
гуру
23.07.12
✎
17:01
|
(13) не устраивает меня временами
|
|||
16
Ахиллес
23.07.12
✎
17:01
|
Не, реально, ООП, ТО, Водородная бомба, Колесо, всё меркнет на фоне Доказательства Аксиом.
Думаю чувак заслужил, чтоб ему при жизни памятник из чистого золота поставили. Метров в сто высотой. |
|||
17
izekia
23.07.12
✎
17:03
|
(15) какое отношение к ооп?
|
|||
18
izekia
23.07.12
✎
17:03
|
(16) еще раз, он про вывод, а не про доказательство ...
|
|||
19
akaBrr
23.07.12
✎
17:09
|
(18) бгг, ценность мнения того кто написал про доказательства аксиом равна нулю, это аксиома
|
|||
20
Ненавижу 1С
гуру
23.07.12
✎
17:09
|
(17) да хрен его знает, ну давай более конкретно попробуем на Си++
Пусть есть некий абстрактный класс Item и от него куча конкретных Item1,...,ItemN Пусть также есть абстрактный класс Owner и от него куча конкретных Owner1,...,OwnerN каждый из OwnerK обладает несколькими контейнерами list<ItemK1>,...,list<ItemKХ> - каждый класс разными по сути но нам также хочется уметь с ними работать в абстрактном классе list< list<Owner> > но вот последнее как раз и не взлетает |
|||
21
Liova
23.07.12
✎
17:13
|
Мне кажется, сама статья так написана - куча, видимо, вырванных из контекста цитат и нелепая попытка ущипнуть ТО эфиром и всё это вместе связать.
|
|||
22
Ненавижу 1С
гуру
23.07.12
✎
17:16
|
Никто кстати с классов не начинает, начинают с интерфейсов
|
|||
23
izekia
23.07.12
✎
17:21
|
(22) мало кто подводит к созданию классов, а все начинают с примера типа автомобиль с газом и тормозом
|
|||
24
izekia
23.07.12
✎
17:22
|
("0) как я понял ты зацикливаешь?
|
|||
25
izekia
23.07.12
✎
17:22
|
(24) к (20)
|
|||
26
Господин ПЖ
23.07.12
✎
17:24
|
>но если задуматься: насколько оправдана эта парадигма?
любая парадигма работает в узких пределах... но фанатики/энтузиасты начинают натягивать ее на все - отсюда и разочарование в очередной "серебряной пуле" и подобные статьи |
|||
27
Rie
23.07.12
✎
17:28
|
(26) +100
|
|||
28
Ненавижу 1С
гуру
23.07.12
✎
17:28
|
(24) нет, это неудачный пример, это ограниченность шаблонов при наследовании, ковариантность
|
|||
29
Stagor
23.07.12
✎
17:30
|
ООП - не нужно, доказано на примере типовых конфигураций :)
|
|||
30
Steel_Wheel
23.07.12
✎
17:31
|
А интересно, за последние лет 10 появился ли хоть один крупный проект, реализованный без использования ООП?
|
|||
31
Rie
23.07.12
✎
17:34
|
(30) УПП.
|
|||
32
Ненавижу 1С
гуру
24.07.12
✎
08:29
|
(29) ага, еще там доказано дублирование кода
|
|||
33
oleg_km
24.07.12
✎
09:23
|
(30) Точно. В первую очередь GUI. Попробуйте-ка напишите GUI приложение на чистом WinAPI
|
|||
34
milan
24.07.12
✎
09:31
|
Товарищь опоздал со статьей лет на 20, теперь с использованием ООП написано все.
|
|||
35
Нуф-Нуф
24.07.12
✎
09:32
|
"выразительный код"...
|
|||
36
Stagor
24.07.12
✎
10:05
|
(32) дублирование кода зависит от программиста, а не от инструмента!
|
|||
37
milan
24.07.12
✎
10:28
|
(36) ну да, ну да, так и есть.
Не читал методику внедрения бсп, например ? не замечал сколько там надо накопипастить, чтобы оно работало ? |
|||
38
milan
24.07.12
✎
10:29
|
(37)+1 а в следующей версии что-нить поменяют и придется еще выуживать эти изменения и копипастить в 2 раза больше
|
|||
39
Rie
24.07.12
✎
10:30
|
(32) А это не дублирование кода, это "inline inheritance" :-)
|
|||
40
Господин ПЖ
24.07.12
✎
10:30
|
наличие ООП не мешает проектам на яве без наличия вменяемого тимлида/архитектора быть помойным ведром с ворохом шароварных библиотек, в каждой их которых пользуются парой функций...
|
|||
41
milan
24.07.12
✎
10:36
|
(40) начало просто прекрасно:
>>наличие ООП не мешает проектам на яве на 1000% прав. |
|||
42
khimiki
24.07.12
✎
10:41
|
Сама постановка вопроса неправильная. В одних проектах ООП рулит, в других проектах было бы логичнее применять структурное программирование. Не стоит забывать, что само ООП не есть что - то статичное, забетонированное. Там много зыбкого, неясного, например, дружественные классы. Поэтому можно ознакомиться со статьёй как с точкой зрения на проблему, но дискутировать по этому вопросу не нужно. Серебряной пули не существует.
|
|||
43
Ненавижу 1С
гуру
24.07.12
✎
10:44
|
>> но дискутировать по этому вопросу не нужно
а как же истина? |
|||
44
Flyd-s
24.07.12
✎
10:49
|
(43), в интернете кто-то не прав?
|
|||
45
Ненавижу 1С
гуру
24.07.12
✎
10:50
|
(44) бывает и так, даже признают
|
|||
46
Ненавижу 1С
гуру
24.07.12
✎
10:50
|
вот он шедевральный пример от 1С:
Если ВидСчетаФактуры = Перечисления.ВидСчетаФактурыВыставленного.НаАванс ИЛИ ВидСчетаФактуры = Перечисления.ВидСчетаФактурыВыставленного.НаАвансКомитента ИЛИ ВидСчетаФактуры = Перечисления.ВидСчетаФактурыВыставленного.НаСуммовуюРазницу Тогда ДанныеДляПечати = СобратьДанныеСФнаАвансИСуммовуюРазницу(ТекущееОснование); ИначеЕсли ВидСчетаФактуры = Перечисления.ВидСчетаФактурыВыставленного.НалоговыйАгент Тогда ДанныеДляПечати = СобратьДанныеСФНалоговыйАгент(ТекущееОснование); ИначеЕсли ТипОснования = Тип("ДокументСсылка.ОтчетКомитентуОПродажах") Тогда ДанныеДляПечати = СобратьДанныеПоОтчетКомитентуОПродажах(ТекущееОснование); ИначеЕсли ТипОснования = Тип("ДокументСсылка.РеализацияТоваровУслуг") Тогда ДанныеДляПечати = СобратьДанныеПоРеализацияТоваровУслуг(ТекущееОснование); ИначеЕсли ТипОснования = Тип("ДокументСсылка.РеализацияОтгруженныхТоваров") И ТипЗнч(ТекущееОснование.ДокументОтгрузки) = Тип("ДокументСсылка.РеализацияТоваровУслуг") Тогда ДанныеДляПечати = СобратьДанныеПоРеализацияТоваровУслуг(ТекущееОснование); ИначеЕсли ТипОснования = Тип("ДокументСсылка.РеализацияОтгруженныхТоваров") И ТипЗнч(ТекущееОснование.ДокументОтгрузки) = Тип("ДокументСсылка.ПередачаОС") Тогда ДанныеДляПечати = СобратьДанныеПоПередачеОС(ТекущееОснование.ДокументОтгрузки); ИначеЕсли ТипОснования = Тип("ДокументСсылка.ВозвратТоваровПоставщику") Тогда ДанныеДляПечати = СобратьДанныеПоВозвратТоваровПоставщику(ТекущееОснование); ИначеЕсли ТипОснования = Тип("ДокументСсылка.ОтчетКомиссионераОПродажах") Тогда ДанныеДляПечати = СобратьДанныеПоОтчетКомиссионераОПродажах(ТекущееОснование); ИначеЕсли ТипОснования = Тип("ДокументСсылка.АктОбОказанииПроизводственныхУслуг") Тогда ДанныеДляПечати = СобратьДанныеПоАкту(ТекущееОснование); ИначеЕсли ТипОснования = Тип("ДокументСсылка.ПередачаОС") Тогда ДанныеДляПечати = СобратьДанныеПоПередачеОС(ТекущееОснование); ИначеЕсли ТипОснования = Тип("ДокументСсылка.ПередачаНМА") Тогда ДанныеДляПечати = СобратьДанныеПоПередачеНМАОрганизаций(ТекущееОснование); ИначеЕсли ТипОснования = Тип("ДокументСсылка.ОтражениеНачисленияНДС") Тогда ДанныеДляПечати = СобратьДанныеПоОтражениеНачисленияНДС(ТекущееОснование); ИначеЕсли ТипОснования = Тип("ДокументСсылка.РеализацияУслугПоПереработке") Тогда ДанныеДляПечати = СобратьДанныеПоРеализацияУслугПоПереработке(ТекущееОснование); ИначеЕсли ТипОснования = Тип("ДокументСсылка.НачислениеНДСпоСМРхозспособом") Тогда ДанныеДляПечати = СобратьДанныеПоНачислениеНДСпоСМРхозспособом(ТекущееОснование); ИначеЕсли ТипОснования = Тип("ДокументСсылка.ОказаниеУслуг") Тогда ДанныеДляПечати = СобратьДанныеПоОказаниюУслуг(ТекущееОснование, "Контрагенты"); ИначеЕсли ТипОснования = Тип("ДокументСсылка.КорректировкаРеализации") Тогда ДанныеДляПечати = ПолучитьДанныеДляПечатиИсправленияСчетаФактуры(ТекущееОснование); КонецЕсли; |
|||
47
Serginio1
24.07.12
✎
10:51
|
http://rsdn.ru/forum/philosophy/3968990.flat.aspx
А вообще C# в себе совмещает и ООП и ФП |
|||
48
Господин ПЖ
24.07.12
✎
10:52
|
(46) и чо не так?
|
|||
49
khimiki
24.07.12
✎
10:52
|
(43) Истины в этом вопросе просто нет. Есть разные технологии, разные подходы к программированию. Они с той или иной степенью подходят для решения тех или иных задач, но ставить вопрос так, что ООП провалилось - это бессмысленно.
|
|||
50
Flyd-s
24.07.12
✎
10:52
|
(46), вполне читаемый пример
|
|||
51
Ненавижу 1С
гуру
24.07.12
✎
10:52
|
(47) никто не говорит, что один подход должен исключать другой
|
|||
52
Ненавижу 1С
гуру
24.07.12
✎
10:53
|
(48)(50) быдлокодинг детектед
|
|||
53
Господин ПЖ
24.07.12
✎
10:54
|
ожидание что ООП будет серебряной пулей и резко упростит жизнь - оно да, провалилось...
|
|||
54
Ненавижу 1С
гуру
24.07.12
✎
10:55
|
(53) "ожидание провалилось" интересная фраза, надо запомнить
|
|||
55
khimiki
24.07.12
✎
10:56
|
(52) Ну понятно, что если бы в вашем примере был задействован полиморфизм, то код выглядел бы совсем по другому, вернее свелся бы к одной строчке. Но 1С - ники, в среднем, не освоят ООП. Так что и 1С - ий язык находит применение.
|
|||
56
Serginio1
24.07.12
✎
10:58
|
(50) С перегрузкой методов было бы значительно короче
|
|||
57
Flyd-s
24.07.12
✎
10:59
|
(52), такой пример затрудняет чтение текста или затрудняет разработку или затрудняет модификацию?
|
|||
58
Ненавижу 1С
гуру
24.07.12
✎
11:00
|
(57) да он все затрудняет
|
|||
59
khimiki
24.07.12
✎
11:00
|
(57)затрудняет сопровождение
|
|||
60
khimiki
24.07.12
✎
11:03
|
59+ Согласитесь,
ДанныеДляПечати.СобратьДанныеПоРеализацияТоваровУслуг(ТекущееОснование) выглядит куда более привлекательным, чем вся эта тряхомундия. |
|||
61
Ненавижу 1С
гуру
24.07.12
✎
11:05
|
(60) хм... а разве не
ДанныеДляПечати = ТекущееОснование.СобратьДанныеДляСчетФактуры(); |
|||
62
khimiki
24.07.12
✎
11:10
|
(61) Это что вообще такое?! У меня есть экземпляр класса, печатающего документ, назовем класс как ПечатникДокумента, я создаю его экземпляр
печатникДокумента = new ПечатникДокумента(); и вывожу документ на печать печатникДокумента.Распечатать(ДокументОснование); |
|||
63
khimiki
24.07.12
✎
11:12
|
62+ А Вы написали код в стиле 1С, который к ООП не имеет никакого отношения.
|
|||
64
Ненавижу 1С
гуру
24.07.12
✎
11:12
|
(62) все это прекрасно, но тогда надо разных печатников делать, ведь от типа основания зависит алгоритм получения данных
|
|||
65
khimiki
24.07.12
✎
11:13
|
(64)Зачем!? ПОЛИМОРФИЗМ
|
|||
66
Serginio1
24.07.12
✎
11:13
|
60 А если бы была перегрузка методов то можно писать единообразно для всех типов документов
ДанныеДляПечати=СобратьДанные(Док). Аналогично можно и 61 прикрутить через Хэлперы (статические методы this) либо как в 61 можно написать через метод объекта или менеджер объекта с передачей этого объекта. Просто в 8 ке куча атавизмов. |
|||
67
Ненавижу 1С
гуру
24.07.12
✎
11:15
|
(65) где полиморфизм?
|
|||
68
Ахиллес
24.07.12
✎
11:16
|
От уже договоритесь... вот введёт в 9.0 одинэс ООП, вот тогда заплачите горючими слезами.
|
|||
69
khimiki
24.07.12
✎
11:16
|
(66) Перегрузка немного не то. Класс ПечатникДокумента может делать другой человек, что он там делает и как - его забота. Я просто использую его класс в своих целях.
|
|||
70
khimiki
24.07.12
✎
11:17
|
(67) Полиморфизм, наряду с абстракцией и наследованием, позволяет не делать того, чего вы боитесь в (64). Вообще - то это основы ООП...
|
|||
71
Господин ПЖ
24.07.12
✎
11:18
|
что и требовалось доказать... 2 человека уже не могут договориться как это будет...
|
|||
72
Господин ПЖ
24.07.12
✎
11:19
|
нах эти бантики в учетных системах? их задачи совсем иные...
|
|||
73
Serginio1
24.07.12
✎
11:19
|
(69) Ну почему. Если у тебя нет доступа к классу, или ты не хочешь его расширять, хотя хэлперы мне очень нравятся, то перегрузка ведет к единоообразию, которая кстати довольно часто применяется в патерне визитер
http://www.rsdn.ru/article/patterns/VisitorPattern.xml#ECLAC |
|||
74
khimiki
24.07.12
✎
11:20
|
(72) Вы просто не пробовали писать учётные системы с применением ООП. Код становится понятнее и доступнее, чем в 1С.
|
|||
75
khimiki
24.07.12
✎
11:22
|
(73) Просто я сторонник виртуальных методов, сами понимаете, сколько людей, столько и предпочтений.
|
|||
76
Господин ПЖ
24.07.12
✎
11:22
|
>Вы просто не пробовали писать учётные системы с применением ООП
не надо меня лечить... насмотрелся в свое время на "убийцев 1Ц"... как только вменяемый тимлид, сидящий с утра до ночи на проекте, переставал куячить по пальцам своим архаравцам - все скатывалось в УГ примерно через полгода... |
|||
77
Ненавижу 1С
гуру
24.07.12
✎
11:23
|
khimiki я так и не понял как вы избавитесь от монстра из (46)
|
|||
78
Господин ПЖ
24.07.12
✎
11:24
|
(77) бугага...
|
|||
79
khimiki
24.07.12
✎
11:24
|
(76) применением ООП
|
|||
80
khimiki
24.07.12
✎
11:25
|
79 Конкретно - таблицей виртуальных методов
|
|||
81
Serginio1
24.07.12
✎
11:25
|
(75) Я тоже, но для 1С есть Модуль объекта и модуль менеджера в котором можно помещать нужные методы используя двойную диспетчерезацию
|
|||
82
Жан Пердежон
24.07.12
✎
11:25
|
(0) одна вода в статье
|
|||
83
Ненавижу 1С
гуру
24.07.12
✎
11:26
|
(79)(80) это все общие слова, набросайте решение
|
|||
84
khimiki
24.07.12
✎
11:26
|
(81)1С и ООП - совершенно разные вещи, не имеющие ни одной точки пересечения.
|
|||
85
khimiki
24.07.12
✎
11:27
|
(83)Честное слово лень повторять любой учебник по объектно - ориентированному программированию.
Философия С++. Введение в стандартный С++ Философия С++. Практическое программирование Там ответы на 80% ваших вопросов. |
|||
86
Господин ПЖ
24.07.12
✎
11:31
|
с вами ООП точно кранты...
|
|||
87
khimiki
24.07.12
✎
11:35
|
(86)ООП прекрасно живёт и существует, с нами или без нас, нет разницы. Что, повторюсь, не отменяет ни структурное программирование, ни декларативное, ни программирование с стиле 1С, которому в мировой практике нет пока названия.
Любой язык и любая технология, находящая применение, достойна уважения. |
|||
88
mikeA
24.07.12
✎
11:44
|
(77) легко:
ДанныеДляПечати= Вычислить("СобратьДанныеДляПечати" + ТекущееОснование.Метаданные().Имя + "(ТекущееОснование)"); метапрограммирование рулит ))) |
|||
89
Serginio1
24.07.12
✎
11:45
|
(87) Почему это нет? 1C это чистой воды двойная диспетчеризация с использованием Idispatch или его аналогов.
|
|||
90
Jolly Roger
24.07.12
✎
11:45
|
(9) >а по сути когда начинаешь писать возникают проблемы с проектированием
если за всю жизнь ума хватило освоить только палку-копалку, то да, экскаватор будет только мешать... |
|||
91
Serginio1
24.07.12
✎
11:46
|
(88) Сам очень часто использую такой подход, но у него есть один минус тяжело понять откуда этот метод вызывается не зная деталей. А так комменты рулят.
|
|||
92
khimiki
24.07.12
✎
11:55
|
(89) Вы хотите перевести тему дискуссии к обсуждению достоинств и недостатков COM технологии?
|
|||
93
Ненавижу 1С
гуру
24.07.12
✎
11:56
|
(85) скользкий ты какой-то
|
|||
94
khimiki
24.07.12
✎
11:59
|
(93)С чего бы это? Просто для того, чтобы рассуждать о ООП нужно быть знакомым с его положениями. А у меня нет желания знакомить новичков с этой технологией. Почитайте книги, там всё есть.
|
|||
95
Кокос
24.07.12
✎
12:02
|
(0) чем не устраивает ООП? даже 1С(включая 77) построен на принципах ООП. конечно дальнейшее наследование закрыто но построенно таки на его принципах. И вплоне успешно работает.
|
|||
96
Serginio1
24.07.12
✎
12:05
|
(94) Нет не хочу. Мне нравится C# где можно использовать и вывод типов, и ФП (Linq очень нравится) и ООП и динамики (двойная диспетчеризация).
Едмнственно пока не реализован патерн матчинг |
|||
97
Flyd-s
24.07.12
✎
12:07
|
(58), у меня не возникало с этим куском кода проблем.
|
|||
98
Flyd-s
24.07.12
✎
12:07
|
(60), а если не только по РеализацииТоваровУслуг надо?
|
|||
99
Flyd-s
24.07.12
✎
12:09
|
(62), да, но всю кашу надо будет куда-то в класс засунуть
|
|||
100
Steel_Wheel
24.07.12
✎
12:12
|
(87) >> нет названия
Предметно-ориентированное? |
|||
101
Steel_Wheel
24.07.12
✎
12:15
|
(77) Общий тип, куча предков, вызов перегруженной функции с параметром типа предок
|
|||
102
Serginio1
24.07.12
✎
12:19
|
(95) Скорее на утинной типизации wiki:%D3%F2%E8%ED%E0%FF_%F2%E8%EF%E8%E7%E0%F6%E8%FF
|
|||
103
khimiki
24.07.12
✎
12:26
|
(96)Да, С# очень правильный язык программирования, очень правильный. Надеюсь со временем он вытеснит 1С как класс с рынка учётных систем.
|
|||
104
khimiki
24.07.12
✎
12:27
|
103+ А я на ADO.NET пока застрял. А что, Linq действительно кульная штучка?
|
|||
105
Serginio1
24.07.12
✎
12:30
|
(104) Особенно Linq to EF. Там и запрося аля 1С.
Ну вообщето в том же Linq to EF это можно делать в том числе и для запросов аля 1С OjectQuery string entitySQL = " SELECT p, p.Filling " + "FROM PartyContext.Pinatas AS p " "WHERE p.Filling.Description='Candy'"; var query=context.CreateQuery<DbDataRecord>(entitySQL); query.MergeOption = System.Data.Objects.MergeOption.NoTracking; var pinatasWithFilling=query.ToList(); Или v8: ADO.NET EF и 1С |
|||
106
Ненавижу 1С
гуру
24.07.12
✎
12:41
|
(101) так он молчит, зато пишет про распальцовку личную
|
|||
107
khimiki
24.07.12
✎
14:16
|
(100) >> нет названия
Предметно-ориентированное? Я говорил про мировую практику, а не про нашу рашу, которая, как известно, всегда идёт своим, особенным путём. |
|||
108
khimiki
24.07.12
✎
14:17
|
(106) А о чём с вами разговаривать, если вы про полиморфизм не знаете? Может мне вас читать - писать поучить?
|
|||
109
iceman2112
24.07.12
✎
14:52
|
бред.
|
|||
110
Serginio1
24.07.12
✎
16:22
|
(62) Проще использовать метод менеджера как статический класс. Кстати в Delphi есть перекрытие виртуальных статических методов ссылки на которые хранятся с отрицательным смещением в VMT
|
|||
111
Serginio1
24.07.12
✎
16:23
|
110 поправка как статический метод класса
|
|||
112
Ndochp
24.07.12
✎
17:01
|
(107) У меня в учебнике (вроде переводном) по VB его стиль назывался предметно ориентированным. На первый взгляд ВБ с 1С схож, но его я глубоко не копал.
|
|||
113
Serginio1
24.07.12
✎
17:17
|
||||
114
Rie
24.07.12
✎
17:37
|
(112) VBA - предметно-ориентированный. Но предметно-ориентированные и объектно-ориентированные - это как бы перпендикулярно (назначение языка и структура/парадигма языка). Для 1Сика и VBA есть термин object-based (но адекватных переводов на русский язык мне не встречалось).
|
|||
115
Flyd-s
24.07.12
✎
17:59
|
(0), прочитал. Какое-то собрание сторонников шапочки из фольги
|
|||
116
Ненавижу 1С
гуру
25.07.12
✎
07:01
|
(108) поучи бабушку, откуда мысль, что не знаю?
|
|||
117
napagokc
25.07.12
✎
08:06
|
Еще не дочитал статью до конца, но на мой взгляд налицо идет сравнение теплого с мягким. Люди просто спорят о разных вещах.
Я согласен с высказыванием Никлауса Вирта - ООП лишь надстройка над структурным программированием. И что? Чем это плохо-то? Противники ООП придираются к тому, что сторонники ООП в своих разработках используют уже готовые объекты! Какая связь концепции ООП и работы конечного программиста с ней? Лично я когда пишу свои собственные программы для себя лично, использую только базовые объекты. Таким образом у меня получаются программы без лишних данных - в моих объектах отсутствуют неиспользуемые поля и методы. И чем плохо такое программирование? Или противники ООП скажут, что это уже структурное программирование, а вовсе не ООП? Учитывая то, что у меня практически отсутствуют процедуры, не являющиеся методами объектов, а сами объекты тесно связаны между друг другом... Я хочу сказать, что концепция ООП ни разу не исключает все положительные стороны процедурного программирования. А быстрота разработки, при использовании ООП, заключается в том, что сами программы разрабатываются быстрее. Да, такие программы могут жрать дофига лишних ресурсов. Да, это может быть похоже на приведенное в статье фото (http://blogerator.ru/uploads/pix2012/2010/oop2-failed-3.jpg). Но согласитесь, что разработать такую модель (если предположить, что она рабочая) значительно проще, чем создавать телефон со встроенным фотоаппаратом? ЗНАЧИТЕЛЬНО проще! А, как известно, чей продукт раньше выйдет на рынок, тот и сорвет весь куш! К тому времени, когда конкурирующая фирма изобретет наконец свой первый телефон со встроенным фотоаппаратом, лидирующая на рынке фирма уже выпустит вторую или третью модель телефона, который тоже будет содержать встроенный фотоаппарат. Только у лидирующей фирмы уже будет все отлажено, устранен целый ряд багов, про которые в конкурирующей фирме еще может быть даже не известно. В общем, пока меня статья не убедила. Просто спорят о разных вещах. Продолжу читать дальше. :) |
|||
118
Jolly Roger
25.07.12
✎
08:22
|
(117) да чо там читать-то?... эта хрень затеяна исключительно ради флуда и привлечения внимания...
|
|||
119
Evpatiy
25.07.12
✎
08:25
|
Все кроме 1С - г0вно, конфигуратор - наше все!
Где голосовалка? |
|||
120
Xapac_2
25.07.12
✎
08:28
|
(0) а где недостатки ООП то? чета не нашел. по пунктам. каике-то бла бла
|
|||
121
Птах
25.07.12
✎
08:45
|
(0) Статья еретическая. Авторам - жечь пятки и сечь жпо.
|
|||
122
Xapac_2
25.07.12
✎
08:49
|
а вообще я так понял мол, за ооп погнались и часто до маразма доходит
то что можно по простому, все там придумывают какието иерархии, когда можно одну мизерную функцию написать. вообщем как обычно все в меру. |
|||
123
НафНаф
25.07.12
✎
08:51
|
про паттерны еще никто не писал
|
|||
124
napagokc
25.07.12
✎
08:55
|
Не, статья верная, но спор идет о разных вещах, на сколько я понял. Противники ООП считают ООП злом из-за того, что из-за наследования конечный класс приобретает слишком много лишних полей и методов. Это совершенно верно, но кто запрещает написать свою собственную иерархию классов? Без всяких излишеств, используя достоинства ООП... Кривость рук? А если писать собственную иерархию, то все аргументы противников ООП уходят в никуда - вообще ни одного аргумента нет против.
|
|||
125
Ненавижу 1С
гуру
25.07.12
✎
08:56
|
(124) написание собственное иерархии уже минус
|
|||
126
Xapac_2
25.07.12
✎
08:59
|
УПП без ООП!!! доказательство, что без ООП жизнь есть!
|
|||
127
Ненавижу 1С
гуру
25.07.12
✎
09:00
|
(126) УПП? да разве это жизнь ))
|
|||
128
napagokc
25.07.12
✎
09:07
|
(125) Серьезно? А без собственной иерархии, простым структурным программированием писать аналогичную программу легче, да? Если нет, то какой же это минус тогда? Нет минуса. Есть только плюсы в ООП.
|
|||
129
quest
25.07.12
✎
09:12
|
Лисперы те еще троли... Прекрасно осознавая что кроме скобок (по сути AST) нет ничего лучше, издеваются над другими языками. И получается у них, что то ООП фигня, то АОП - чушь, то ФП - херня.. А сами обзавелись наверное одной из самых лучших реализаций ООП, четко вывереной методлогией использования агентов и как ни странно - той самой функциональщиной.
|
|||
130
quest
25.07.12
✎
09:13
|
а Грэм ООП в своей On Lisp неслабо так потролил :)
|
|||
131
NS
25.07.12
✎
09:14
|
(112) Схож, или всё-таки 1С это и есть VB?
|
|||
132
Ненавижу 1С
гуру
25.07.12
✎
09:19
|
(128) работать, когда можно не работать это минус
|
|||
133
napagokc
25.07.12
✎
09:24
|
(132) Ты уводишь разговор в сторону. Если ты хочешь писать как можно меньше своего кода - созданные в ООП классы тебе в помощь. Тут налицо явный плюс ООП. Если ты хочешь написать компактный код, не жрущий лишних ресурсов - пиши свою собственную иерархию. Это немного усложнит задачу, но даже при таком подходе ты не проиграешь просто структурному программированию.
А значит, ООП никак не хуже структурного программирования, но в некоторых случаях может иметь целый ряд больших плюсов. |
|||
134
Ненавижу 1С
гуру
25.07.12
✎
09:25
|
(133) я с тобой полностью согласен
|
|||
135
NS
25.07.12
✎
09:25
|
(133) А процедуры и функции объединенные в библиотеки не помогают писать меньше своего кода?
|
|||
136
napagokc
25.07.12
✎
09:26
|
(135) ты не поверишь, но используя ООП можно использовать те же самые процедуры и функции из сторонних библиотек!
|
|||
137
NS
25.07.12
✎
09:28
|
(136) И казалось бы - причем тут ООП...
|
|||
138
Sserj
25.07.12
✎
09:29
|
(126) Не ври, в 1С каждый справочник, документ, отчет, обработка наследник базового класса а значит ООП есть :)
|
|||
139
napagokc
25.07.12
✎
09:30
|
(137) В том-то и дело, что не надо уводить разговор к задачам, где ООП использовать нет необходимости. Я не знаю таких программистов, которые используют ООП просто потому, что знают его, а не потому, что это действительно облегчит задачу.
|
|||
140
Sserj
25.07.12
✎
09:30
|
(139) А я знаю - это все кто пишет на яве. Потому что там прото нельзя писать не используя хоть один класс :)
|
|||
141
napagokc
25.07.12
✎
09:31
|
(140) Напомню, что мы говорим о концепции ООП, а не о конкретном языке программирования
|
|||
142
Jstunner
25.07.12
✎
09:31
|
(135) помогают, но расширить возможности библиотек без использования наследования и полиморфизма довольно проблематично.
Пример: без простейшего ООП, библиотеку, рисующую фигуры, с предопределенными треугольником и прямоугольником, сложно заставить рисовать пятиконечную звезду. |
|||
143
Sserj
25.07.12
✎
09:36
|
(141) неправда ваша, досвловно "не знаю таких программистов, которые используют ООП просто потому, что знают его", фактически если программист пишет на современных языках ява, сишарп и многих других он просто обязан использовать ООП, потому как без него на этих языках просто невозможно писать.
|
|||
144
Rie
25.07.12
✎
09:39
|
(143) А что мешает писать на Java или C#, НЕ используя ООП?
|
|||
145
NS
25.07.12
✎
09:42
|
(143) А я знаю. Каждая первая шахматная программа, несмотря на предупреждения опытных товарищей - пишется с использованием ООП. А потом переписывается с нуля, когда человек понимает что ООП тут нафик не сдался.
|
|||
146
Sserj
25.07.12
✎
09:42
|
(144) Хотяб бы то что любой метод или поле, в том числе и точки входа обязаны быть внутри классов. И хочешь или нет классы придется делать а классы как минимум наследуются от базовых ну и собственно ООП уже используется.
|
|||
147
Jstunner
25.07.12
✎
09:46
|
(145) шахматы - известная и законченная модель, маловероятно, что когда нибудь появится новая фигура или ход
|
|||
148
Rie
25.07.12
✎
09:47
|
(146) И что? Делаешь статические классы - и не мучаешься.
|
|||
149
Rie
25.07.12
✎
09:49
|
+(148) Да и почему напрягает ключевое слово class? ООП - это ведь технология. Не применяй её - и пиши хоть на Java, хоть на C#, хоть на Smalltalk.
|
|||
150
Jstunner
25.07.12
✎
09:49
|
(146) достаточно использовать классы только как пространство имен.
|
|||
151
Xapac_2
25.07.12
✎
09:50
|
(148)+100500 именно так и делаю "библиотечки"
|
|||
152
Sserj
25.07.12
✎
09:52
|
(148) Но таки делаешь же статичный, но таки класс - ООП в действии.
(149) Можно любой пример на яве рабочий без использования class, вот действительно стало до жути интересно. |
|||
153
NS
25.07.12
✎
09:52
|
(147) Не понимаю о чем ты. Любая готовая программа это законченная модель.
|
|||
154
Rie
25.07.12
✎
09:57
|
(152) Тебе шашечки или ехать? Какое отношение к ООП имеют статические классы? Или для тебя ООП и ключевое слово class - синонимы?
|
|||
155
Кирпич2
25.07.12
✎
10:05
|
ХорОш про ООП! Давайте про goto уже.
|
|||
156
Rie
25.07.12
✎
10:08
|
Можно совместить и обсудить goto из метода базового класса внутрь произвольной функции класса-наследника...
|
|||
157
Кирпич2
25.07.12
✎
10:09
|
(156) Вот вот
|
|||
158
Кирпич2
25.07.12
✎
10:11
|
+157 Ведь это форменное безобразие. Хорошо что никакой язык этого не позволяет. А то мучались бы. И страдали.
|
|||
159
Stagor
25.07.12
✎
10:28
|
"Противники ООП считают ООП злом из-за того, что из-за наследования конечный класс приобретает слишком много лишних полей и методов. "
ага! но вроде, как в Руби (или др. языке) можно выборочно наследовать и даже динамически. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |