Есть еще вариант — у вас есть толпа Иванов и надо за один месяц разработать 5 разных печей (угольных, электрических, газовых, солнечных..) — в зависимости от того что в том городе дешевле. И Иванов вам надо обучать уже сейчас, а печей еще не построили и не придумали.
Что вы делаете? А придумываете интерфейс. И одновременно даете команды:
— учить Иванов
— делать печи
И никаких спичек не будет! Будет автоподжиг — вы ведь так задачу поставили разработчикам печей. :)
Нет — меняется место принятия решения.
Если объект А посылал сообщение объекту Б — то не важно через адаптер он это делает или нет — он знает про Б.
Если есть посредник, то объект А посылает сообщение в пустоту — а кто словит, тому и будет. Посредник ловит и отсылает его в Б, а может и в В или куда-то еще в зависимости от изменившихся требований.
Статья не очень понравилась тем, что рассматривает статический случай.
А вместо этого людей реально интересует динамика (что всплыло при обсуждении).
Не так важно как мы красиво построили систему. Более важно что произойдет в случае необходимости ее поменять.
ООП слегка развязывает руки — при внесении модификаций в систему, разбитую на части общающиеся через четко прописанный интерфейс мы получаем возможность менять систему по очереди независимо.
Т.е сначала одну часть (не ломая работоспособности), затем другую.
Точно так же мы это можем делать при использовании библиотек (не важно ООП или библиотек функций).
Изменили, версия другая, но старый код работает (почти всегда ;)
Если ООП не использовать — то нет повода думать о разбиения системы на части, с четко прописанными интерфейсами (слабо изменяющимися во времени). Т.е никто не запрещает про это думать :) Но сам язык не намекает на это. ;)
Т.е плюс в том что не приходится затрагивать всю систему при внесении изменений.
Минус в том, что изменения очень часто не помещаются в придуманные нами интерфейсы и появляются извращения :)
Ну как с файлами — сначала были на локальном винте.
Потом появились права доступа — оп… вдруг оказалось что файл может существовать, а прочитать его низя (а старый софт то не знает! хотя интерфейс доступа к файлам остался тот же).
Потом появились сетевые хранилища — оп… вдруг оказалось что файл начал читаться и с какого-то момента перестал или чтение вдруг занимает минуты, а не секунды (чтение с сервера в другой стране). А старый софт то по прежнему не знает… интерфейс то тот же… Ни тебе прогрессбаров «скачивания» файла, ни оптимальной работы с данными (как начнет открывать для определения типа по содержимому — тут мы на минут 30 и зависнем).
Абстракция «файл» — хорошая как бы. И интерфейс доступа вроде как не менялся — открыл, прочитал, записал, закрыл. Но… протекающие абстрации никто не отменял. Если мы не меняем интерфейсы — все больше в этих абстракциях появляется дырок.
Зато экономим время программистов — им не приходится думать о «открыть локальный файл, открыть сетевой файл, открыть файл с DropBox»…
ps. да это все не относится именно к ООП, но и к нему тоже, только примеры будут другими.
Наверное значение в том, что ООП позволяет частично вместо документации использовать сам язык для того чтобы усилить соблюдение договоренностей об интерфейсах между людьми из разных под-проектов.
И чем больше людей в командах, тем важнее что сам язык запрещает доступ к каким-то данным, вместо того чтобы это делал человек словами «но ведь мы же договорились!».
Понятно что от всего не спасет, но облегчит.
Так кто спорит что одни концепции легче реализовывать, другие сложнее в рамках конкретного языка, но почти все возможно. Даже на С можно писать ОО программу. Только больше нужно будет решать на уровне договоренностей между программистами. Договор по наименованию функций, структур и модулей, например.
Сам по себе ОО язык не заставит человека проектировать в терминах объектов :)
Так что определитесь — Вы критикуете языки программирования или Вы не видите смысла именно в ОО подходе (не зависимо от языка — ОО или нет).
А как насчет андроид?
Вроде как там объекты выходят за рамки приложений — события транслируются во вполне определенные вызовы (вроде уснуть/проснуться) и все приложения это поддерживают. Совершенно не важно какое приложение — не надо знать что внутри, зато важно что любому можно послать событие «заснуть» или «убейся» :)
Конечно — это всего лишь интерфейс. Контракт. А явный он или нет… зависит от продуманности и зыка. Тот же «усни» может длиться минутами, что совсем не предполагалось неявно — выглядит для пользователя как подвисание :) А все потому что не прописано в контракте.
А пример с Solr (не вкурсе что это) не корректен. Потому что он может оказаться не самым лучшим эталоном ООП. Ведь использование ООП само по себе не делает программу лучше :)
А если задуматься в этих примерах кто главный? Главное действующее лицо, принимающее решение.
Собака, еда или «кушать»?
Не так важно — Собака.скушает(еду) или Еда.Употребится(собакой). Перестановка мест не принципиальна ;)
Главные в этом не они.
А тот кто
1) знает о существовании Собаки
2) знает о существовании Еды
3) знает о существовании действия «кушать».
И может это все вызвать в правильном сочетании :)
Т.е тот код из которого идет этот вызов. Допустим это будет объект Человек.
А вот что его заставляет этот вызов сделать? А тут тоже интересно.
Если мы сделаем
Человек.Покорми собаку() {Собака.кушай(Еду)} — то принципиально ничего не изменится.
Потому что инициатива придет извне. Т.е главным будет тот, кто вызвал это.
Другой вариант Человек.ВремяСейчас(Н часов) — мы сообщаем некое событие окружения, а не просим конкретное действие. А логика принятия решения (если Н = 8 или 20, то кормить) — спрятана внутри.
В этом случае главным остается человек.
Но… кажется это все не совсем ООП. :) Это скорее те модели, что требуются в реальной жизни, а чем они реализуются не так важно. Так называемая бизнес логика… Какой модуль/объект лишь исполнитель, а какой принимает решения.
А что до ООП — удобно при написании кода получать список действий, который применим к конкретному объекту. Ctrl+Tab. :) В отличии от функций… где это делается через «str....» «ltoi» и подобные договоренности.
Т.е структурирование namespace по большому счету. Модули этого не дают. И это то, что используется из ООП чаще всего :)
Автор допускает одну ошибку или неточность.
Закон действует на большие массы населения, а не на единицы.
Если закон запрещает убивать, это не значит, что единицы не найдут способа убить кого-то и остаться без наказания.
Так и здесь — то что вы знаете что такое «анонимайзер» не имеет никакого значения.
Потому что закон предназначен для 99% которые не знают.
Да и вообще аудитория хабра проходит мимо этого закона — в основном потому что вообще не интересуется теми сайтами, которые под него подпадают. Морально устойчива к подобным материалам (забьет на них). Но и потому что знает как обойти все это.
Защищают то слабых, а не сильных ;) В данном случае морально слабых, не наученных в школах как игнорировать подобную информацию (например, те у которых обработка исключений не прописана в детстве и приводит к core dumped — самоубийствам).
Ну все — википедию надо разделять на два домена — ru и rub.wikipedia.org — зарубленная часть статей :)
И rub — сразу заранее добавить во все черные списки.
А то жалко ж труд удалять вот так вот просто… К тому же лет через 20 может и закон отменят, а все уже поудаляли.
Ну и при переходе предупреждать «Минздрав заботится о вашем психическом здоровье» :)
А сколько игр порубят… Та же рассовая ненависть AngryBird-сов к свинюшкам…
А почему вы думаете что это должно быть именно в ВУЗ-е?
Для практического опыта — напильником там, например, уметь работать — есть техникумы.
Это как раз и есть самое то — изучение практического опыта.
Ну или современные аналоги — курсы различных компаний, продвигающих свои технологии и среды разработки.
А ВУЗ он ведь для другого совсем. А вы идете в ВУЗ, а потом не то что учеными не становитесь, но и даже преподавателями. Т.е полностью заваливаете то, ради чего на вас тратят время. А еще и жалуетесь :)
А на самом деле просто не тот тип образования выбрали.
И про курсовой все правильно — писать программу — это практика. Не этому учат — это бесполезно для обучения в ВУЗ-е! А вот чтобы грамотно обзор сделать — совсем другие навыки нужны.
А вот выводы — здравые. Искать надо там, где есть практические результаты деятельности.
А если нужных еще нет в свободном доступе, то можно и самостоятельно создать — конкурс или соревнования объявить по нужной вам тематике с игровой соревновательной составляющей и призами.
:)
А нечего бросать свое имущество где попало без присмотра ;)
Для этого есть гаражи и охраняемые стоянки.
Если вы положите кошелек на дороге и его там не окажется через какое-то время — это конечно не законно, но вы ничего с этим поделать не сможете.
Т.е собственник определяется косвенно — по факту нахождения, покупки, заявления о краже.
А по поводу частей — так кто-то же в итоге соберет это в единое целое?
Причем только одним способом. Если взять кусочки из разных фильмов, то целое не получится ;)
И вот тогда и наступает момент проверки. А как только удостоверились — производится поиск источника… и там уже все равно как он будет порезан и запаролен. Т.е скачать — можете, смотреть — нет :) Распространять не посмотрев? А смысл ;) Разве что для истории — ожидая когда копирайт закончится.
Очень бы пригодилась хардверная кнопка «гаситель яркости»,
которая бы ограничила максимальную яркость точки.
Переключил — и 100% никаких белых экранов смерти даже при зависании.
А вот позиционирование в пространстве недодуманное…
Как недавно на хабре было — наклоны головы ловит, а перемещения в стороны — пока нет.
А есть ли в вашей системе читалка QR кодов?
Приклеил на предмет или бейдж (или на лоб :) — любой подходит и сразу в очках видит информацию.
Только нужна не ссылка на сайт, как это часто делают, а специальный сайтик с информацией
в формате вывода для очков с меню и типизированными полями для быстрой фильтрации нужных данных.
А не делали ли вы навигаторы для помещений?
Для примера — на ресепшене подгружается карта, которая стрелочками ведет до лифта и на
этаже до нужной комнаты.
А можно ли у этих очков перенести вес на что-то другое?
Резинку на дужку прицепить, скажем. Или обруч через голову?
Ну примерно как фонарики у спелеологов.
А как быть с товарами, которые имеют и физическую, и интеллектуальную составляющую?
А это практически все.
С одной стороны — это пылесосы, машины, строительные блоки (и даже в них есть патент на раствор).
С другой — dvd, бумажные книги и т.п
Есть и компьютеры, телефоны, синтезаторы.
Т.е что из этого переходит в Public Domain, как и когда? Как подсчитать прибыль от интеллектуальной и физической составляющей? Перестает ли выпускать фирма товар как только его часть переходит в Public?
Выгоднее ли будет выпускать новое стройство с программой, «прошедшей ремастеринг», т.е не в Public-е.
Что именно переходит в Public — бинарники программы или исходники? Формула лекарства, или программы, по которым проводились исследования и эксперименты? Черновики книги или результат после правок редактора? Все отснятые эпизоды фильма в исходниках или результирующий фильм только?
По поводу назначения прибыли — можно проще. Компания сама указывает сколько хочет прибыли :) А ты волен покупать продукт или нет.
Т.е всеми силами вставлять палки в колеса прогресса.
Если мы научили человека на лошади ездить, то все бензиновые повозки должны иметь седло и управляться поводьями :)))
как-то так.
Есть еще вариант — у вас есть толпа Иванов и надо за один месяц разработать 5 разных печей (угольных, электрических, газовых, солнечных..) — в зависимости от того что в том городе дешевле. И Иванов вам надо обучать уже сейчас, а печей еще не построили и не придумали.
Что вы делаете? А придумываете интерфейс. И одновременно даете команды:
— учить Иванов
— делать печи
И никаких спичек не будет! Будет автоподжиг — вы ведь так задачу поставили разработчикам печей. :)
Если объект А посылал сообщение объекту Б — то не важно через адаптер он это делает или нет — он знает про Б.
Если есть посредник, то объект А посылает сообщение в пустоту — а кто словит, тому и будет. Посредник ловит и отсылает его в Б, а может и в В или куда-то еще в зависимости от изменившихся требований.
Так вроде?
А вместо этого людей реально интересует динамика (что всплыло при обсуждении).
Не так важно как мы красиво построили систему. Более важно что произойдет в случае необходимости ее поменять.
ООП слегка развязывает руки — при внесении модификаций в систему, разбитую на части общающиеся через четко прописанный интерфейс мы получаем возможность менять систему по очереди независимо.
Т.е сначала одну часть (не ломая работоспособности), затем другую.
Точно так же мы это можем делать при использовании библиотек (не важно ООП или библиотек функций).
Изменили, версия другая, но старый код работает (почти всегда ;)
Если ООП не использовать — то нет повода думать о разбиения системы на части, с четко прописанными интерфейсами (слабо изменяющимися во времени). Т.е никто не запрещает про это думать :) Но сам язык не намекает на это. ;)
Т.е плюс в том что не приходится затрагивать всю систему при внесении изменений.
Минус в том, что изменения очень часто не помещаются в придуманные нами интерфейсы и появляются извращения :)
Ну как с файлами — сначала были на локальном винте.
Потом появились права доступа — оп… вдруг оказалось что файл может существовать, а прочитать его низя (а старый софт то не знает! хотя интерфейс доступа к файлам остался тот же).
Потом появились сетевые хранилища — оп… вдруг оказалось что файл начал читаться и с какого-то момента перестал или чтение вдруг занимает минуты, а не секунды (чтение с сервера в другой стране). А старый софт то по прежнему не знает… интерфейс то тот же… Ни тебе прогрессбаров «скачивания» файла, ни оптимальной работы с данными (как начнет открывать для определения типа по содержимому — тут мы на минут 30 и зависнем).
Абстракция «файл» — хорошая как бы. И интерфейс доступа вроде как не менялся — открыл, прочитал, записал, закрыл. Но… протекающие абстрации никто не отменял. Если мы не меняем интерфейсы — все больше в этих абстракциях появляется дырок.
Зато экономим время программистов — им не приходится думать о «открыть локальный файл, открыть сетевой файл, открыть файл с DropBox»…
ps. да это все не относится именно к ООП, но и к нему тоже, только примеры будут другими.
И чем больше людей в командах, тем важнее что сам язык запрещает доступ к каким-то данным, вместо того чтобы это делал человек словами «но ведь мы же договорились!».
Понятно что от всего не спасет, но облегчит.
Все эти толпы окошек, кнопочек, контролов (слегка разные, но с одними интерфейсами).
А документооборот тогда был в виде отдельных файликов и никакой особой сложности не представлял.
:)
А можно писать и не ОО программы.
Но сам по себе язык не ориентирован именно на ОО подход.
Некоторые используют дополнительные инструменты, которые парсят исходники на С и выдают ошибки при нарушении ОО стиля.
Сам по себе ОО язык не заставит человека проектировать в терминах объектов :)
Так что определитесь — Вы критикуете языки программирования или Вы не видите смысла именно в ОО подходе (не зависимо от языка — ОО или нет).
Вроде как там объекты выходят за рамки приложений — события транслируются во вполне определенные вызовы (вроде уснуть/проснуться) и все приложения это поддерживают. Совершенно не важно какое приложение — не надо знать что внутри, зато важно что любому можно послать событие «заснуть» или «убейся» :)
Конечно — это всего лишь интерфейс. Контракт. А явный он или нет… зависит от продуманности и зыка. Тот же «усни» может длиться минутами, что совсем не предполагалось неявно — выглядит для пользователя как подвисание :) А все потому что не прописано в контракте.
А пример с Solr (не вкурсе что это) не корректен. Потому что он может оказаться не самым лучшим эталоном ООП. Ведь использование ООП само по себе не делает программу лучше :)
Статья на эту тему — www.joelonsoftware.com/articles/LeakyAbstractions.html
Наглядно.
А если задуматься в этих примерах кто главный? Главное действующее лицо, принимающее решение.
Собака, еда или «кушать»?
Не так важно — Собака.скушает(еду) или Еда.Употребится(собакой). Перестановка мест не принципиальна ;)
Главные в этом не они.
А тот кто
1) знает о существовании Собаки
2) знает о существовании Еды
3) знает о существовании действия «кушать».
И может это все вызвать в правильном сочетании :)
Т.е тот код из которого идет этот вызов. Допустим это будет объект Человек.
А вот что его заставляет этот вызов сделать? А тут тоже интересно.
Если мы сделаем
Человек.Покорми собаку() {Собака.кушай(Еду)} — то принципиально ничего не изменится.
Потому что инициатива придет извне. Т.е главным будет тот, кто вызвал это.
Другой вариант Человек.ВремяСейчас(Н часов) — мы сообщаем некое событие окружения, а не просим конкретное действие. А логика принятия решения (если Н = 8 или 20, то кормить) — спрятана внутри.
В этом случае главным остается человек.
Но… кажется это все не совсем ООП. :) Это скорее те модели, что требуются в реальной жизни, а чем они реализуются не так важно. Так называемая бизнес логика… Какой модуль/объект лишь исполнитель, а какой принимает решения.
А что до ООП — удобно при написании кода получать список действий, который применим к конкретному объекту. Ctrl+Tab. :) В отличии от функций… где это делается через «str....» «ltoi» и подобные договоренности.
Т.е структурирование namespace по большому счету. Модули этого не дают. И это то, что используется из ООП чаще всего :)
Сокращает время работы программистов, но добавляет аппаратные затраты.
Закон действует на большие массы населения, а не на единицы.
Если закон запрещает убивать, это не значит, что единицы не найдут способа убить кого-то и остаться без наказания.
Так и здесь — то что вы знаете что такое «анонимайзер» не имеет никакого значения.
Потому что закон предназначен для 99% которые не знают.
Да и вообще аудитория хабра проходит мимо этого закона — в основном потому что вообще не интересуется теми сайтами, которые под него подпадают. Морально устойчива к подобным материалам (забьет на них). Но и потому что знает как обойти все это.
Защищают то слабых, а не сильных ;) В данном случае морально слабых, не наученных в школах как игнорировать подобную информацию (например, те у которых обработка исключений не прописана в детстве и приводит к core dumped — самоубийствам).
И rub — сразу заранее добавить во все черные списки.
А то жалко ж труд удалять вот так вот просто… К тому же лет через 20 может и закон отменят, а все уже поудаляли.
Ну и при переходе предупреждать «Минздрав заботится о вашем психическом здоровье» :)
А сколько игр порубят… Та же рассовая ненависть AngryBird-сов к свинюшкам…
Для практического опыта — напильником там, например, уметь работать — есть техникумы.
Это как раз и есть самое то — изучение практического опыта.
Ну или современные аналоги — курсы различных компаний, продвигающих свои технологии и среды разработки.
А ВУЗ он ведь для другого совсем. А вы идете в ВУЗ, а потом не то что учеными не становитесь, но и даже преподавателями. Т.е полностью заваливаете то, ради чего на вас тратят время. А еще и жалуетесь :)
А на самом деле просто не тот тип образования выбрали.
И про курсовой все правильно — писать программу — это практика. Не этому учат — это бесполезно для обучения в ВУЗ-е! А вот чтобы грамотно обзор сделать — совсем другие навыки нужны.
А вот выводы — здравые. Искать надо там, где есть практические результаты деятельности.
А если нужных еще нет в свободном доступе, то можно и самостоятельно создать — конкурс или соревнования объявить по нужной вам тематике с игровой соревновательной составляющей и призами.
:)
:)
Для этого есть гаражи и охраняемые стоянки.
Если вы положите кошелек на дороге и его там не окажется через какое-то время — это конечно не законно, но вы ничего с этим поделать не сможете.
Т.е собственник определяется косвенно — по факту нахождения, покупки, заявления о краже.
А по поводу частей — так кто-то же в итоге соберет это в единое целое?
Причем только одним способом. Если взять кусочки из разных фильмов, то целое не получится ;)
И вот тогда и наступает момент проверки. А как только удостоверились — производится поиск источника… и там уже все равно как он будет порезан и запаролен. Т.е скачать — можете, смотреть — нет :) Распространять не посмотрев? А смысл ;) Разве что для истории — ожидая когда копирайт закончится.
Компания не обязана продавать товар всем желающим.
которая бы ограничила максимальную яркость точки.
Переключил — и 100% никаких белых экранов смерти даже при зависании.
А вот позиционирование в пространстве недодуманное…
Как недавно на хабре было — наклоны головы ловит, а перемещения в стороны — пока нет.
А есть ли в вашей системе читалка QR кодов?
Приклеил на предмет или бейдж (или на лоб :) — любой подходит и сразу в очках видит информацию.
Только нужна не ссылка на сайт, как это часто делают, а специальный сайтик с информацией
в формате вывода для очков с меню и типизированными полями для быстрой фильтрации нужных данных.
А не делали ли вы навигаторы для помещений?
Для примера — на ресепшене подгружается карта, которая стрелочками ведет до лифта и на
этаже до нужной комнаты.
А можно ли у этих очков перенести вес на что-то другое?
Резинку на дужку прицепить, скажем. Или обруч через голову?
Ну примерно как фонарики у спелеологов.
там же не те лопасти.
А это практически все.
С одной стороны — это пылесосы, машины, строительные блоки (и даже в них есть патент на раствор).
С другой — dvd, бумажные книги и т.п
Есть и компьютеры, телефоны, синтезаторы.
Т.е что из этого переходит в Public Domain, как и когда? Как подсчитать прибыль от интеллектуальной и физической составляющей? Перестает ли выпускать фирма товар как только его часть переходит в Public?
Выгоднее ли будет выпускать новое стройство с программой, «прошедшей ремастеринг», т.е не в Public-е.
Что именно переходит в Public — бинарники программы или исходники? Формула лекарства, или программы, по которым проводились исследования и эксперименты? Черновики книги или результат после правок редактора? Все отснятые эпизоды фильма в исходниках или результирующий фильм только?
По поводу назначения прибыли — можно проще. Компания сама указывает сколько хочет прибыли :) А ты волен покупать продукт или нет.