Можно и без классов - напирмер oberon, javascript ... Классы это всего лиш способ реализации ООП в некоторых языках. В oberon (zonnon, blackbox) нету никаких классов, есть расширяемые структуры, есть модули.

+1
На практике комментарии не так уж полезны, как об этом теоретизируют, зачастую даже вредны. Надо чётко осознавать, что хорошие комментарии не дублируют код и не объясняют его, они лишь поясняют его цель, т.е. описывают намерения программиста, а не то, что он написал, т.к. сам язык программирования в этом плане гораздо яснее и лаконичнее. Если же программист не способен написать код, который понятен без комментариев(т.е. комментарии чуть ли не в каждой третьей строке), то с чего вы взяли, что он будет способен написать понятный комментарий    Такие комментарии вредны, и со временем вовсе рассинхронизируются с кодом, что приводит к тому, что неправильными становятся и код, и комментарии к нему.
Хороший код читается как простой текст на английском(пусть и немного корявый со стилистической точки зрения), и классы в данном плане отлично помогают. Но надо понимать, что классы - это синтаксический сахар, как тут уже говорили, т.е. они делают процесс кодирования более приятным, но отнюдь не обеспечивают ООП... 
ООП может быть без классов, а классы могут быть без ООП. Большинство противников ООП просто не осознают сей простой факт.
 

source777, *doc - это тоже комментарии, если что ;)

Поди напиши VCL на одних функциях и goto.

Хороший пример применения ООП это обертка GUI для WinAPI.

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

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

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

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

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

Вот такое вот у меня на сегодняшний день мнение)

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

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

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

Это сообщение отредактировал(а) Torsten - 11.2.2009, 20:12

Очень интересная тема.....

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

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

Архитектор продает продукт, Хакер свою работу.

Как правильно программировать, вопрос не принципа, а психологии.

Холерик и сангвиник - Хакеры.
Флегматик и меланхолик - Архитекторы.

 [offtopic] Я флегматик. => Я архитектор... Верно подмечено, мне ООП нравится гораздо больше процедурного стиля... И когда пришлось работать как-то с чистым WinAPI у меня промелькнула мысль: а почему бы не сделать обертку для всего этого с использованием ООП

Это сообщение отредактировал(а) Krawler - 15.3.2009, 17:34

 Кстати да, я тож например флегматик и ближе к архитектору, чем к хакеру...
Сейчас например LISP осваиваю, так первое за что взялся - объектная система... 

Объясню, за что я на функции взъелся: не люблю прыгать по коду и постоянно скроллить туда-сюда.

Я когда писал программы для себя какие-то, часто начинал(или продолжал) писать по "общим правилам" - мол, надо функции, одна функция делает одну штуку и т.д.

А через какое-то время в программе наступает тупик - не получается реализовать что-то. И я понимаю, что запутался в собственной программе.

Начинаю оптимизировать и понимаю, что программе не хватает комментариев. Делаю комментарии. А потом замечаю, что мне очень неудобно работаьт с функциями.

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

Добавлено через 6 минут и 33 секунды
И ещё меня бесят функции в учебных примерах. Очень неудобно читать. MSDN любит писать примеры программы "Hello, world!" кодом на 1000 строк, чтобы программа одновременно ещё и теорему Ферма доказывала(вдруг кто заинтересуется?), хотя я всего лишь интересовался "Console.WriteLine".

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

В то же время, если бы код был написал линейно, я бы сразу определил ненужные мне инструкции, пропустил бы их и дошёл до нужных, быстро найдя то, что я искал.

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

А ты пробовал именовать функции нормальными идентификаторами, а не такими дебильными как LetThisShitWork и Funktsiya?

P.S. Нехорошо откапывать такие старые темы  

Что ты имеешь в виду под словом "синтаксис"? Я плохо понимаю описания MSDN. Я гораздо лучше понимаю на примерах.

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

Я делаю функции с хорошими именами. А вот MSDN и многие авторы туториалов - нет.
А тему поднял, потому что возник непонятный вопрос.

На самом деле не так всё однозначно - я написал тот пост и сам засомневался) Но вот про туториалы и МСДН точно так.

slavaentp, незнаю, у меня доки в мсдн практически не когда не вызывали проблем с понятием кода по какой либо функции или классу, а если оттуда не мог уловить описание той или иной информации, потому что не всегда хватало знания моего анг =) то гугл выручал всегда.
Это на вкус и цвет, пасмотрите Java api doc у sun. там вообще сам черт ногу сломит (имхо естесно) по сравнению с MSDN

комментарии дело хорошее, когда ими пользуются осмысленно, про что сказал source777[/B) а не в стиле:

Код

//Объявляем переменную А int a; //Объявляем переменную B int b; //Объявляем переменную RESULT int result; //Складываем значение переменной A со значением переменной B и заносим полученный результат в переменную RESULT result = a + b; //etc

например если я объявил где то [b]простой метод к примеру:

я помечу его однострочным комментирием, иногда по ним проще ориентироваться, хотя задача метода часто бывает понятна из имени метода =)

Это сообщение отредактировал(а) Exai1e - 30.11.2009, 11:36

Убило