Ru-Board.club
← Вернуться в раздел «Прикладное программирование»

» В чем преимущество ООП ?

Автор: Pinocchio
Дата сообщения: 24.12.2004 15:35
vserd
Спасибо, - интересная информация. Только я уже бояться начинаю - там что и OLE автоматизация была? То есть я мог из другого языка (например любой паскаль от Turbo до Delphi) взять Excel за ячейку и впихнуть в него OleVariant (или на подобие его)?

Вообще я пытался склонить аудиторию что MSIL это путь к серьёзной интеграции, а InProc/Local/Remote это сиюминутно. Чё то у меня IDispatсh какой-то не такой всегда когда софт меняют перекомпилировать всё приходится. Оказалось всё не так, видимо я не пентрю и не канаю. Ну извиняйте меня неуча. Тока сначала сами попытайтесь всей этой автоматизацией на компе без сырцов MFC и Си компиляторов воспользоваться. Думаю что только те кто попробовал, понимают о чём я говорил.
Автор: UncoNNecteD
Дата сообщения: 24.12.2004 15:41

Цитата:
Да и не думаю что он бы работал быстрее и надёжнее реализованного на DirectShow

А зря.
Опять же, мы можем путать - идеалогию и свойства ООП, то есть пользоваться готовыми компонентами, которые универсальны - это на мой взгляд тенденция проявления слабости программиста. Специальное - хуже универсального.
Опять же - писать программы используя объекты - когда пишешь их специально под этот проект - это в принципе иногда полезно и удобно.
Автор: Dimonka
Дата сообщения: 24.12.2004 18:38
UncoNNecteD

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


Это экономит время программиста и средства клиента.
Есть например области, в которых заведомо бессмысленно возится самому. Например возьмём такую часть программы, как движок баз данных. Сколько будет стоить клиенту написания движка баз данных под проект? Сколько-сколько? А сколько будет стоить клиенту сопровождение самопального движка?
Наверное всё можно написать самому и с нуля, да только это не то, что никому не нужно - это вредно (!!!) разбрасывать свои силы и придумывать велосипеды (когда все уже на самолётах летают).
Автор: UncoNNecteD
Дата сообщения: 25.12.2004 15:51
Dimonka
Главное найти определенную грань.
Автор: vserd
Дата сообщения: 27.12.2004 15:42
Pinocchio

Цитата:
Только я уже бояться начинаю - там что и OLE автоматизация была? То есть я мог из другого языка (например любой паскаль от Turbo до Delphi) взять Excel за ячейку и впихнуть в него OleVariant (или на подобие его)?

А фиг его знает. Что-то было, но насколько оно работало я не знаю. Мне для своего проекта хватило и DDE.
У меня OLE не заработала так как я хочу, поэтому я его забросил. Хотя вполне возможно что я его "просто готовить не умею" )). Сколько раз пытался запустить в тестовых системах, ни разу не получилось. Вечно какие-то ограничения, утечки памяти, не работа так как я хочу, сложности с возвратом результатов.
Да и отсутствие доки на объекты тоже не сахар.
Автор: Pinocchio
Дата сообщения: 29.12.2004 12:14
vserd
По моему никто даже не понял что я спросил (включая меня). Кажется MSDOS3.0 - NowellDOS7.0 были не мультизадачными. Размер параграфа памяти был 16байт а сегмент 64кбайт. Единственная возможность одновременной работы разных EXE была основана на резидентах. По крайней мере игрушки приходилось взламывать сканнируя 64кбайта сегмента данных прерванного процесса. Так что у EXE спрашивать было нечего если его CS:IP в стэке. Разве что зная формат экселовского файла (или имея .h .lib .obj от майкрософт). Так что какое тут OLE . Тока DDE на W3.11.

Да, я думаю они всё таки правы. Не прокатит .NET за технологию. MSIL раскритикуют и в будущем все будут писать только ActiveX компоненты, а тех кто свяжется с .NET будут считать еритиками и отступниками. Подумать только - какая наглость, желать наследования объектов из DLL, тем более в 1995. Даже сейчас никому не известно понятие "отложенный линк", "биндинг паттерны". Суть таблицы интерфейса понимается РАЗРАБОТЧИКАМИ с трудом, а единственно правильная трактовка аггрегации эта та, что даёт БУч. Эдак программеры ёще лет 10 подождут, за одно ActiveX освоят. Рано ещё .NET на ранок выпускать, конкуренты будут. Всё, решил, стираю Framework нафиг, буду досовский Word и Excel осваивать. Вот это ИНТЕГРАЦИЯ!!! :|
Автор: vserd
Дата сообщения: 29.12.2004 13:57
Pinocchio

Цитата:
Всё, решил, стираю Framework нафиг, буду досовский Word и Excel осваивать. Вот это ИНТЕГРАЦИЯ!!! :|

Ты чего ерничаешь?
поясни по понятному. А то как оранжевый, кто не снами тот против.

Если комуто не нравится твой любимый продукт, это не повод "матюкаться". Вроде ты уже вышел из того возраста когда те кто не используют определенную технологию/язык/среду разработки объявляются ламерами?

Кстати, а в мире OLE есть стандартный интерфейс (GUID) тестового редактора?
много не нужно. буфер обмена + поиск/замена, максимум проверка грамотности?
Автор: Pinocchio
Дата сообщения: 30.12.2004 07:36
vserd

Цитата:
Ты чего ерничаешь?
поясни по понятному. А то как оранжевый, кто не снами тот против.

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

Попробую объяснить запутанно и не мудрёно, что мне мечтается хотеть. Например пишу я следующее:

Код: TMyClass2 = class(TMyClass1)
Автор: vserd
Дата сообщения: 30.12.2004 13:15
Pinocchio

Цитата:
При этом я знаю что методы TMyClass1 находятся в "MY1.DLL", а методы TMyClass2 находятся в "MY2.EXE". И следовательно когда я пишу "inherited" он прыгает именно в DLL.

Ты наверное хотел сказать что не знаешь конкретно где сидит код TMyClass1?
Главное что знаешь о существовании такого класса и выполняемых им действиях?
х.м. я ЗА. Обеими руками.

Скорей всего это появится, просто еще не пришло время, да и эта идея не совсем растиражирована. А значит не обсуждается и не обдумывается. Ты посмотри с чего начался топик. С вопроса о том ЧТО ТАКОЕ и КАК Я МОГУ ИСПОЛЬЗОВАТЬ ЭТО В СВОИХ РАБОТАХ.
А твой взгляд это уже следующий этап, может даже не один :)).

Нету нормальной не говоря о Хорошей или Отличной литературы на тему использования ООх (или я о ней не знаю). Да Буч хороший, но он один. Это его взгляд на жизнь в ООх. У тебя другой взгляд, немного (или много) отличающийся от Буча, но ведь ты не пишешь книгу об этом? А значит твоего взгляда люди не знают и не могут сделать DIff между взглядами. Куча книг авторов которые учат как ОО программировать на конкретном языке, а Буч рассказывает что нужно думать в терминах объектов, не зависимо от языка программирования.

А вот то, что мне не нужно знать, где хранится код который выполняет этот класс является важным свойством, но свойством техническим, и не явным. Даже не всегда осознаваемым подавляющим большинством авторов и читателей. Если удасться поднять эту проблему на осознание, тогда и появится решение. Может на подобии (или основе) OLE, может другой методы.

Я когда в первый раз читал Буча думал, во классно, но как применить, у меня вся программа "не объектная" "по природе и жизни"?. А недельки через 3-4 появился первый объект, т.к. код был похожий. Делал рефакторинг и вспомнил о объектах, дай думаю попробую.
И пошла работа. А когда у Пачеко увидел что и формы можно наследовать, то вспомнился целый пласт FAQ и ссылок который до этого не понимался и работа пошла.

А Фаулеровский "Рефакторинг" это еще одна ода класной книжке. То что сам делал на инстинктах и не всегда осознавая зачем, вывелось на осознный уровень и повысило качество работы. Так и TDD.

P.S. перечитал тему и понял что немного совравши. Когда я говорил что VB был в MS Office я имел ввиду версию word 6.0- 7.0, Excel 5.0 и выше. Под дос использовал ME да Turbo.exe :))), под конец активной DOS-жизни "Слово и дело" но он мне не нравился.
Из электронных таблиц Super Calc. В ME были скрипты, да еще какие!!!!. практически все что хош можно было сделать. В Super Calc тоже был язык програмирования, но я его не помню, помню что программу писаную на нем сопровождал.
Автор: Pinocchio
Дата сообщения: 30.12.2004 15:06
vserd

Цитата:
Ты наверное хотел сказать что не знаешь конкретно где сидит код TMyClass1?
Главное что знаешь о существовании такого класса и выполняемых им действиях?
х.м. я ЗА. Обеими руками.

Да но только я хочу не знать где находится TMyClass2. Имеется ввиду что мне не придётся ехать через всю Россию на предприятие чтобы менять весь софт. Допустим абстрактный класс станет кроме сокетов использовать и ком-порты. Экзешник скачает апдейт DLL-ки из интернета самостоятельно и заменит TMyClass1. Очень хочется чтобы TMyClass2 без DLL ничего не делал.

Добавлено
Буч хорошь, но я немного ранее познакомился с китами ООП, чем вышла его книга. Мои взгляды не сильно разнятся с его взглядами на ОО. Например мне кажется он маловато значения вложил в делегирование. Кажется он не ставит этот термин наравне с полиморфизмом. Для Delphi это более актуальный механизм. Но это всё нюансы.
Автор: vserd
Дата сообщения: 30.12.2004 16:00
Pinocchio

Цитата:
Да но только я хочу не знать где находится TMyClass2.

Не понял.
TMyClass2 это твой класс. Который ты разработал и распространяешь. куда ты его поместишь твое решение как разработчика (DLL, OCX или другое). Но для всех пользователей твоего класса (TMyClass2), как и для тебя как пользователя TMyClass1, совершенно все равно где находится код. Админ пользователя устанавливая твое приложение, физически его может поместить в разные места. О которых ты даже и немог подумать в кошмарном сне :) Но главное что система правильно его выполняет.

Цитата:

Имеется ввиду что мне не придётся ехать через всю Россию на предприятие чтобы менять весь софт.

А это зависит от уровня их спецов.

Цитата:

Допустим абстрактный класс станет кроме сокетов использовать и ком-порты.

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

Цитата:

Экзешник скачает апдейт DLL-ки из интернета самостоятельно и заменит TMyClass1. Очень хочется чтобы TMyClass2 без DLL ничего не делал.

Причем здесь механизм обновления и функциональность класса?. Ты не можешь гарантировать что админ заменил класс на новую версию. но можешь проверить версию класса. И сказать что немогу работать, т.к. отсутствует нужная версия класса.
Кроме того, админы щас очень отрицательно относятся ко всем системам, которые самостоятельно выкачивают что либо и тем более устанавливают в систему. И я их поддерживаю. А еще лучше, что бы TMyClass2 обеспечивал функционирование на уровне предыдущей версии.
В моем представлении, должен быть механизм, по которому я запрашиваю нужную мне функциональность. Получаю список компонентов которые могут их реализовать. выбираю нужный и работаю с ним. Если функциональность не доступна, тогда либо ограничиваем функционал максимальной версией которую можем реализовать, либо невозможностью работать.

Вот была нужда в простом текстовом редакторе, этих редакторов как грязи, но нет в системе общего места чтобы запросить а кто реализует эту функциональность?
и получить в ответ MS Word, Write, Notepad, OpenOffice Write, StarOffice write, Вася Пупкин СуперРедактор. мне пофигу кто из них. Я должен знать что предпочитает конкретный пользователь (или админ) на этой машине, чтобы дать выбор в настройщике да что вызвать в моей программе автоматом.
Мне нужно отдать ему текст в определеном формате, и получить его назад. Что пользователь делает и как мне пофигу.
Автор: Pinocchio
Дата сообщения: 07.01.2005 01:37
vserd
Всё это очень хорошо, окромя действительности.
1) Допустим кроме текстовых редакторов существуют задачи поважнее, в которых админы, как бы мягче сказать, слабо участвуют. И это к лучшему, если говорить об Автоматизированных Системах Коммерческого Учёта Электроэнергии (сокращённо АСКУЭ). Например предприятие выпускает плюшевых мишек марки Вася-Пупкин. Но оказывается, что если они поставят себе АСКУЭ, то за электричество станут платить в три раза меньше, а это значит (для крупного предприятия), что всем зарплату можно сделать в два раза больше. На предприятии имеется свой отдел АСУ, но никто из сотрудников АСУ не считает, что его профессиональный уровень вырастет, если он начнёт ходить по цехам и налаживать аппаратуру, поставленную к ним на предприятие сторонней организцией, поставляющей электричество. Бабушки которые за этой фигнёй смотрят не смогут оценить этого по достоинству. Так же как они не смогут самостоятельно сделать Update для серверов опроса специфического оборудования.
2) Для EXE файлов несколько проблематично перезаписывать самого себя, когда это самоё находится в исполнении. Наверное система устанавливает эксклюзивные права к EXE файлу на момент исполнения программы. Однако это совсем не относится к DLL - её элементарно выгрузить заменить и снова загрузить.
3) Что такое EXE? Это только расширение к коду, для того чтобы система пустила в этот код нити процесса. Ни о каких OLE тут речи нет. Я уже очень успешно проделывал трюк размещения объекта TApplication в DLL. Никаких проблемм с передачей хэндла нету, а это означает, что и главное окно (MainForm) и обработчик кнопки Task (Application) могут прекрасно жить в DLL. Экзешник из моего примера вообще не знает ни одного визуального класса, только мьютексы, INI и реестр, если есть желание могу скинуть прогу с исходниками. Но это тоже крайность, которая вовсе не обязательна.
4) Мне достаточно состряпать программу умеющую брать окно свойств объектов из DLL. После того как мы вспомним, что данные этих объектов находятся в базе данных, структура которых тоже может меняться, станет понятно, что несколько логичнее в DLL держать объекты, а не только окна свойств. Окна свойств в DLL это уже реальность, тут ничего необычного.
5) Зачем вообще деление EXE/DLL. Ну представь, что случилась некоторая фигня с пром-компьютером и тебя сажают на вертолёт (билеты из твоего кармана), и летишь ты скорым рейсом для решения проблемы на месте (допустим Иркутск плюс 5 часов к московскому времени). А ведь мог чуть раньше потратить немного времени на HTTP компоненты? Потратить денёк на отладку скачивания и замены DLL? Ничего сверхестественного, не правда ли?
6) Что такое TMyClass2? Так это просто привязка нормального класса к визуальному интерфейсу. TMyClass1 - это тоже МОЙ класс, что уже понятно из названия, но только он более значительный, так как реализует функционал, который задействуется с помощью второго класса. И EXE-DLL и TMyClass1-TMyClass2 уже существуют и работают, но нет в исходниках той красоты и осмысленности, которая могла бы стать нормой ещё 10 лет назад.

p.s.
Я думаю что не нужно объятнять почему админы не допускаются к опломбированным ящикам внутри которых находятся компьютеры имеющие одну единственную программу. Админов я очень уважаю, но бывают задачи, которые относятся не к их компетенции и думаю, что они за это не в обиде. Я считаю что админ должен весь день сидеть в Диаболе, а не бегать по предприятию с обновлениями печатных форм для плятёжек.
Автор: aqval
Дата сообщения: 07.01.2005 07:43

Цитата:

Ядро Linux написано на языке С и ассемблере. Был найден обычный компромисс между этими двумя языками: код на С более переносим и прост в поддержке, тогда как код на ассемблере обеспечивает большую скорость выполнения. В общем случае ассемблер в ядре используется только в тех местах, где наиболее критичным показателем является скорость, либо там, где требуется реализация кода, специфичного для конкретной платформы (например, кода непосредственного доступа к аппаратуре управления памятью).


Цитата:

Так сложилось, что части ядра компилируют в gcc (компилятор GNU C++), несмотря на то, что возможности объектов С++ не задействуются. Хотя объектно-ориентированный код С++ не характеризуется большой избыточностью, даже небольшая избыточность разработчиков ядра не устраивает.


Цитата:

Например, давайте обсудим частоту использования goto в ядре — во имя скорости ядро частенько прибегает к этому обычно нежелательному оператору. В почти 40000 строк кода goto встречается более 500 раз, т.е. один goto на приблизительно 80 строк кода. Если не принимать во внимание ассемблерный код, получается один goto на около 72 строк. Справедливости ради следует отметить, что такая частота использования goto связана, прежде всего, со спецификой выбранного кода — в основной части ядра, рассматриваемой в книге, наиболее важным требованием является скорость. Частота использования goto для ядра в целом составляет один goto на 260 строк, что представляет собой довольно большое значение.

Цитаты из книги "Ядро Linux в комментариях" Скотт Максвел

Так что, даже гуру программирования не всегда применяют ООП.
Автор: vserd
Дата сообщения: 11.01.2005 15:44
Pinocchio

Цитата:
Я думаю что не нужно объятнять почему админы не допускаются к опломбированным ящикам внутри которых находятся компьютеры имеющие одну единственную программу.

А к таким компьютерам не допускаются и остальные люди, даже с очень большими знаниями в этой области. В таком аспекте у тебя в 90% случаев инсталяциий не будет доступа к Inet и в 80-99, (9)% даже доступа к одному компу с которого можно обновить программу централизовано. В моей микро практике в этой области, это не реально было по чисто физическим причинам.


Цитата:
Но оказывается, что если они поставят себе АСКУЭ, то за электричество станут платить в три раза меньше, а это значит (для крупного предприятия), что всем зарплату можно сделать в два раза больше.

Ну автоматом они не уменьшат энергопотребление, это уже административными и модернизационными методами делается. А вот увидеть куда и сколько утекает, да на разных сменах по разному, хотя делают одних и тех же мишек. АСКУЭ это инструмент измерения ресурса, причем довольно гибкий и мощный. И оправдывает свою стоимость приобретния и эксплуатации.
Да и сомневаюсь я что сократив энерго потребление в три раза, можно повысить зарплату в два раза. Чисто из поврхностного курса экономики в универе. :)))))


Цитата:
. На предприятии имеется свой отдел АСУ, но никто из сотрудников АСУ не считает, что его профессиональный уровень вырастет, если он начнёт ходить по цехам и налаживать аппаратуру, поставленную к ним на предприятие сторонней организцией, поставляющей электричество.

А это как руководство себя поведет, да ты в договор на поставку запишешь. Скажут что будут, и будут бегать как миленькие. А поставит себя начальник за Главного Царька, а ты в договоре этот момент пропустил, значит будешь ездить за свой счет к ним для обновления программы.

Кстати, возможно сбытовики и разработали такую систему (хотя я сильно сомневаюсь, у них мотивация другая, чем больше потребят, тем лучше), но у меня это была фирмочка из 5-7 человек, которая обслуживала 3 области. паралельно с другими проектами и инсталяциями. Работали по принципу разработали, устанвили, запустили и забыли. Если находится новая возможность обновить/расширить и заказчик готов за это платить тогда да, модернизировали. Все проблемы и ньюансы обычно решались на этапе опытной эксплуатации. Ну и с числом инсталяций проблем с заказчиками было все меньше. Опыт однако. :))))

А бабушки и не должны, у них вобще дожно быть минимум кнопок и максимально простой и понятный интерфейс.

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

Цитата:
Так что, даже гуру программирования не всегда применяют ООП.

А ни кто не говорит что нужно применять только ООП, а все остальные методы нельзя. Каждой задаче свое решение и инструмент. Если поставить целью быстродействие, то можно такого кода написать, что когда потом будешь разбираться, то мат будет настолько плотным, что топор можно будет повесить :))). Но если писать такой код для пользовательского интерфейса, тогда стоимость его будет больше стоимости золота. Так что любой метод программирования, что процедурный, что объектный или любой другой ставит перед собой задачу уменьшения времени разработки, а соответственно стоимости.


Добавлено

Цитата:
Ну представь, что случилась некоторая фигня с пром-компьютером и тебя сажают на вертолёт (билеты из твоего кармана), и летишь ты скорым рейсом для решения проблемы на месте (допустим Иркутск плюс 5 часов к московскому времени). А ведь мог чуть раньше потратить немного времени на HTTP компоненты? Потратить денёк на отладку скачивания и замены DLL? Ничего сверхестественного, не правда ли?

Если случилась фигня с пром. компьютером, то либо тебя не будет на воле несколько десятков лет, если докажут что твоя вина и ты мог справится с ней путем резервирования, дублирования и прочего. И наличие связи с интернетом, сдесь только отягощаещее обстоятельство. Либо если маштабы помельче, твой вариант, но только за счет клиента, он не смог справится своими силами, путем замены на другой ТЭЗ, пускай платит. А я видел пром компьютеры, обыкновенная коробка с четырмя винтами крепления, и в моем случае, с 3 разъемами для подключения питания 220в, датчиков и коммуникации с вышестоящим устройством. Заменить ее сможет даже бодунящий электрик. Не говоря о инженерах из КИПА или на крайняк АСУ.
Если хочешь, то пром компьютер это обыкновенная запасная часть, которая возможно одинаково устроена внутри, но вот на внешние раздражители реагирует по разному. И отличает ее от другой, только децимальный номер на шильдике крышки. И если местные спецы изменяют децимальный номер внутри коробки через перепрошивку, но не меняют на крышке, это не твои проблемы. А если это делают твои сотрудники, то это брак, но и клиент должен смотреть, что ставит. А брак исправишь за свой счет.

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

И чем они тебе помогут если хакер, используя хитроумные приемы, подсунет вместо твоего обновления свое, которое полностью нарушит работу всего предприятия или будет вносить мало заметные сбои, которые вызовут дискредитацию твоей ситемы? Скажешь что это все из области фантастики? Так никто не знает пределов человеческой выдумки когда нужно сделать пакость другому :((((. Сотрудник которому выгодно дискредитировать твою систему может не обладать нужными знаниями, но может обладать другими ресурсами (включая умение общаться и воздействовать на других людей), чтобы попробовать такой вариант, либо другой, но приводящий к нужному ему результату.
Автор: aqval
Дата сообщения: 11.01.2005 17:00

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

Так для ядра ОС быстродействие только одно из важных требований. А самое главное - это надёжность (в самом широком смысле этого слова). Ядро линукса открыто и можно посмотреть , как там всё написанно. И пишется это командой.
Чаще всего забывается такое понятие, как организация труда, а это включает и выбор метода программирования со всеми достоинствами и недостатками.
Например по пользовательскому интерфейсу:
можно использовать компоненты сторонних разработчиков, что очень убыстряет процес, а можно самим писать компоненты- что долго и не легко, но потом можно и продавать собственные разработки. Так что на счёт стоимости вопрос спорный.
Автор: Pinocchio
Дата сообщения: 12.01.2005 09:51
vserd
Из вышесказанного можно сделать вывод, что Вы имеете достаточный опыт, чтобы понять, что я говорю. В Вашей ситуации всё верно и так и есть. У меня немного отличается. Думаю мне не придётся много объяснять. Во первых моя фирма давно работает в этой области и имеет свой опыт и свои сложившиеся взаимоотношения.
Во вторых опросник организован на сокетах и ящики после установки будут иметь свой TCP-шник. В третьих все случаи жизни имеют как правило локальный характер. У меня например ситуация когда новый софт считается необкатанным пока не отработает реально минимум полгода. Этого как раз достаточно чтобы привыкнуть к верталётам. И получается совершенно наобарот во всех этих стучаях инсталляции всегда имеется доступ в интернет. И все эти случаи укладываются в полугодовой срок. И практически во всех этих случаях необходимы только разовые переделки программы.

Но думаю мы увлеклись и отошли от темы. Ситуация когда неплохо бало бы иметь дистанционную динамически обновляемую DLL на стадии разработки и на стадии предварительной (тестовой) эксплуатации не вызывает удивлении даже у админов предпочитающих не программировать. Несмотря на то что они бывает не понимают простейших вещей в программировании это не значит что они дураки полнейшие и с ними нельзя договориться. Лично я дружу с админами и легко обговариваю ситуацию с DLL.

Напомню что речь шла об реальном наследовании объекта из DLL. Просто хочу именно чётко представлять где находится код моих объектов.

aqval

Цитата:
Так что на счёт стоимости вопрос спорный.

Да никакой он не спорный. Уже давно всем ясно (по трезвому размышлению) какой метод использовать в конкретно своём случае. Метафора (без пояснений):
* Если у меня работа за десять километров от дома, то каким бы я не был сторонником ходьбы пешочком мне каждый день приходится садиться в транспорт и ехать. А Вы предлагаете мне испытывать комплекс по поводу того что я не похож на знаменитых спортсменов.
Автор: vserd
Дата сообщения: 12.01.2005 12:04

Цитата:
Так что на счёт стоимости вопрос спорный.

Нет. Он не спорный. Он оцениваемый. И ключевой при принятии решения о целесообразности. Сделали с меньшими затратами, занчит больше заработали, занчит больше в карман положил(и). Вот только проблема в том, что не всегда можно заранее оценить что дешевле, купить стороннее или разработать свое. Использовать методологию А или Б. Что будет быстрее при заданных критериях качества.
Рекомендую прочитать "Путь камикадзе", и "Мифический человеко месяц" Брукса. Там это описано довольно просто.
Автор: aqval
Дата сообщения: 12.01.2005 18:52
Pinocchio
vserd

Такое ощущение, что вы завалены работой и деньгами на годы вперёд.
Кто-то ведь пишет компоненты и неплохо зарабатывает на этом, особенно когда не видно ни клиентов ни заказов и намечается застой в работе.
Автор: vserd
Дата сообщения: 13.01.2005 10:58
aqval

Цитата:
Такое ощущение, что вы завалены работой и деньгами на годы вперёд

Работой точно, а вот деньгами... это такое проходящее, сегодня это много, а завтра мало.
Так уж устроен человек.

Цитата:
Кто-то ведь пишет компоненты и неплохо зарабатывает на этом, особенно когда не видно ни клиентов ни заказов и намечается застой в работе.

Каждому свое. Кто-то специализируется на разработке сложных систем, и им писать свои компоненты не с руки, слишком дорого получается. А кто-то пишет компоненты, которые покупают писатели сложных систем :))), и тоже считает что зарабатывает не плохо, возможно что даже больше первого. А кто-то обслуживает творения первых двух, и тоже доволен работой.
Это реальность жизни. Если уйдет этот кусок сыра, нужно будет бежать искать новый. Такова жизнь. Крутишся и имеешь, перестал крутиться, будешь плакаться что "вот там больше, а у меня ничего", то и у тебя действительно ничего не будет.

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

Сегодня ООх дает преймушества, его и используем, завтра появится проект, который нужно сделать в структурном подходе будет сделан в нем. Не зацикливайся на одном, смотри по сторонам, самое вкусное лежит на границах областей, там денежные ниши, нашел разработал вот ты и в центре.
Автор: Pinocchio
Дата сообщения: 13.01.2005 12:32

Цитата:
Кто-то ведь пишет компоненты и неплохо зарабатывает на этом, особенно когда не видно ни клиентов ни заказов и намечается застой в работе.

Но только не в России (разумеется за некоторым исключением).

Добавлено
vserd

Цитата:
Да и сомневаюсь я что сократив энерго потребление в три раза, можно повысить зарплату в два раза. Чисто из поврхностного курса экономики в универе. ))))

Я выразился несовсем точно. Если исключить начальников, так как бывают предприятия, где на одного токаря одинадцать начальников (это из курса производстенной практики). При техническом учёте можно спрогнозировать потребление, а при "многообразии" тарифов будет легче экономить на штрафах и стоимости. Хотя технический уже даёт выгоду просто в потреблении. Между прочим в России достаточно предприятий где задержка по зарплате в один год, так что их нуль можно умножать вообще на любую цифру. Так нулём и останется.


Цитата:
Сегодня ООх дает преймушества, его и используем, завтра появится проект, который нужно сделать в структурном подходе будет сделан в нем. Не зацикливайся на одном, смотри по сторонам, самое вкусное лежит на границах областей, там денежные ниши, нашел разработал вот ты и в центре.

Судя по тому что ООП появился позднее структурного программирования (я не имею ввиду Палестину), можно сделать заключение, что ООП это следующий шаг к прогрессу. Обратное направление появится практически не может (хотя всё бывает). Скорее всего будет ещё один новый вид программирования и новые споры.
Автор: dikun
Дата сообщения: 19.01.2006 21:48
UncoNNecteD

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

Dimonka

Цитата:
Пример откровенно плохой.


Я так понял, что ООП не покатит, потому что частиц-объектов слишком много? Тогда - паттерн Flyweight
Автор: Alex770
Дата сообщения: 07.08.2007 14:04
Я сейчас начинаю изучать основы ООП, до этого имел дело только с функциями. Вообщем-то я понимаю его плюсы, но никак не могу представить где это может пригодится, а кто-то, как я понял, на классах все программы пишет. Вот единственное могу представить это ООП в игре. Например класс оружее, из него можно наследовать объекты меч, топор и т. д. Ну а например в программе для работы с базами данных, где можно применить ООП?
Автор: delover
Дата сообщения: 07.08.2007 15:17
Alex770
А чем тебе ADO не база данных? Это всё построено на интерфейсах. Написание базы данных, если сущности сделать просто данными, то в написании будет куча одинакогого кода с небольшими расхождениями, а если сделать объектами то кода понадобится намного меньше и читать будет удобнее когда привыкнешь.
Автор: vserd
Дата сообщения: 07.08.2007 15:41

Цитата:
Ну а например в программе для работы с базами данных, где можно применить ООП?

Есть базовый класс документ, от него наследуется "платежка", акт выполненных работ, ведомость на зарплату и т.п. и т.д.
Если правильно реализовать, то все телодвижения при добавлении нового типа документа сводятся к минимуму. Кроме того, ООП очень хорошо ложится в основу интерфейса для отображения данных из БД.
Автор: aslav
Дата сообщения: 10.08.2007 16:18

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


дело не только в настледовании. вот создал ты класс пистолет.

а затем тебе надо в программе два пистолета разного калибра. как ты с функциями тут будешь работать ?

а так - создал два объекта через конструкторы настроив и радуйся

а с функциями увы тебе придется много постоянно думать что там внутри нее если она одна или опять городить пару функций

если грубо.

а вцелом - пока реально не будешь с этим работать - плюсов не поймешь.

личто я использую ооп только там где оно нужно. т.е. лично в моих проектах - почти нигде
Автор: Qraizer
Дата сообщения: 10.08.2007 21:44
aslav
Это надо понимать так, что ты пока "плюсов не понял", потому как "реально не работал"? Можно наводящий вопрос: "Ну вот есть у меня fopen(). А если мне нужно одновременно два разных файла открыть?" А ведь stdio.h отнюдь не классы юзает...
Автор: Mickey_from_nsk
Дата сообщения: 14.08.2007 08:35
Alex770
Тут уже пару лет назад проскакивала ссылка на Буча. Прочитай. Написано просто отлично. После этого хватит одного небольшого проекта с объектами, чтобы открыть для себя великолепие ООП, а дальше и компонентно-ориентированного программирования.
Автор: aslav
Дата сообщения: 14.08.2007 08:59

Цитата:
Это надо понимать так, что ты пока "плюсов не понял", потому как "реально не работал"? Можно наводящий вопрос: "Ну вот есть у меня fopen(). А если мне нужно одновременно два разных файла открыть?" А ведь stdio.h отнюдь не классы юзает...


из пушки по воробьям не стреляют. к тому же С++ - язык почти умирающий, ниша для него все Уже и Уже. а использовать fopen вместо потоков только Архангельский учит.
Автор: delover
Дата сообщения: 14.08.2007 09:14
Qraizer
Смотря как открыть, если один файл текстовый, а второй архив и тебе надо чтобы в визуальной среде авторы архиватора могли настроить так чтобы архив открывался как папка с вложенными файлами. Сейчас без ООП нет интеграции. Самое безумное место это comctl32.dll и то там используются сообщения, с которыми удобнее работать объектам.
Автор: Qraizer
Дата сообщения: 14.08.2007 11:05
aslav
Это C++-то умирающий? Единственный в мире язык, который несмотря на то, что он программирования, изучается теоретиками (только зовутся они не филологами), как будто он естественный человеческий?? В котором делаются открытия, по исследованиям которого издаются труды, наверное даже защищаются диссертации??? И он, оказывается, умирающий! Ну ты дал. Скорее Windа умрёт, чем C++. Писать на плюсах - это не компонентами жонглировать, не каждому дано.
Ну и так, между прочим - ты не ответил на вопрос.
delover
Я не об этом спрашивал. Я намекал, что stdio.h - это та же объектная концепция. Только реализована на языке (я имею в виду C, без плюсов), который не поддерживает ООП явно. Вообще, пост aslav-а, на который я отвечал 10-08-2007, мягко говоря ошибочен. Сразу видно, что человек действительно "не использует в ООП", как он и признался. Ибо просто не видит, "когда оно нужно". ООП - это не свойство языка, это философия и стиль. Объектно программировать можно хоть на ассемблере.

Страницы: 1234567

Предыдущая тема: Сервис работы с файлами


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель - сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.