Самый правильный вариант — это запретить крупным торговым сетям заниматься производством товара. И вознаграждать их сотрудника, который раскроет нарушение этого правила, премией в 50% от общего штрафа.
Так это же идея для стартапа: бесплатный сайт + бесплатный хостинг + бесплатное доменное имя, а взамен — актуальный почтовый ящик, на который можно отправлять хорошо таргетированную рекламу.
"… для начала клиенту необходимо задавать простой вопрос «Какой трафик и из каких систем у нас пойдёт?», а уже потом придумывать как его ловить"
Не-а. Это все должны знать вы еще до того, как к вам кто-то обратился. Клиент просто говорит про свои услуги и всё. Но идея, что верстальщики — вторые на этом конвейере после рекламщиков — правильная.
Ну вот вы и назвали главную причину копроэкономики — скорость вывода продукта на рынок. А качество уже будет не так важно, если продукт обладает «собирающей» силой: то есть чем больше пользователей пришло вчера -> тем больше их придет завтра (например как у соц. сетей).
Есть, конечно, и обычные производственные компании, где казалось бы этот принцип не должен работать, но там видно другие основные причины вмешиваются (дешевизна вместо качества и т.д.).
Ну а Хабр уже немного тоже монополист в своем секторе, поэтому тоже подпадает под влияние непривычных для нас (немонополистов) факторов.
Судя по минусу, тема интересная )) Я думаю, что копроэкономика — следствие излишнего монополизма крупных корпораций в современном мире. Потому что они, как известно, больше работают не на своих акционеров, а в основном на свой менеджмент.
«я видел кучу кода с типами (и его разработчики очень этим гордились), где ошибки были чуть не в каждой первой строчке» — это были ошибки согласования типов?
(я извиняюсь, что встряю, но вы прямо подставляетесь))
«Обычные методы в ООП по определению не чистые» — под «обычностью» я подразумевал то, откуда мы их берем. Но теперь мы должны сделать их стать чистыми (иначе зачем это все затевать).
Можно сделать таким образом: у «хранящего» объекта (а других и не должно быть) есть список переменных, доступных для чтения снаружи. Какие это переменные — определяется самим этим объектом. И пожалуйста, любой другой объект может взять эти данные и сделать что-то с ними для себя.
Также у объекта есть список переменных, доступных для записи извне — так другой объект может передавать в наш необходимую информацию.
Объект, получив на свой вход какие-то новые данные, определяет, что с ними делать дальше и вызывает необходимые для этого внешние функции. Конечный результат может быть возвращен в наш объект или передан на вход другом объекту.
Можно на этом строить реактивное программирование, указав что в объекте его «входное поле» зависит от «выходного поля» другого объекта.
То есть здесь получается сообщения в духе обычных геттеров и сеттеров, но они не нарушают инкапсуляцию (в широком смысле) любого объекта.
А внешние чистые функции — это обычные методы объекта в ООП, только чистые и вынесенные за пределы объекта. Плюсы: они чистые, их можно переиспользовать (вместо наследования), можно делать их композицию, они могут быть полиморфными (тогда как внутри объекта всё может быть строго статически типизировано).
Так объект высушивается до хранителя стейта, защищенного внутренним «поведением / характером», которое выглядит как переключатель «if-else-if-else...», зависящий от входных данных и внутренней логики.
А с какого перепугу Теле2 имеет право поднимать тарифы? Человек ведь приобрел пакет по фиксированной цене. Тогда пусть номера своих пользователей обнуляют, раз старый пакет для компании стал невыгоден.
Я не уверен, что полностью согласен с Аланом Кейем (и про динамическую типизацию, и про то что «все есть объект»), но вот что yegor256 правильно делает — так это пытается облегчить отдельный объект, оставляя за ним только одну какую-то функцию. В результате у него получается цепочка из декораторов (ну вот просто Java такая), которая и есть по сути композицией функций из ФП.
И последний оставшийся шаг до правильного ООП — это разделить объекты на делающие и хранящие. Первые — это просто чистые функции ФП, вторые — это те самые мутабельные объекты, обменивающиеся сообщениями в духе Smalltalk.
В итоге имеем два типа акторов — объекты-состояния и функции.
«Изменяемые Объекты – это глобальные переменные» — в этом и есть вся проблема современного ООП, где объект — это то, над чем можно производить действия (get/set, передавать его по ссылке и т.д.), поэтому их сейчас стремятся делать иммутабельными. Но «правильный» объект — это, то что должно само производить действия над другими участками кода в программе (а точнее переключать направления вычислений, подобно стрелочнику на ж/д путях) — а это уже ближе к реактивному программированию. Что-то пытался в этом смысле сделать Егор Бугаенко, но к сожалению кмк он чрезмерно обожествлял ООП.
Не-а. Это все должны знать вы еще до того, как к вам кто-то обратился. Клиент просто говорит про свои услуги и всё. Но идея, что верстальщики — вторые на этом конвейере после рекламщиков — правильная.
Есть, конечно, и обычные производственные компании, где казалось бы этот принцип не должен работать, но там видно другие основные причины вмешиваются (дешевизна вместо качества и т.д.).
Ну а Хабр уже немного тоже монополист в своем секторе, поэтому тоже подпадает под влияние непривычных для нас (немонополистов) факторов.
(я извиняюсь, что встряю, но вы прямо подставляетесь))
Также у объекта есть список переменных, доступных для записи извне — так другой объект может передавать в наш необходимую информацию.
Объект, получив на свой вход какие-то новые данные, определяет, что с ними делать дальше и вызывает необходимые для этого внешние функции. Конечный результат может быть возвращен в наш объект или передан на вход другом объекту.
Можно на этом строить реактивное программирование, указав что в объекте его «входное поле» зависит от «выходного поля» другого объекта.
То есть здесь получается сообщения в духе обычных геттеров и сеттеров, но они не нарушают инкапсуляцию (в широком смысле) любого объекта.
А внешние чистые функции — это обычные методы объекта в ООП, только чистые и вынесенные за пределы объекта. Плюсы: они чистые, их можно переиспользовать (вместо наследования), можно делать их композицию, они могут быть полиморфными (тогда как внутри объекта всё может быть строго статически типизировано).
Так объект высушивается до хранителя стейта, защищенного внутренним «поведением / характером», которое выглядит как переключатель «if-else-if-else...», зависящий от входных данных и внутренней логики.
upd
И последний оставшийся шаг
до правильного ООП— это разделить объекты на делающие и хранящие. Первые — это просто чистые функции ФП, вторые — это те самые мутабельные объекты, обменивающиеся сообщениями в духе Smalltalk.В итоге имеем два типа акторов — объекты-состояния и функции.
Скорость уклонения ограничена возможностями человеческого организма выносить запредельные перегрузки. И емнип этот порог уже достигнут.