ООП против Процедур

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

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

_DEN_
Единственный мощный инструмент это голова у тебя на плечах. И именно наличие в ней мозгов отличает тебя от пещерного человека.

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

opennetworks
Когда у меня программа имеет обыкновение работать до поры до времени, а потом вылетает где-нибудь в процессе работы я использую отладчик в режиме Just in Time. Когда происходит ошибка и отладчик сработает ты, конечно попадешь в ntdll.dll, но оттуда можно вернутся по стеку в свой модуль к процедуре, на которой прога завалилась, и оттуда уже плясать. Если программируешь на чем-то делфеобразном, то там, конечно, тяжело что-то найти в коде, но проявив терпение можно разобраться, что же такого у тебя там происходит, что приводит к подобной ошибке.

 

+10!!!
Miller Rabin
Истина!

 

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

 

fluderast
Miller Rabin

Отдыхайте, ребята )

 

Тогда посмотри че за эксцепшн

 

Вот рантайм1

 

рантайм 2

 

Товарищи, спокойнее --

 

fluderast

Так уж и на 100%? А драйвер подсистемы Win32, например? И объектного кода в Виндовс становится всё больше.

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

Хотя не спорю, в некоторых случаях оптимален процедурный подход.

 

А интересно тут файлы качают -- основное приложение - скачано 3 а рантаймы - 1

Такое впечатление что тут все из одной конторы

 

Походу рантаймы скачал только я.
Как только будет время свободное посмотрю что там у тебя

 

Miller Rabin
Спасибо. Если нужны будут исходники - пришлю

А нафига остальным основное приложение без библиотек? У нас тут экстрасенсы наверное водятся -- исходники библиотек к ним в Нирване являются сами

 

Прочтение вышеизложенного навело мя на одну мыслишку...
Профессия "програмист" вероятно, накладывает отпечаток на образ мышления:
- if - then;
- "0" - имхо;
- "1" - куль;
При обсуждении подобных тем оператор if нетянет, тут даже switch не подходит.
Мир прекрасен потаму, что он РАЗНЫЙ.
Пользоваться ООП действительно проще. Не нравится придумки сторонних разработчикоф, напишите своё. Написал один раз грамотный CFile и юзай скока угодно. А создавать обращения к файлу в каждом новом пректе заново - это глупо ( или програмируем методом Ctrl+C -> Ctrl+V? ).

 

ViCooper
+1
Кратко и по делу, а главно метко выразился!

 

fluderast
Ты видать новичок в программировании

Задам вопросы:
1. Является ли программирование хобби, или же это профессия?
2. Как часто ты программируешь?
3. Какие задачи?
4. Как много людей работают с твоим исходным кодом?
5. как часто ты читаешь исходный код других людей?
6. Сейчас я опишу ситуацию, а ты опиши действия которые ты будешь делать(к примеру опишу структуру - ее члены, опишу прототип ф-ции - ее действия, опишу события - их обработчики и т.д.)
Ситуация:
Ты с друзьями пишешь компьютерную игру в духе 3d-Action. Наступает момент, что надо написать, нападение нескольких монстров, скажем 20, и каждый умеет нападать, но каждый это делает по разному(кто-то кидает топор, кто-то махает палицей и т.п.) все монстры умеют прыгать, но каждый это делает по разному, часть монстров умеет летать, но часть не умеет и лишь только со временем эта часть монстров, по мере прохождения игры, все таки учится летать. Все умеют подбирать предметы и швырять, но каждый берет предмет по своему, каждый швыряет по своему(ну мало ли, может у монстра рука гниет). Если попал снаряд на монстра то каждый по разному на это реагирует (кто то на 3 буквы посылает, кто-то рычит, ктото отлетает и т.п.)

опиши плиз, как ты это будешь решать? И как долго ты будешь решать? (оцени срок)

 

"...если перевести большой проект на
процедурный уровень то размер исходников будет
ОГРОМНЫМ - запутаешься."

Не похоже - если грамотно переводить, конечно. Как кто-то заметил, все методы классов останутся теми же - только с дополнительным параметром.

"ООП при желании можно и на асме реализовать"

На моём сайте есть статья если кому интересно. Не полно, но базовая постановка имеется.

"...зачем этот CFile вобще нужен?"

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

Примером можно показать зачем нужен CFile. Например, написана программа и _lseek() вызван в 100 местах в исходниках. В какой-то момент разработки (или сопровождения) проекта необходимо узнать на какое место показывает указатель файла после _lseek().

При процедурном программировании надо будет отследить и изменить все 100 мест в коде. А если у нас был ООП и есть такой CFile - то изменить надо только ОДНО место внутри CFile!

Допустим это было сделано для отладки. А после отладки надо вернуться к старому коду (без отслеживания позиции _lseek()). Опять менять в 100-а местах (процедурное) или в ОДНОМ месте (CFile).

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

 

Первые признаки мышления объектами

Я не человек с громадным опытом, но на работе с меня требуют проекты, которые надо решить "вчера", т.е. быстро!
Причем есть множество нюансов(форматов файлов, правил ведения баз данных и т.д.) которые необходимо знать не только мне, но и разработчику со стороны.

Что я делал раньше:
1. Подходил к коллеге, выспрашивал до тошно, где лежат файлы, как они устроены внутри, если нет уже доки готовой, а дока часто не бывает, иду пыхтеть над разработкой, а "вчера сдавать" уже между прочим наступило! С меня требуют, айда-ка не тяни!
2. Далее писал структуры, которые описывают формат файла, выносил в инклуд
3. Далее писал ф-ции и их выносил в инклуд, делал структуры локальными, что бы потом не мудрить как и что устроенно, все это а-ля: OpenFile, CloseFile, GetTValue, GetPValue(давление) и т.д.
4. В каждом новом исходнике я вызывал эти ф-ции и все вроде бы "ок"!
5. Приходит Петя Видит мой код, говорит его надо в топку, пишет свой, т.е. повторяет п.1-п4 и радуется
6. Придохит Вася видит Петин код не фига не понимает как надо это юзать, смотрит в мой код вроде чето понимет, смотрит в Петин опять, выспрашивает всех и вся - пишет свой код
7. Сторонний программист, пишет который прогу на заказ, принимает исходные коды от Меня, Пети,Васи , смотрит, видет что это все в топку - пишет свой
8. Повторяется, пока каждый программер свой инклуд не напишет

Что делаю сейчас:
1. Пишу абстрактный класс: - "Файл АСУТП" - ASUTPFile говорю в нем, что его можно открыть,закрыть, создать, записать\читать температуру, давление, и т.д. и т.п.
2. Пораждаю класс "Архив по №1" , реализовываю его в виде компонента на Delphi.
3. Делаю инсталлер
4. Ребята после установки моего компонента видят абстрактный ASUTPFile, тут же понимают раз у них это уже есть, это работает корректно, более того нет возможности посмотреть исходник и переделать все нахрен, начинают юзать и писать класс "Архив №2" и так до бесконечности и необязательно под Delphi.
5. Сторонний программер, плюет на наши старые сорцы, ставит компонент, смотрит на объявление абстрактного ASUTPFile и начинает его применять, т.к. не имеет возможности все переделать нафиг

в итоге. все привыкли и знают как работать с ASUTPFile и никто уже нехочет изобретать велосипед!
1. Повышается понимание исходного кода коллег ибо всем понятен ASUTPFile
2. Повышается скорость разработаки очередного проекта, т.к. никто не переделывает очередной раз работу коллег
3. Повышается надежность продуктов, ибо баги в одном месте (компоненте) и их ловить намного быстрее!

 

Не понимаю, почему многие поборники ООП пытаются присвоить себе написание понятного и хорошо структурированного кода. Это всё равно как если Вирт размахивая томиком (вариант: колодой перфокарт) с надписью "Algol W" уверял здесь нас, что на ассемблере невозможно написать нормальную программу, что из кода получается "лапша", а нам всем просто не дано понять стиль и красоту процедурного программирования.
Каждой задаче - свои методы решения. Если кодер самостоятельно ведёт небольшой проект он вполне может не придерживаться даже процедурного подхода, т. к. метка типа "endallbranch" и строка ";; save edx equ buferbase!" скажут ему о многом даже по прошествии некоторго времени, и он без всяких классов догадается, что send не делают в hFile, а CreateFileMapping не применяют к hSock. С другой стороны, если 100 человек, из которых 10 к концу месяца уволяться и будут заменены новыми, пишут монстров и пишущий "ковыряние пальцем в носу" не знает ответственного ни за "палец", ни за "нос", ни за "ковыряние", то ООП - лучший выход.

 

EvilsInterrupt
Вопрос первый:
Кто помешает Пете/Васе/Стороннему программисту усомниться в качестве реализации твоего компонента (учитывая к тому же, что они не видят реализацию, а должны поверить тебе на слово) и не переписать компонент заново?

Вопрос второй:
Кто помешает тебе скомпилировать первый вариант в статическую либу и отдать ее сторонним программистам вместе с .h, в котором будет описаны только структура и прототипы функций, чтобы они не читали твой код и у них не возникало желание его переписать? )

 

Mescalito
Метко сказал, по поводу текучки!
Именно это тоже является фактом, т.к. на нашем предприятии средняя зарплата Инжинегра-Программиста является 12000 - это средняя, я же тружусь за 8.000 руб. обещали повышения вроде вырастит до 10.000 (с учетом провинции, вроде хватает) , но человек хочет больше потому уходит, вот и остаются наработки Васи, Пети и еще бог знает кого!

rmn
Сторонний программист не усомнится! Более того это для него выгодно, это для нас будет плохо, если мой компонент глючный. Так как если он применит мой компонент из-за этого у него будут баги, то он имеет права сказать: "Ребата, а это ваша разработка! Переделывать буду но за отдельную плату", Нам это надо?
Нам надо чтобы он быстрее сделал прогу, а уж за правильность компонента мы сами побеспокоимся.

Выход, но у него будет уходить время,на изучение инклуда, могут возникнуть а нахрен нужна структура А, структура Б, ф-ция С, пока он не выяснит, он будет не спокоен, а это опять в лучшем случаее 1 день.

При работе с компонентом ему для успешной работы надо знать:
1. Что файл можно открыть Open
2. Что в файле могут быть температура, давление и т.д. и что их можно вытащать соглассно ф-циям в абстрактном классе а-ля: GetTValue, GetPValue etc.
3. Файл можно Create
4. Файл можно закрыть Close

четыре пункта читаются на ура, в течении 10 минут