достаешь функтор, показываешь монаде, обмазываешь миксинами и стреляешь себе в копию ноги из деревянного немутабильного пистолета. Просыпаешься

подходишь к монаде и говоришь: У вас такие больше ЛЯМБДЫ

дальше должна быть штука про функтор, но ладно)

Шутки шутками а в четырехмерном пространстве обьекты и состояния врядли мутабельны)

И как бы Егора можно за многое критиковать, но посыл верный. Его обьекты по крайней мере далеко не так связаны

Мне кажется, низкая связность объектов - просто хороший тон в ООП, который, как раз, не является каким-то специальным достижением сам по себе. А в остальном мсье Бугаенко гонит столько сомнительного буллшита, что воспринимать его всерьёз я не готов от слова "совсем".

Мне кажется, низкая связность объектов - просто хороший тон в ООП, который, как раз, не является каким-то специальным достижением сам по себе. А в остальном мсье Бугаенко гонит столько сомнительного буллшита, что воспринимать его всерьёз я не готов от слова "совсем".

а можно более конкретно

твоё лицо, когда опять задали вопрос про хэш-мапы на собеседовании

а можно более конкретно

Про последнее?

ну да. про буллшит егора

твоё лицо, когда опять задали вопрос про хэш-мапы на собеседовании

А ты обкурился эндофункторов и пытаешься не заржать.

Мне кажется, низкая связность объектов - просто хороший тон в ООП, который, как раз, не является каким-то специальным достижением сам по себе. А в остальном мсье Бугаенко гонит столько сомнительного буллшита, что воспринимать его всерьёз я не готов от слова "совсем".

Если говорить с точки зрения дизайна (и упустить за рамки косяки вроде чрезмерных аллокаций) что там такого уж сомнительного?

мне на собеседовании в вокальную школу задали вопрос как-то: Покажи где здесь "кики" а где "буба" и показали вот такие вот пикторграмки: . \ : * O ! _

:D

мне на собеседовании в вокальную школу задали вопрос как-то: Покажи где здесь "кики" а где "буба" и показали вот такие вот пикторграмки: . \ : * O ! _

кики и буба? ну и пошляки

надеюсь ты им бубу не показал?

показал) еще как)

кароче кики это *

а буба O

:D

не спрашивайте почему)))

JVM образовательный.

лучше бы спросили про пупу и лупу

боку но пико\

боку но пико\

че пацаны аниме?

или как отличить пупсиня от вупсеня)

че пацаны ЭНТЕРПРАЙЗ

Вебсферки накатим

Мне кажется, низкая связность объектов - просто хороший тон в ООП, который, как раз, не является каким-то специальным достижением сам по себе. А в остальном мсье Бугаенко гонит столько сомнительного буллшита, что воспринимать его всерьёз я не готов от слова "совсем".

И нет - это не просто хороший тон. Это один из важнейших аспектов code maintainability, про который как правило аутсорсинг компании любят забывать)

И нет - это не просто хороший тон. Это один из важнейших аспектов code maintainability, про который как правило аутсорсинг компании любят забывать)

+1

И нет - это не просто хороший тон. Это один из важнейших аспектов code maintainability, про который как правило аутсорсинг компании любят забывать)

В данном случае под "хороший тон" имелось в виду то, что, на мой взгляд, это такое правило уровня "мой руки перед едой", за соблюдение которого в пример ставить малость странно.

В данном случае под "хороший тон" имелось в виду то, что, на мой взгляд, это такое правило уровня "мой руки перед едой", за соблюдение которого в пример ставить малость странно.

Я бы сказал за несоблюдение оного к стенке бы надо ставить. Но мир неидеален, поэтому вместо этого мы здесь сидим и ноем как ООП плох лол

Один из столпов ОО это наследование... А оно часто в такую кашу превращается

Больше интерфейсов

Нужно больше интерфейсов

В данном случае под "хороший тон" имелось в виду то, что, на мой взгляд, это такое правило уровня "мой руки перед едой", за соблюдение которого в пример ставить малость странно.

да нет. "мойте руки перед и зад" ? это маст хев) если принеберчь все очень быстро в ад погрузится и любое маломальское измнение не будет обходиться без shortgun surgery

Один из столпов ОО это наследование... А оно часто в такую кашу превращается

его нужно уметь деать. Например не наследоваться от реализации)

Один из столпов ОО это наследование... А оно часто в такую кашу превращается

Кстати из той же серии. Наследование ведет как раз к высокому coupling.

только расширять, но не переопрделть и все хорошо будет у тебя с наследованием

а можно более конкретно

http://www.yegor256.com/2014/05/05/oop-alternative-to-utility-classes.html - вот в этой великолепной статье, например, у него благодаря переписыванию "процедурного кода в типа-ООП" мистическим образом меняется сложность по времени. "Besides that, it is obvious that the second script runs in O(1) space, while the first one executes in O(n). This is the consequence of our procedural approach to data in the first script." Хинт - от того, что он потенциально тот же самый код выпихнул из метода в конструктор промежуточно сооружаемого класса, фактическая сложность по времени не изменится, если не меняется используемая алгоритмика.

тогда наследование классов не нужно, бери интерфейсы и делегируй

опять же Бугаенко хорошо описал правила наследования имхо

тогда наследование классов не нужно, бери интерфейсы и делегируй

нужно. абстрактные классы же есть еще

ну вот они не нужны

если не переопределять

функциональность а только расширять

Я бы сказал за несоблюдение оного к стенке бы надо ставить. Но мир неидеален, поэтому вместо этого мы здесь сидим и ноем как ООП плох лол

Именно. Надо. А тут вместо этого хвалили Бугаенко за соблюдение. Что и показалось мне, среди прочего, довольно странной аргументацией.

Именно. Надо. А тут вместо этого хвалили Бугаенко за соблюдение. Что и показалось мне, среди прочего, довольно странной аргументацией.

Опять же - Бугаенко можно за многое критиковать, я этого не отрицал. Но с точки зрения cohesion-coupling его концепция уруливает нахрен весь мейнстрим.

функциональность а только расширять

абстрактный класс содержит базовую логику в виде final методов которые нельзя переопределить а например 1 абстрактный метод. т.е наследник всегда должен реализацию предосавить такого метода и не может изменить поведение базового метода. все логично и хорошо поддерживается, я так работаю - доволен как слон

Опять же - Бугаенко можно за многое критиковать, я этого не отрицал. Но с точки зрения cohesion-coupling его концепция уруливает нахрен весь мейнстрим.

+1

Нельзя в одну кашу смешивать быстродействие, быстроту разработки и maintainability. Это разные термины

У Егора - про последнее. Причем написано как для самых маленьких, а все равно не догоняют)

Угу, мэйнтэйнить код из 15000 классов - тоже, гм, специфичное удовольствие выйдет.

Не вижу в примерах кода Бугаенко maintainability ужасно читаемые лесенки декораторов

И да, new new new new new new new - великие цепочки

Угу, мэйнтэйнить код из 15000 классов - тоже, гм, специфичное удовольствие выйдет.

Отличное удовольствие. Отвечаю. То что в джаве для этого надо много бойлерплейт кода писать, проблемы джавы.

И да, new new new new new new new - великие цепочки

Цепочки можно легко устранить если немного подумать.

Пример проекта дайте где отличный ооп

у него много годных идей, мне лично очень нравятся: immutability, no utility classes, no accessors, no deep inheritance, no blanks lines, no more than 4-5 method params, no shadowing, no "instance of" :D

"Очень много очень маленьких сущностей" и "Очень мало очень больших сущностей" - две примерно одинаково, на мой вкус, плохие вещи, которые вылезают просто чуть разным геморроем. Я предпочитаю постоять посерединке.

И да, new new new new new new new - великие цепочки

DI

DI не ооп и зло

Какой DI, когда у тебя получение потримленных строк из файла - новый объект?

DI

Ну я не DI имел ввиду. А вообще интересный вопрос - если иньекция через сеттеры - так се подход, и иньекция через конструктор рулит - зачем вообще DI? неужели так сложно породить обьект блеать)

ERROR: S client not available

4 -5 параметров в методе это давное еще в Effective Java было , это не от Бугаенко

Ну я не DI имел ввиду. А вообще интересный вопрос - если иньекция через сеттеры - так се подход, и иньекция через конструктор рулит - зачем вообще DI? неужели так сложно породить обьект блеать)

Чтобы делать это через конструктор и чтобы управление такой инициализацией было вне объекта.

а кстати кто нить модет ткнуть меня в спеку джавы, где конкретно написано что new гарантирует инстанциирование в куче? звучит просто не очень логично, зачем т.е лезть в динамическую память если мы в скопе автоматической памяти (на стеке)? например в крестах T t; создает объект прям на стеке что оч круто, и не надо его потмо удалть руками (даже в крестах)

4 -5 параметров в методе это давное еще в Effective Java было , это не от Бугаенко

Вот да, половина вышенаписанного - такие же оригинальные идеи Бугаенко, как колесо - моё изобретение

4 -5 параметров в методе это давное еще в Effective Java было , это не от Бугаенко

Если исключить литературу, то это тоже из серии coupling. Каждый новый аргумент пагубно влияет на cohesion и coupling

Равно как и каждый новый метод

Вот да, половина вышенаписанного - такие же оригинальные идеи Бугаенко, как колесо - моё изобретение

да какая разница чьи они - они клевые и это самое главное

да какая разница чьи они - они клевые и это самое главное

Разницы, чьи - никакой, разница, кого за них хвалить - большая.

а кстати кто нить модет ткнуть меня в спеку джавы, где конкретно написано что new гарантирует инстанциирование в куче? звучит просто не очень логично, зачем т.е лезть в динамическую память если мы в скопе автоматической памяти (на стеке)? например в крестах T t; создает объект прям на стеке что оч круто, и не надо его потмо удалть руками (даже в крестах)

Так то есть escape analysis и скаляризация. Где то у меня спич на эту тему был заложен...

Разницы, чьи - никакой, разница, кого за них хвалить - большая.

community, все по чутьчуть вкладываются

Подаешь в метод Лонг булеан и джсон как это влияет на cohesion и coupling ?

Окей, что из перечисленного внёс именно Бугаенко как сколько-нибудь оригинальное новшество, касающееся структуры и организации кода?

Это на читабельность влияет

Так то есть escape analysis и скаляризация. Где то у меня спич на эту тему был заложен...

ну я имею ввиду наверное то, что зачем просить gc выделять память если можно этого не делать? или там как-то очень хитро оптимизировано оно?

ну я имею ввиду наверное то, что зачем просить gc выделять память если можно этого не делать? или там как-то очень хитро оптимизировано оно?

https://www.youtube.com/watch?v=K6c3W6vhQOA&list=PLVe-2wcL84b-Waky1nkWVSNHPg6eOQWU9&index=14

а кстати кто нить модет ткнуть меня в спеку джавы, где конкретно написано что new гарантирует инстанциирование в куче? звучит просто не очень логично, зачем т.е лезть в динамическую память если мы в скопе автоматической памяти (на стеке)? например в крестах T t; создает объект прям на стеке что оч круто, и не надо его потмо удалть руками (даже в крестах)

Так new в Java и new в крестах — два разных new.

Так new в Java и new в крестах — два разных new.

бля эврика)))

вопрос изначально то какой был?))

вопрос изначально то какой был?))

Так это, Ctrl+F -> new по спеке

Ну блин, праст new T(); в Java — это ж некий аналог T t; в плюсах скорее, если сравнивать. Насколько я понимаю.

не думаю что это корреткное сравнение

не думаю что это корреткное сравнение

А ты не "не думай", а прочитай спеку и скажи точно

Некорректное, но если и пытаться проводить аналогии, то скорее так, чем сравнивание двух new.

запусти цикл for(;;) {new Object()} и прицепись jvisualvm увидишь как gc сборки делает периодчески

Подаешь в метод Лонг булеан и джсон как это влияет на cohesion и coupling ?

Этого недостаточно для ответа на вопрос. cohesion обычно считается как количество независимых друг от друга частей в модуле (классе). Чем больше, тем хреновей. Соответственно чем больше методов, свойств или аргументов, тем больше вероятность что они не cohesive enough

скорее too cohesive, не?

Хотя тут может туплю уже я

Таки как раз нет)

Окей-окей

Cohesion это метрика которая показывает насколько модуль неделим. Если он cohesive, значит он single responsible с очень большой вероятностью.

Да но при чем здесь количество аргументов в методе