Да нет, не пишется так в разумных учебниках. Это так “читается” у некоторых.
ООП – это подход к проектированию (методология, парадигма, дизайн... как кому больше нравиться). Смысл её в том, что декомпозиция задачи (системы) делается путём выделения её ключевых сущностей и соотношений между ними, а не действий, как это было ранее. Действия (события) добавляются следующим шагом как свойства этих сущностей. В этом смысл.
А вот “инкапсуляция, наследование, полиморфизм” – это технические возможности ООП ориентированных языков, которые позволяют более удобным образом эту методологию поддержать. В общем случае, вы можете использовать ООП дизайн, делая при этом реализацию на абсолютно любом языке (хоть на ассемблере). Вам просто придётся внутренне придерживаться некоторых соглашений по организации кода и это не будет выглядеть так наглядно как в ООП языках.
Давая определение ООП в упрощённом виде “... процессы, обменивающиеся сообщениями...” вы просто запутываете себя и других. Собственно, как и автор заметки, смешал в кучу код отдельно взятой функции с парадигмой ООП.
Всё как раз с точностью до наоборот. Если вы говорите компилятору 'как' то именно так он и делает. И свободы у него нет. А когда говорите 'что', то он сам решает как это сделать. Имея полную свободу. В этом и отличие императивных языков от декларативных. Декларативные вроде как нагляднее, но это пока человек способен чётко постулировать одной фразой что он хочет получить. Это, кстати, не так и просто. Хороший пример - язык SQL. Пока вы просто командуете что вам нужны поля такие-то и такие то, то всё гуд и в шоколаде. А вот как только вам нужно сделать сложную обработку, то декларативный запрос оказывается написать куда как сложнее. Почему и появился язык хранимых процедур. Уже императивный по своей сути.
Похоже, что наоборот, я статью не только что прочитал, но ещё и подумал о том, что там написано. В отличие от самого переводчика, который повёлся на зомбирующий стиль статьи.
Статья написана в стандартном рекламном навязчивом стиле, смысл которого состоит в том, что неважно хорошие (правильные) или плохие примеры приводятся. Главное в ней, что возле слова C#, мы постоянно видим эпитеты в духе: многословный, уродливый, кривой, ничего не делает... Что и отпечатывается в памяти.
Пример же там ничему особенному не учит, он написан в духе – руль в машине можно крутить членом, но это ещё более неудобно, чем крутить его ногами, посему советую крутить руками. Разумеется, что можно считать это ценным опытом обучения правильным навыкам вождения.
А уровень автора виден вот по этой фразе: ...применение принципов функционального программирования привело бы меня к использованию лишь статических методов, не используя instance-методы, везде где это только возможно, избегая всего, что изменяет состояние или даже потенциально способного его изменить. Я бы использовал лишь простые 'тупые' типы данных, отделяя алгоритмы от них...
Что по сути означает – уходим дескать от высокоуровневых абстракций и начинаем акцентироваться на колупании в потрохах. Это типа достойный уровень программирования в 21 веке. За травой, потерян лес. :-)
Во-первых, метод, по уму, должен был называться getDescription()
Во-вторых, какого хрена этот чудик ухитрился впереть сюда генерикс и делегаты, для прохождения коллекции и конкатенации строк, одному богу известно.
Такое чувство, что этот недоделок получил задание укатать Java и C# в пользу Haskell. Ничего умнее, кроме как выдернуть пару сложных конструкций, написать несвязанный бред, расчитанный на незнающих язык людей, он не придумал.
Видимо предполгается, что менеджер высокого звена остановится на фразе ...корявая глиняная хибара в сравнении с элегантным шпилем кода на...
Как говорится - фтопку!
Хаскель и Питон возможно отличные языки, но из статьи скорее следует обратное.
М-м-м... Я сам спокойно отношусь к идее коворкинга, но ваш пост, это то, что по жизни называется словом "доебаться". Человек, на мой взгляд, достаточно чётко и внятно отвечает на все вопросы. Что-то продумано больше, что-то меньше... Сразу не получается всё учесть. Судя по ответам автора, таки продумывалось реально. Сама идея сдачи в аренду офисных мест для работы в центре большого города очень даже неплоха. Даже если отбросить всякие там религиозные рассуждения о братстве фрилансеров.
Мож вам опять сегодня что-то там про веру пописАть? Дескать никому не верь, даже себе, только мне... :-)
Приятно выглядящий сайт. Хорошая идея. Но... Мне кажется автор несколько наивно верит в ВЕБ 2.0. Дескать, прибежит большая толпа незаурядных интересных и ярких личностей. Настреляет ему на сайт много классных и оригинальных идей про подарки. Затем набежит другая толпа и начнёт их яро и с энтузиазмом поглощать, попутно делясь своими. И вот снежный ком сорвался и резво покатился, подпрыгивая, попыливая и впитывая-налепливая на себя всё новые и новые незаурядные идеи... Ага... Три раза... :-)
Увы, но большинство людей не способны много сгенерировать. Или не хотят. Они зайдут и уйдут. Что бы этот ком катнуть, вам надо сесть (одному или с кем-то) и придумать сотню таких интересных идей. Выкатить их на сайт под видом разных пользователей и, по сути, симитировать эту первую волну. И вот тогда, возможно, начнут и другие прилепливаться... И тогда уже можно чуть и раскруткой заняться. :-)
Рискую показаться занудливым, но так и не могу понять в чём хоть какой-то смысл этих подкастов. Ну несколько приятных людей, с уже нехорошим русским языком и явно слышимым акцентом беседуют между собой. Хихикакют там, ну молодцы... Но вот я их лично не знаю. Да и, подозреваю, большая часть аудитории Хабра также не знает.
Порой кончено слышны какие-то слова имеющие отношения к Хабру. Само слово Хабр, ебанта какая-то... Вроде как интересных и ярких суждений они не кажут. Просто хорошие ребята. Ничего, разумеется, плохого, но такого рода болтовни я могу с избытком наслушаться нажав любую клавишу на магнитоле в машине и выбрав случайную УКВ радиостанцию. Или народ всё ещё, по инерции, прётся от радива в инете?
Извините, если кого задел, но раза три пытался послушать эти подкасты и терпения хватало только минуты на три-четыре. :-)
Строить отношения с заказчиком в ультимативных чёрно-белых тонах, это худшее, что можно придумать. В конце концов у него могут быть разные причины не хотеть этой ссылки. От политических до моральных. Абсолютно не понятно, с чего вы решили, что заказчик не имеет права этого требовать. А работу он прерывать возможно и не хочет. Что бы не проходить опять весь путь с другим исполнителем.
А скажем мы, что заказчику что-то не понравилось в работе с вами. На конфликт он не пошёл, но тактично намекнул. Ссылку убрать, сделать вывод и выстраивать отношения дальше с учётом этого факта.
Дело возможно не в том, что не любят разговоры про деньги, а в том, что люди, стремящиеся пополнить круг читателей, часто пишут банальности, исключительно чтобы отметиться и, как вы правильно сказали, пополнить круг своих читателей. :-)
3. Комментарии бывают тактические и стратегические.
Тактические, могут быть скомпенсированы грамотными названиями методов и переменных. Нужны в непростых местах (типа сдвига третьего бита влево на 17 позиций, какого хрена...).
Стратегические - желательны всегда. Для чего это всё нужно, какой алгоритм, подход, патерны запользованы. Хотя бы несколько строк на метод.
Безусловно в кураже азарт присутствует. Поэтому видимо и поставили ссылку с одного слова на другое. Оттенки у слов разные. Кураж носит некий налёт вызывающего поведения, кривляния... Азарт - это действительно пылкий энтузиазм и максимально воодушевленная работа.
Синонимом слова "кураж" скорее является слово "выпендрёж", а не "азарт". В данном же случае, на мой взгляд, слова "кураж" и "выпендрёж" - абсолютно не в тему.
Нда, с такой капчей, скоро могут появиться и Счастливые дни.
И что характерно, будут меньше выкладывать. А значит - ударит и по тем, кто платит за этот сервис.
Я старался. :-)
А насчёт критерия - если эти четыре картинки поставить в ряд и, как в тестах на IQ, попросить удалить лишнюю (отличную от других), то, полагаю, критерий сразу будет найден. :-)
ООП – это подход к проектированию (методология, парадигма, дизайн... как кому больше нравиться). Смысл её в том, что декомпозиция задачи (системы) делается путём выделения её ключевых сущностей и соотношений между ними, а не действий, как это было ранее. Действия (события) добавляются следующим шагом как свойства этих сущностей. В этом смысл.
А вот “инкапсуляция, наследование, полиморфизм” – это технические возможности ООП ориентированных языков, которые позволяют более удобным образом эту методологию поддержать. В общем случае, вы можете использовать ООП дизайн, делая при этом реализацию на абсолютно любом языке (хоть на ассемблере). Вам просто придётся внутренне придерживаться некоторых соглашений по организации кода и это не будет выглядеть так наглядно как в ООП языках.
Давая определение ООП в упрощённом виде “... процессы, обменивающиеся сообщениями...” вы просто запутываете себя и других. Собственно, как и автор заметки, смешал в кучу код отдельно взятой функции с парадигмой ООП.
Смотреть надо ширше. :-)
Статья написана в стандартном рекламном навязчивом стиле, смысл которого состоит в том, что неважно хорошие (правильные) или плохие примеры приводятся. Главное в ней, что возле слова C#, мы постоянно видим эпитеты в духе: многословный, уродливый, кривой, ничего не делает... Что и отпечатывается в памяти.
Пример же там ничему особенному не учит, он написан в духе – руль в машине можно крутить членом, но это ещё более неудобно, чем крутить его ногами, посему советую крутить руками. Разумеется, что можно считать это ценным опытом обучения правильным навыкам вождения.
А уровень автора виден вот по этой фразе: ...применение принципов функционального программирования привело бы меня к использованию лишь статических методов, не используя instance-методы, везде где это только возможно, избегая всего, что изменяет состояние или даже потенциально способного его изменить. Я бы использовал лишь простые 'тупые' типы данных, отделяя алгоритмы от них...
Что по сути означает – уходим дескать от высокоуровневых абстракций и начинаем акцентироваться на колупании в потрохах. Это типа достойный уровень программирования в 21 веке. За травой, потерян лес. :-)
Во-вторых, какого хрена этот чудик ухитрился впереть сюда генерикс и делегаты, для прохождения коллекции и конкатенации строк, одному богу известно.
Такое чувство, что этот недоделок получил задание укатать Java и C# в пользу Haskell. Ничего умнее, кроме как выдернуть пару сложных конструкций, написать несвязанный бред, расчитанный на незнающих язык людей, он не придумал.
Видимо предполгается, что менеджер высокого звена остановится на фразе ...корявая глиняная хибара в сравнении с элегантным шпилем кода на...
Как говорится - фтопку!
Хаскель и Питон возможно отличные языки, но из статьи скорее следует обратное.
Мож вам опять сегодня что-то там про веру пописАть? Дескать никому не верь, даже себе, только мне... :-)
Увы, но большинство людей не способны много сгенерировать. Или не хотят. Они зайдут и уйдут. Что бы этот ком катнуть, вам надо сесть (одному или с кем-то) и придумать сотню таких интересных идей. Выкатить их на сайт под видом разных пользователей и, по сути, симитировать эту первую волну. И вот тогда, возможно, начнут и другие прилепливаться... И тогда уже можно чуть и раскруткой заняться. :-)
Порой кончено слышны какие-то слова имеющие отношения к Хабру. Само слово Хабр, ебанта какая-то... Вроде как интересных и ярких суждений они не кажут. Просто хорошие ребята. Ничего, разумеется, плохого, но такого рода болтовни я могу с избытком наслушаться нажав любую клавишу на магнитоле в машине и выбрав случайную УКВ радиостанцию. Или народ всё ещё, по инерции, прётся от радива в инете?
Извините, если кого задел, но раза три пытался послушать эти подкасты и терпения хватало только минуты на три-четыре. :-)
Сдержался, да. С трудом. :-)
1. Притча, как и программный метод, должна быть недлинной. Строк 20-30. Ну ладно - для эстетов - 40-50 :-)
2. Имена действующих лиц, как и названия переменных, не заумными, а понятными нашему человеку. Ну скажем так:
ФРАСИМАХ = Салага.
КАЛЛИКЛ = ОпытныйПерец.
ГЛАВКОН = Выскочка.
ИСМЕНА = ПрикладнаяТётка.
СОКРАТ = МудрыйПряник.
ну и так далее...
3. Комментарии бывают тактические и стратегические.
Тактические, могут быть скомпенсированы грамотными названиями методов и переменных. Нужны в непростых местах (типа сдвига третьего бита влево на 17 позиций, какого хрена...).
Стратегические - желательны всегда. Для чего это всё нужно, какой алгоритм, подход, патерны запользованы. Хотя бы несколько строк на метод.
ну где-то во-так видимо....
И что характерно, будут меньше выкладывать. А значит - ударит и по тем, кто платит за этот сервис.
А насчёт критерия - если эти четыре картинки поставить в ряд и, как в тестах на IQ, попросить удалить лишнюю (отличную от других), то, полагаю, критерий сразу будет найден. :-)