Это да))) Еще моего бывшего начальника (начальника отдела web-разработок) ввела в ступор конструкция public static)))) Я, конечно, все понимаю, но это уже слишком... короче, уволился я оттуда

Добавлено через 1 минуту и 34 секунды
Это оффтоп. А вообще, дотнет, конечно, удобная штука, но слишком много ресурсов кушает и память за собой чистить не умеет нормально, поэтому при разработке ресурсоемких систем все равно с++ юзать будут

Лично я попав на C#, после C++, когда там стали выскакивать подсказки и половину кода за меня писал автомат, ужаснулся. Не могу я так. Вот что хотите делайте, а мне нужны задачи и сложные комплексные решения с навороченными алгоритмами - работа мысли, пот и кровь; а не дома - матрёшки, в 256 этажей.

Это сообщение отредактировал(а) Rickert - 6.11.2008, 09:51

жжешь   



ну сколько можно повторять, причем здесь ОО языки?   
повторное использование кода != ОО язык
это вообще разные понятия
все либы на С - есть повторное использование кода, к примеру   

Это не начальство хочет - это реалии жизни. Пойми, это отнюдь не прихоть, а вопрос конкурентоспособности в современном мире. Другое дело что трезвомыслящий человек понимает, что если в данной области он ни бум-бум, ему нужен опытный менаджер, который во-первых может организовать работу, во-вторых понимает достаточно в предметной области и в-третьих кому он может доверять в плане решения качество-скорость разработки. Конечно идеально, что этот менаджер и есть главный архитектор. Но очень часто так не бывает.


а это проблема любой крупной системы. Как я уже писал, возможности человеческого интеллекта весьма ограниченны. В крупной системе невозможно знать все с уровнем детализации до машинных кодов. Именно здесь и работает ООД, позволяя абстрагироваться на любой уровень детализации системы.


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

Идеология программирования разная.
Как показывает практика, трудозатраты при структурном программировании нарастают экпоненциально по отношению к сложности задачи из-за слишком развлетвленной системы внутренних связей. ОО позволяет избежать этой проблемы. Это во-первых.
Во-вторых структурное программирование не позволяет масштабировать модель, в то время как ОО позволяет работать практически на любом уровне абстракции.
В-третьих, нативное человеческое мышление основано на ОО модели
В-четвертых, природа большинства решаемых на сегодняшний день проблем так-же нативно объектно ориентированная - что позволяет эффективно отображать проблему на ОО языках.
В-пятых, окружающий нас мир вообще нативно объектно ориентированный, и наделен хорошо различимыми уровнями абстракции - что опять-таки позволяет описывать его в терминах ОО языков.

Безусловно МОЖНО все это организовать и на структурных языках (ты нам уже приводил этот пример если помнишь   ), НО - молотком закручивать шурупы, согласись, не очень удобно   

все оно позволяет   
главное, чтобы руки были ровные и голова на плечах

пример






агрегирование - подход настолько мощный, что позволяет достичь любого уровня абстракции

Добавлено через 6 минут

не хочу заново начинать   

ps. молотком мы шуруп вряд ли _закрутим_  

Добавлено через 10 минут и 51 секунду

ага

забить гвоздь молотком или потребовать у молотка забить гвоздь   
кто не понял
work(m) и m.work()

J0ker, 
кстати, я так и не понял, причем здесь повторное использование к ОО языку?   
очевидно, что мы с тем же успехом можем повторно использовать структуры и работающие с ними функции (кстати, не зная их внутреннюю организацию)
пример - cURL

пардон за самоцитирование


дальнейший пример - проблема в том, что данные которыми ты оперируешь - общие - они никак не защищены от некорректных воздействий - это одна из ключевы проблем структурного программирования, которую исправляет ОО. Основной смысл ООП - объединение данных с операциями, которые можно над ними совершать и разграничение доступа к данным как собственности объекта. Ну и так-же возможность построение иерархий.


абстракции невозможно достич без виртуальных функций


ну надо-же, хоть в чем-то мы пришли к общему мнению   



worker.DoWork(hammer);
мы пожалуй обойдемся без волшебных самозабивающих молотков 

Добавлено через 2 минуты и 3 секунды

эээ... я тоже не понял
еще я не понял почему ты ко мне с этим пристаешь  

Добавлено через 4 минуты и 9 секунд

безопасность типов???   

только на уровне кода
а проблемы нет на самом деле
программист, осуществляя RAW доступ к структурам не используя документированные интерфейсы, сильно рискует
это категорически неправильно и является только его ошибкой
хотя это даже не ошибка, а отсутствие элементарной логики
если человеку говорят используй это, а не это, а он продолжает использовать второе, то извините, но он, мягко говоря, неадекватен


а ops здесь что по-твоему?   
для каждого типа сокета свои операции
по сути ops - набор виртуальных методы базового абстрактного класса struct socket (в терминах ООП)




человек не может обладать работой, т. к сущность "работа" - не материальна
это просто последовательность действий с объектами работы
так что 
DoWork(worker, hammer) aka работа выполняется при помощи рабочего и молотка   


твоя цитата?

"достаточно знать как работают уже изобретенные и области их применимости" != повторное использование кода?   



читай самый первый абзац

Что пузырь? Если ему это не мешает выполнять свои обязяности, то зачем ему это знать? Да, в качестве повышения общей образованности полезно, но не критично.

В жизни есть дела не менее прекрасные чем программирование. И зацикливаться на нем не стоит. И всё что помогает достичь цели с минимальными сроками и при этом не потерять в функционале - это благо и к этому надо стремиться.

этого достаточно для компрометации   


ну вот видите - если бы вы мне это сейчас не сказали, я бы не знал, что для каждого свои   


а он и не обладает - работа - это его поведение
для создания более сложного поведения (ака обучения) работу можно инкапсулировать в сущьность - скилл - но даже тут работа будет поведением


ага, а хвост вертит собакой? или собака вертит хвостом?   


безусловно


ты являешь собой яркий образчик структурного программиста даже по жизни
видишь-ли, для меня контекст играет весьма ключевую роль (впрочем как и для любого нормального человека (помнишь, яговорил о нативности мышления?))
я не знаю, было-ли это намеренным, или-же это следствие мышления структурного программиста   
НО, все-таки контекст




читай самый первый и самый второй абзацы   

сочувствую
на С ты точно не программировал, имхо  


вертеть = функция = поведение
поведение "знает" об объектах поведения, иначе оно, представляя собой код, не имеет смысла   


я не понял, в хорошем или плохом смысле это сказано?
также я не понял, как связан контекст и структурное/ОО программирование
и наконец, "структурный программист" это тот кто пишет на структурных ЯП или тот, кто пишет в структурном стиле?   


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

не
я просто мысли читать не умею   


вопрос был собственно кто кем, а не что делает... хотя вопрос мне казался очевидным... странное у вас мЫшленье   




ты не находишь некоторого противоречия?


в нейтральном
я просто факт констатирую


не верю, что не понял
ты при цитировании вырезал фразу определяющую контекст
ну если хочется перечитай тот пост, который цитировал


программист, который ДУМАЕТ в структурном стиле   


ну для ОО программиста - огромная   


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


в свете вышесказанного я теряюсь в догадках   

не
скорее всего я прав 
 



неа
работа не материальна, 
это последовательность действий связанных с объектами этих действий
последовательность описывает, что делать с объектами
в данном случае материальны объекты   
термин "знает" здесь был применен не в контексте того, что работа материальна, а
в контексте того, последовательность действий _предусматривает_ наличие объектов

  


а, ну тут как говорится, каждой задаче... (если речь идет про меня)
где-то больше подойдет ОО подход, где-то структурный



вообще говоря, по тексту контекст можно придумать практически любой   
он субъективен зачастую
а вывод о повторном использовании кода вполне логичен, ибо
повышается уровень абстракции -> формирование независимых завершенных блоков  -> повторное использование кода -> возможность построения на основе этих блоков более сложных структур




тогда возвращаемся к вопросу




объясняю
начнем с конца

т. е чтобы осуществить

но в то же время

ведет к тому, что

и в то же время устраняет


теперь видно?   

а теперь сравним с:
объект А совершает некоторое действия используя объект Б
причем ИМЕННО объект А совершает - т.к. он это умеет
правда нативней? (для нормального человека конечно   )   
а вот у тебя получается, что есть какая-то работа-не-пришей-кобыле-хвост, которая то-ли совершается объектом А над Б, то-ли совершается объектом Б над А, то-ли совершается дружными усилиями А и Б (ага, рабочего и молотка  ), то-ли совершается сама по себе над объектами А и Б


ну знаешь дАрАгой товарищ, совесть надо иметь
этот "по тексту" - единственная строка из цитируемого тобой абзаца, которую ты вырезал
тут уж трудно не заподозрить намерение   


да он (вывод) может быть каким угодно - главное что к делу он не относится, ибо злостный поклёп   


не совсем понимаю, о чем вопрос - о моем высказывании или о контексте в программировании?


видно ЧТО????
как с этим "видно" сообразуется фраза 

???
я все больше и больше в непонятках