Ломка
10.11.2010 технологии о человеках
Ох, тяжело, тяжело… Вот вместо дела снова решил немного вам похныкать :) Переходить с традиционного процедурного стиля на объектно-ориентированное программирование очень непросто — что бы ни придумал, сразу тянет быстренько набросать в привычной манере.
Это также как с текстовым редактором. В своё время мне пришлось жёстким волевым решением просто удалить Geany, чтобы наконец-то начать изучать Vim всерьез. Это было правильное решение, но сначало жутко ломало, постоянно придумывал себе отмазки, чтобы не работать. Сейчас такая же фигня с моим первым классом. Он уже написан большей частью, но доделывать его — сущая мука.
Музычку послушать, посмотреть фильмы, почитать блоги, написать в свой блог, проверить комменты и 1000 раз на дню проверить почту, погрустить над пустым кошельком WebMoney (какого хрена никто ничего не покупает?!), поспать сутками… но только бы ничего не делать.
И так с любыми привычками. Я понимаю, что зону комфорта нужно расширять, но я слишком слаб, постоянно скатываюсь к тёплому привычному гнёздышку. Так никакого развития не будет, я деградирую и всё.
Комментарии
Комментирование этой статьи закрыто.
Та же херня, коллега. Я даже марафон себе придумал, чтобы хоть чем то занять, себя. А так то работы дофига, и твоя микротудушка разрывается от заданий. Невыполненных заданий((((
дадад...
ООП по какой книге учишь? От подачи материала многое зависит. Рекомендую «ООП на php» Кузнецова и Симдянова, сейчас сам читаю, хорошо так мозги вправляет.
PS
Хотя у меня опыта особо и нет, чтобы что-то толковое посоветовать, но может нафик ООП, если задачу проще решить процедурным стилем? Если не используется наследование, полиморфизм, то ООП ИМХО только во вред, больше кода, да и сам код менее понятным становится.
Я не учу ООП по книге, учу на практике + несколько статей прочёл из сети.
В случае класса для AvisoSMS ООП точно оправдано, я потом сразу же смогу тот же самый класс применить и в «Йерке» и в других проектах, вплоть до Daos 2.0.
Не меняя вообще код.
Такой подход – зло. Хотя еще несколько дней назад я был совершенно иного мнения и тоже думал, что изучение на практике самое оно. Оказалось, что ООП намного сложнее и что без хорошей теоретической подготовки полноценный ООП код не написать. Я вот раньше не знал о существовании __set(), __get(), __call(), __autoload(), о тонкостях использования конструктора и еще 100500 разных фич, до которых самому или по обрывочным статьям не дойти.
Может такой подход и зло, но я знаю про перечисленное тобой. Хотя не вкурил как следует.
Книгу может куплю попозже, сейчас вообще денег нет. Лучше делать хоть что-то, чем не делать ничего вовсе.
Если бы я всегда читал книги прежде чем что-то делать, то у меня не было бы ничего сейчас, вообще никакого опыта.
Для понимания действительно многие вещи трудны. Мне помогает только то, что читаю и одновременно набираю код, тестя прочитанное в разных вариациях. Хотя все равно не шибко хорошо все это откладывается в голове, месяцы практики нужны видимо.
PS
Ты где-то месяц назад писал, что ищешь лучший способ организации модульности. Если нашел, то не поделишься идеями, ссылочками на статейки?)
Там в комментариях много интересного. Вплотную ещё не занимался этим и не определился окончательно.
tulvit, бред, у всех свой подход к обучению. Кому то необходим большой теоретический базис, кому то достаточно практики из которой постепенно приходит понимание теории. Если уж на то пошло я вообще ни одной книжки по программированию не прочитал. Это не мешает мне знать эти «магические методы» которые к ООП на самом деле мало относятся :)
Тормоз, ты бы знал как меня сейчас ломает в svn вести строгий changelog и писать конфиги для phing…
Почитал, большинство комментов не понял=) Видимо курить буду в сторону изучения Drupal, ИМХО в нем модульность реализована на высоте, грех не перенять опыт.
PS
Все хотел спросить… Пару недель назад пришла идейка написать скриптик для блогов, just for fun, не для продажи. Смысл – ротатор трех последних сославшихся по данным ЯППБ. Внешний вид правда по идее будет сильно смахивать на Daos. Ты не против, если все-таки руки дойдут до написания?
Jeck, ну да, все индивидуально. Мне просто легче за раз прочитать про все возможности пхп-ного ООП, включая стандартные методы, и потом по мере необходимости их использовать, чем на практике сталкиваться с задачами и искать их решение не совсем понимая в какую сторону копать.
Джек, это мне ещё только предстоит :) А что, эйфория прошла? Ты ж вроде радовался, что наконец-то начал применять svn.
Tulvit, странно, что спрашиваешь — дело твоё. Похож, это ж не как две капли, надеюсь? :)
Тебя уже спрашивали в комментах один раз, ты был «сильно против» =)
Я не знаю, если честно, т. к. пока только идея. Просто смысл аналогичный – ротация двух-трех-пяти строчек, ну а касательно оформления, то оно может быть любое на выбор, от просто текстовых строчек (взятых из тайтла), до представления списком (как блогролл) или просто баннеры (генерирующиеся автоматически на основе анализа сославшегося блога/сайта).
Тормоз, радоваться это одно :D А лень совсем другое. Просто забываюсь и кучу кода пишу сразу вместо того что бы фиксировать каждое изменение. Ну и скрипты сборки… Cейчас у меня то что лежит в svn вообще работать не будет, надо сначала собрать тестовую или продакшен версию (это я магазин на jeck.ru допиливаю). В итоге процесс разработки идет так – правлю код, запускаю сборку тестового билда, проверяю на локальном сервере что все работает (вообще тут должно быть Unit тестирование но лень пока сильнее меня). Фиксирую изменения в svn и запускаю сборку уже рабочей версии. Радует только то что теперь можно забыть о правки конфигов на локалке и на сервере. Вот видишь тоже теперь блоги читаю и комментарии пишу.
Tulvit, про стандартные интерфейсы уже читал? ru.php.net/manual/en… интересней методов __get и __set будет.
Не помню сейчас точно тот случай и лень искать комментарий, но вроде контекст совсем другой был. В любом случае спрашивать такое как-то странно, на мой взгляд.
Не должно влиять моё мнение, главное — стремление. Если ты загорелся и тебе интересно делать это, так надо творить, какая разница чего там думает какой-то Тормоз?
Про интерфейсы пока не читал, но прочитаю обязательно.
Джек, а магазин только для себя делаешь или движок будешь продавать? Очень актуально сейчас для меня, тоже надо делать магазинчик.
Очень много есть идей, которые стопорит именно необходимость настроить и контролировать продажи. Тот самописный магазин, который есть, слишком привязан к конкретному продукту, он совсем не универсален.
В книге закладка на пятой главе, «Интерфейсы» =) Так что пока не читал, но вот-вот начну=)
Да, контекст был, если не изменяет память, сделать аналог Даоса (именно рекламный движок) с последующим распространением как опен сорс.
Этика и все такое=)
Тормоз, пока для себя, у меня привязки к конкретному продукту нет, но есть свои косяки с архитектурой. Кстати я там как раз с ООП переборщил год назад :) Но вообще посмотришь потом, если такое решение тебе подойдет – скину копию в личное пользование.
Спасибо. Просто поучиться интересно было бы, всё же у тебя опыта гораздо больше.
>Я вот раньше не знал о существовании __set(), __get(), __call(), __autoload(), о тонкостях использования конструктора и еще 100500 разных фич, до которых самому или по обрывочным статьям не дойти.
tulvit, перестань читать такие книги. это не имеет ничего общего с ООП.
Тормоз, а пришли класс, который написал – хочу сравнить с тем, что я писал через месяц-два после начала использования ООП в php ;)
aktuba, может я пример не совсем корректный привел. Но на данный момент теория мне сильно помогает, ну а практикой усиленно займусь через недельку, если потребуется. А так книга хорошая, про ООП как парадигму программирования в ней тоже много чего написано с примерами.
Я в блоге опубликую.
Коменты не читай сразу отвечай
@Тормоз, ты знаешь что такое рефакторинг? Пишешь значи что задумал в привычном функциональном стиле и когда перед глазами уже все реализации, когда точно знаешь и видишь что надо что ненадо, начинаешь их переводить в вид класса, так же с классом. Когда он уже написан начинаешь рефакторить, совершенствовать, если есть что, конечно. Рекомендую.
Я считаю, что лучше сразу проектировать как надо. А потом уже рефакторить.
Твой подход рефакторингом-то назвать сложно, это скорее какое-то функциональное прототипирование :)
Ну да ну да, но в широком смысле слова, ведь ООП это скорее подход чем парадигма или синтаксис, к тому же программы это алгоритмы + скруктуры данных
И не имея опыта ты хороший класс все равно не спроектируешь, поверь
Пфф. И что теперь, и не пробовать что ли? Пусть не супер, но кое-что, первый блин. С чего-то надо начинать.
Функций я предостаточно уже написал, хочу выходить на новый уровень. Кстати, класс почти совсем уже доделал, остался один метод — checkSignal, проверяющий сигнал от AvisoSMS о пришедшей SMSке.
Делать, но я бы на твоем месте их из функций взращивал а не промедлял месяцами :). К тому же все же не стоит все пытаться обернуть в объектную парадигму, проверку того же сигнала, я помню делал свою версию ДАОС (охохо) и у меня этот сигнал проверял скрипт, который вызывался аяксом со страницы оплаты, вот зачем такой фукнционал заключать в класс?
Другое дело если ты хочешь чиста класс такой написать для работы с Ависо, но я бы написал библиотеку :).
Именно класс для работы с AvisoSMS.
Сейчас тоже испытываю что-то подобное. Только связано с тем что изучаю рельсы и руби.
Ага, и здесь обгоняешь! Ах ты негодяй :) Тоже надо срочняк изучать уже «Рубин», очень уж мне нравится его философия и вообще. Правда, в «Рельсы» я скорей всего не буду врубаться, мне вообще не очень нравятся все эти каркасы.
Что-то мне кажется народ немного не в ту тему скатился. Добавлю свои пять копеек. Я пишу на java это язык фактически чистого ООП, хотя и на нем можно писать в процедурном стиле. Когда я через пару лет нашел исходники своих первых программ мне было реально стыдно, хорошо хоть я их для себя писал.
В общем исходя из своего опыта могу сказать: надо писать (ну ты в общем это уже делаешь), надо читать (как литературу, так и исходники хороших проектов). А еще очень неплохо поработать в команде с хорошим наставником (за пару месяцев можно будет узнать гораздо больше чем за пару лет самостоятельного изучения).
Все вышенаписанное является моим личным мнением основанным на собственном опыте.
я вот не понимаю
function blah($data)
class Foo { var $data function blah(
разве это ФАКТИЧЕСКИ ЧИСтОЕ ООП?
врубайся лучше в джангу :)
каркасы позволяют делать дело а не херней страдать
Миша, я не хочу врубаться в чужие каркасы. Почти все каркасы предназначены прежде всего для решения одной чужой задачи, а потом уже их приспосабливают для других задач. В результате такая чушь получается иногда!
То есть я для обучения, возможно, посмотрю реализацию тех же RoR, но пользоваться этим вряд ли буду.
Штудер, а мне не с кем в команде поработать, я один. Устраиваться куда-то на работу только ради опыта что-то не хочется :)
Дурак ты, Тормоз, но ничего. Все еще впереди и у тебя ;).
Да, у меня действительно ещё всё впереди, я очень молод. Но в будущем буду не просто дураком, а дураком убеждённым в своей правоте, как Миша :)
я наверное младше тебя :)
А какой язык? Я так понимаю, речь о ПХП?
Как изучать ООП:
1. Берём Руби или Питон.
2. Пишем код.
3. …
4. Профит!
Когда имеешь дело с нормальным ОО-языком, никаких проблем и ломок не возникает. Всерьёз писать на ПХП в ОО-стиле – всё равно что пользоваться нотепадом в качестве текстового редактора. Отсюда и проблемы.
На Ruby я с удовольствием перейду в будущем, когда буду заниматься исключительно своими проектами, то есть части которых никуда не продаю. Но если ты разрабатываешь коммерческие решения, никуда не денешься — привязан к PHP. Попробуй-ка напиши Daos на Ruby и продай хотя бы пару копий в Рунете. Получится?
Да это понятно… и печально…