Вы просто не поняли за что Вас минусуют. Некрасиво посылать людей по принципу «не нравится — вали отсюда». Есть более конструктивные направления диалога, вроде предложенной платной кнопки «скачать».
Он никому и ничем не обязан
Своим существованием он таки обязан своим пользователям. Так же как любой публичный сервис. Пользователи создают контент, пользователи рекламируют сервис, из жизни пользователей жизнь этого сервиса и состоит.
Пользователи — хотят для себя больше удобств и просят для себя изменений. Если ресурс создан не для удовлетворения потребностей пользователей, то для чего же тогда он создан?
Разумеется, одна единественная второстепенная фича не станет решающим фактором в жизни сервиса — этих фич у него много. Однако социальный сервис не может просто так заявить «валите отсюда» и остаться безнаказанным — уже само подобное отношение может спровоцировать негативную реакцию со стороны тех, кому вопрос изначально был безразличен.
Во всей этой истории меня смущает только одно: все эти сервисы лишают YouTube прибыли (чем он и не блистал никогда). Возможно стоит вдогонку петиции устроить мозговой штурм над хорошей бизнесмоделью для видеохостингов? В конце концов — утомляет, когда загрузки видео в хорошем качестве приходится ждать, а время, как выше уже упомянули — оно тоже деньги. Предложить им высокое качество раздавать по модели абонплаты? Или абонплату за приоритетное обслуживание? Глядишь на пару дополнительных датацентров насобирают и к качалкам будут менее агрессивны.
В общем, судя по описанию и обсуждению в этой теме, хаскель — «не_ооп_язык с ооп». В принципе — хоть груздем назови — какая разница? О чём вообще весь разговор? О том как назвать то, что по религиозным соображениям нельзя назвать ООП?
Каждый язык даёт некоторое множество инструментов, пользуясь которыми можно решить некоторое соответствующее множество задач. Как обозвать этот набор инструментов — дело десятое.
Есть четыре вышеперечисленных качества? Можем писать в стиле ООП. Каким бы при этом «не ООП» язык ни называли.
Имеют и что?
Если у стола есть ножки и у гриба есть ножка, то гриб — он как бы уже не настоящий, поскольку ножки есть не только у грибов?
Отличие ООП от не ООП в том и заключается, что все необходимые свойства ООП есть, а не какая-то часть из них.
Не должно быть никаких данных открытых для общего доступа.
private name
public getName(): return this.name
отнюдь не означает, что это прямой доступ. Как раз наоборот, доступ только через метод, реализация которого на практике может изменяться и пложение совершенно не волнует, как метод реализован.
Понятно. Да, это плохая задача для ООП при решении через наследование. Immutable вариант будет иметь свои недостатки — эллипс у которого сравнялись оси — не будет знать, что он должен стать кругом. Эта задача должна решаться иначе. Но для полноценного решения понадобится целая инфраструктура (если мы хотим находить класс, оптимальный для реализации нового состояния). Мне с такой дилеммой на практике сталкиваться пока не приходилось. Куда большая проблема то, что вещи куда менее родственны, чем они кажутся на первый взгляд :-)
А какая разница какое поле. Тот же wight, если он объявлен в интерфейсе, а затем из этого интерфейса будет удалён, то чем больше компонентов реализовало этот интерфейс, тем масштабнее «разрушения».
Пример будет справедлив для любого поля в такой ситуации.
То есть, если бы поле убрали в виду его ненужности никому — так никто и не заметил бы.
Точно так же в нашей жизни, если бы кто-то запретил хранить имена в виду права на анонимность — это привело бы к коллапсу. Если бы запретили рассказывать свои сны — мало кто это заметил бы. Чем больше реализаций расчитывающих на интерфейс, тем страшнее последствия от изменения интерфейса.
Но это так же относилось бы и к функциональному программированию, если бы кто-то взял и удалил одну из функций, которую использует значительная часть кода — код бы просто оказался нерабочим. Здесь то же самое, только в пространстве конкретного интерфейса.
Получается, что для одних частных случаев можно использовать наследование, но для других частных случаев нельзя — придется использовать различные обертки.
Именно так. Наличие в руках молотка, не означает, что кругом только гвозди, хотя подобные мысли могут и мелькать ))
Первый пример — баг архитектуры приложения. Объект либо обязан содержать имя, либо интерфейс должен содержать упоминание о возможности исключения.
В целом, с именами всё не так просто, чтобы использовать их вообще в качестве поля — тут на эту тему как раз недавно была хорошая заметка
Про мозгосносящий конфликт наследования эллипса-круга я уже молчу
Можно чуть подробней о чём идёт речь? Но я наверно предположу, что речь идёт про то, что некий класс Эллипс наследует класс Круг? Это бессмысленное наследование, поскольку круг является частным случаем эллипса, а не наоборот. Но наоборот часто пытаются сделать не понимая этой логики, а просто следуя желанию сэкономить поле в структуре данных. Индуктивное правило «наследники усложняются по сравнению с предками» — ложно.
Я не понимаю. Может это был самый неудачный пример от визави, но в ТЗ сказано «убрать любой ценой», при чём тут ООП? Я полагаю, что класс Person проектировался не для того, чтобы в нём исчезло поле, являющееся одним из его смыслов, а также станут неработоспособны все компоненты, которые писались с расчётом на то, что этот класс будет предоставлять такой интерфейс, а они даже близко не должны быть хоть сколько-то «родственными» классу Person или даже друг другу. Это пример вообще не про ООП — в любой реализации, из которой вынимают фундамент, будет подобный хаос, независимо от парадигмы.
А по поводу того, что ООП плох для повторого использования кода — нужно таки реально сравнивать. В моих проектах оверхеда на тему повторного использования не возникает, копипастой заниматься не приходится, а тем кто пытается занимается — на первый раз объясняю, чем это плохо, на второй — бью по рукам, на третий — самых тупых — исключаю из команды. :-)
Чтобы читать не так скучно было. Но если вы настаиваете, следующую статью я напишу в строгом консервативном стиле
Да нет, зачем? Не в образности дело. Образы должны присутствовать и помогать воспринимать материал. Но в данном случае вызывает протест несправедливый подтекст.
Хорошо, критиковать все умеем, давайте тогда больше позитива и конструктивизма :-)
Раз уж речь зашла о моделировании реального мира через ООП — я думаю это тоже такое образное выражение, которое используется для объяснения сути новичкам :-)
Точно так же как про абстракцию можно сказать, что она универсальна для всех парадикм, также и все парадигмы одинаково пригодны для моделирования реального мира — тут как ни крути, большая часть вычислений и нужна только для этого.
Но что значит моделирование реального мира? Имитация поведения выделяемых в интересующем процессе действующих лиц, их ролей, возможностей, отношений — всё это очень хорошо ложится на концепцию ООП. При этом не так важно, какой конкретно ООП реализован в языке, есть ли в нём возможность множественного наследования, есть ли миксины и т.д. Модель может быть построена разными способами. Главными являются инструменты контроля над взаимодействием больших и компонуемых систем и разделения ответственности между командами и отдельными разработчиками (которых, команд и разработчиков, может быть действительно много).
например, до сих пор нет чёткого определения того, что такое ООП
Вот не знаю, как по мне два слова «наследование» и «полиморфизм» являются более чем исчерпывающим определением, что такое ООП. А «инкапсуляция» — автоматически задаёт планку качества кода, в связи с чем я бы вообще избавился от модификатора доступа public.
И добавим ещё сюда обвешивание триггерами и событиями — которое можно осуществить прозрачно, и уже только за одно это (ну и за вышеперечисленное — тоже) я готов писать все геттеры и сеттеры вручную без всякого синтаксического сахара и IDE.
Вчера — просто return field, сегодня — делегирование вызова, завтра — ленивое создание структуры. И при этом интерфейс цел и никого снаружи не волнует, как класс устроен внутри.
Он никому и ничем не обязан
Своим существованием он таки обязан своим пользователям. Так же как любой публичный сервис. Пользователи создают контент, пользователи рекламируют сервис, из жизни пользователей жизнь этого сервиса и состоит.
Пользователи — хотят для себя больше удобств и просят для себя изменений. Если ресурс создан не для удовлетворения потребностей пользователей, то для чего же тогда он создан?
Разумеется, одна единественная второстепенная фича не станет решающим фактором в жизни сервиса — этих фич у него много. Однако социальный сервис не может просто так заявить «валите отсюда» и остаться безнаказанным — уже само подобное отношение может спровоцировать негативную реакцию со стороны тех, кому вопрос изначально был безразличен.
Нда, суровая самокритика, однако.
Хм. Возможно речь идёт не про ООП, а про конкретные языки? Это вполне стоит целой серии статей.
Каждый язык даёт некоторое множество инструментов, пользуясь которыми можно решить некоторое соответствующее множество задач. Как обозвать этот набор инструментов — дело десятое.
Есть четыре вышеперечисленных качества? Можем писать в стиле ООП. Каким бы при этом «не ООП» язык ни называли.
Да, я уже после такого заявления мимо пройти не смогу… )))
Если у стола есть ножки и у гриба есть ножка, то гриб — он как бы уже не настоящий, поскольку ножки есть не только у грибов?
Отличие ООП от не ООП в том и заключается, что все необходимые свойства ООП есть, а не какая-то часть из них.
Метод — часть интерфейса. Смена важного интерфейса = «слезай, приехали».
При удалении поля или создании пяти полей вместо одного, метод остаётся, меняется его устройство.
При удалении метода… ну тут уже выше написали, с кем и что делают благодарные программеры из зависимых проектов.
Вообще-то с этого тред начался: «обещали пряник, а заставили работать» — «вместо общения с девушкой приходится программировать».
В JavaScript его нету.
А? Прототипы канули в Лету?
Полиморфизм? Опять же, в JavaScript полиморфизм сводится к указателям на анонимные функции.
Указатели в JavaScript?
Ну да и указатели, если бы они — чем не угодили? Они как-то не так работают, полиморфизм чем-то отличается?
Динамическая типизации к полиморфизму и наследованию — ортогональна.
private name
public getName(): return this.name
отнюдь не означает, что это прямой доступ. Как раз наоборот, доступ только через метод, реализация которого на практике может изменяться и пложение совершенно не волнует, как метод реализован.
Пример будет справедлив для любого поля в такой ситуации.
То есть, если бы поле убрали в виду его ненужности никому — так никто и не заметил бы.
Точно так же в нашей жизни, если бы кто-то запретил хранить имена в виду права на анонимность — это привело бы к коллапсу. Если бы запретили рассказывать свои сны — мало кто это заметил бы. Чем больше реализаций расчитывающих на интерфейс, тем страшнее последствия от изменения интерфейса.
Но это так же относилось бы и к функциональному программированию, если бы кто-то взял и удалил одну из функций, которую использует значительная часть кода — код бы просто оказался нерабочим. Здесь то же самое, только в пространстве конкретного интерфейса.
Именно так. Наличие в руках молотка, не означает, что кругом только гвозди, хотя подобные мысли могут и мелькать ))
В целом, с именами всё не так просто, чтобы использовать их вообще в качестве поля — тут на эту тему как раз недавно была хорошая заметка
Про мозгосносящий конфликт наследования эллипса-круга я уже молчу
Можно чуть подробней о чём идёт речь? Но я наверно предположу, что речь идёт про то, что некий класс Эллипс наследует класс Круг? Это бессмысленное наследование, поскольку круг является частным случаем эллипса, а не наоборот. Но наоборот часто пытаются сделать не понимая этой логики, а просто следуя желанию сэкономить поле в структуре данных. Индуктивное правило «наследники усложняются по сравнению с предками» — ложно.
А по поводу того, что ООП плох для повторого использования кода — нужно таки реально сравнивать. В моих проектах оверхеда на тему повторного использования не возникает, копипастой заниматься не приходится, а тем кто пытается занимается — на первый раз объясняю, чем это плохо, на второй — бью по рукам, на третий — самых тупых — исключаю из команды. :-)
Да нет, зачем? Не в образности дело. Образы должны присутствовать и помогать воспринимать материал. Но в данном случае вызывает протест несправедливый подтекст.
Хорошо, критиковать все умеем, давайте тогда больше позитива и конструктивизма :-)
Раз уж речь зашла о моделировании реального мира через ООП — я думаю это тоже такое образное выражение, которое используется для объяснения сути новичкам :-)
Точно так же как про абстракцию можно сказать, что она универсальна для всех парадикм, также и все парадигмы одинаково пригодны для моделирования реального мира — тут как ни крути, большая часть вычислений и нужна только для этого.
Но что значит моделирование реального мира? Имитация поведения выделяемых в интересующем процессе действующих лиц, их ролей, возможностей, отношений — всё это очень хорошо ложится на концепцию ООП. При этом не так важно, какой конкретно ООП реализован в языке, есть ли в нём возможность множественного наследования, есть ли миксины и т.д. Модель может быть построена разными способами. Главными являются инструменты контроля над взаимодействием больших и компонуемых систем и разделения ответственности между командами и отдельными разработчиками (которых, команд и разработчиков, может быть действительно много).
например, до сих пор нет чёткого определения того, что такое ООП
Вот не знаю, как по мне два слова «наследование» и «полиморфизм» являются более чем исчерпывающим определением, что такое ООП. А «инкапсуляция» — автоматически задаёт планку качества кода, в связи с чем я бы вообще избавился от модификатора доступа public.