Frog, поясни пожалуйста вот этот момент. Что ты имел ввиду?

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

Добавлено @ 16:00 
Но теперь и телефоны получше стали, я сейчас использую огромное кол-во классов, и ничего... пока работает все нормально

Пожалуйста - классическое ООП предполагает использование классов и  наследования , где общие для всех классов методы наследуються от родительского класса . Взаимодействие между обьектами приложения проис ходит путем вызова соответствующих методов  классов , от которых данные обьекты были произведены.  Таким образом код оказываеться поделен на удобные , небольшие части - классы и методы , исключаються повторения кода , возможность утилизации кода в иных приложениях ессесно тоже улучшаеться. Всем известны выгоды и удобство ООП. НО - увы - за все надо платить -
многочисленные обьекты легко фрагментируют память (особенно heap ,без динамичекой аллокации ) ,а их создание порождает огромное количество "мусора" усугубляющего проблему. А главное - обращение к методу обьекта , причем даже к методу принадлежашему данному обьектку (!) занимает ,увы, значительное время ,иногда порядка сотен миллисекунд , что ,если Вы пишете игру ,или графически нагруженое приложение , и вынуждены перерисовывать экран хотя-бы 10-15 раз в секунду - недопустимо много. Причем торможение на вызовах методов совершенно не зависит от типа компайлера JVM (будь он AHEAD или JIT) или свойств самих классов ,будь они ,скажем , static или нет ... Понятно что на мощных девайсах типа 6630 или К700 торможение менее заметно ,однако для коммерческого кода ,расcчитанного на большое число телефонов, применение того самого процедурального кода оказываеться необходимым.
Процедуральным кодом принято называть код прямо описывающий действия программы - то есть , для J2МЕ игры - у нас есть только два класса - MIDlеt (он мал, но не может быть подвергнут обфускации - потому и вынесен), и самой игры - в классе игры все действия игровых персонажей и состояний (меню,плей) описаны последовательно ,управляються switch(aми) и if/else статементами ,причем всячески избегаються не только методы ,но и циклы (тоже жрут немало процессорного времени) - так писали еще на заре компютерной эры  - понятно что код получаеться длинный ,сложный , малопригодный для повторного использования в других играх/приложениях.  Зато сей код предельно быстр, и один раз загрузившись обьектов не плодит и память не фрагментирует.  

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

Добавлено @ 16:25 
to WOLF - а get и set методы для переменных Вы используете ? ООП - это целостная система и философия прежде всего , а не то или иное количество классов в приложении.

Это сообщение отредактировал(а) Frog - 21.8.2006, 16:19

Я до этого два года на с++ сидел. ТАк что наверно использую. И не надо тут рассказывать про ООП. Гради Буча наверно все читали. 

У меня есть знакомый, которого кол-во классов никогда не смущало, и он не использовал процедурный код. Он просто написал приложение, которое на уровне байткода ООП превращало в процедурное. И мы использовали ООП в полном его объеме, а при компиляции оно превращалось в 2 класса.

Добавлено @ 17:15 
И вообще, если не нравится j2ME - не надо ее здесь опускать ниже плинтуса

Не следует возводить технологию в ранг фетиша - четкое виденье текущих недостатков J2МЕ не делает ее менее ценной в наших глазах , а позволяет создавать более продвинутые програмные продукты.  
Собрать из ООП кода - процедуральный действительно возможно при использовании препроцессора при компиляции , я однако , предпочитаю писать вручную - для лучшего контроля . 
Рассказывать о путях создания програмного обеспечения ,а так-же обсуждать как общую стратегию так и частности - полагаю необходимым. Тем более что Гради Буча я не читал - до всего доходил своим умом , не без помощи добрых людей на форумах ,конечно. А вот использовать get и set методы для J2МЕ приложений - не рекомендую - это-же не С++  

Это сообщение отредактировал(а) Frog - 21.8.2006, 18:32

Мне кажется что чистота кода и алгоритмизация зависит от конкретного кодера. Можно написать всё в одном классе и потом вызывать методы (аля процедурный подход), а можно разбить на классы и реализовывать всю модель приложения дискретно, вызывая теже get и set без проблем для производительности. Я используювсегда второй подход и никогда бы не сказал что программирую с помощью процедурного подхода. Использую и наследование и интерфейсы (где модель приложения требует какой-то абстракции). Java достатчно ОО язык и не пользовться его приемуществами мне кажется плохо. А что касается производительности, то нужно для каждого устроиства компилить свой код, т.к. метод вызываемый (например) в Нокии будет тормозить в Мотороле (для каждого девайс свой код оптимизации, потому что техническая реализация хоть и похожа, но реализация разная). 
/информация с конференции Sun'a/

Конечно , существует огромное количество приложений в которых нам не требуеться перерисовывать экран телефона >10 раз в секунду , кроме того - для игр - если игра не слишком насыщена графикой , количество и размеры выводимых в кадре картинок не велики - то проблемы оптимизации отходят на второй план - и можно наслаждаться ООП кодингом в полной мере. Проблема в том, уважаемый Javastic , что именно в нагруженых графикой и логикой играх мы начинаем остро чувствовать даже разницу в скорости выполнения циклов - так "for где i++" работает явно медленнее чем "for где i--" - не говоря уж о вызове метода раз во фрейм , или там вложенных циклах - в текущих реализациях J2МЕ мы лишены возможностей ООП программирования именно там где оно нам больше всего нужно - при решении тяжелых ресурсоемких задач  - и это обьективно , и не зависит от вкуса - пока не сольешь все методы в один , и не пораскрываешь циклы - игра будет тормозить. А поскольку Java являеться буквально квинессенцией (эк завернул) ООП , то процедурально с ней работать неудобно и неловко. Таким образом, на мобильных девайсах, преимущества технологии Jаvа фактически сведены к нулю , а иной раз могут быть прямым недостатком (пример - фрагментация heap-memory наплодившимися многочисленными обьектами и завис приложения).

Полагаю ошибочным мнение что с ростом мощности телефонных процессоров проблема несовместимости с ООП снимиться и дальнейшему процветанию J2МЕ уже ничто не помешает- дело в том что высокая мощность позволит использовать еще более простые средства разработки - ту-же Flash Lite ,которая ,кстати ,уже наступает на пятки - в частности меня тревожит отсутствие интереса к J2МЕ у производителей мp3 и мультимедия плееров - многие имеют подходящие экраны ,джойстики , казалось-бы Java-игры (установка с компа) были-б к месту - ан нет - не поддерживают  ( Flash Lite зато поддерживает iRiver U10 - по крайней мере)

Это сообщение отредактировал(а) Frog - 23.8.2006, 02:37