без автолоадера в принципе, не будет. Но тут проблема в том, что товарищ свой и чужой не может подружить)

есть ли в этом хоть какой-нибудь смысл или лучше про что-нибудь другое написать? например information hiding или GRASP

мининекропост лучше любой баззворд, кроме солид причина - солид достаточно прост и разжеван для базового понимания

мининекропост лучше любой баззворд, кроме солид причина - солид достаточно прост и разжеван для базового понимания

практика показывает что нет)

есть не нулевая доля вероятности что мое понимание SOLID отличается например от твоего)

причем значительно

оно конечно есть оригинальная публикация (еще до появления SRP и когда принципов было 11 а не 5) и там да, в целом понятно

но люди не читают первоисточники

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

разные углы обзора это всегда хорошо

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

ты воспринимаешь наследование как "принцип" или как "механизм"

?

"инкапсуляция" тоже разная бывает, есть сокрытие данных а есть сокрытие информации, и люди часто это путают

так что вроде бы "все разжовано" и "все основы" но почему тогда столько проблем с этим?

полиморфизм - тут вообще молчу

когда я продумываю кусок бизнес - логики - принцип когда пишу код - механизм

просто люди слишком мало думают

или слишком много

когда я продумываю кусок бизнес - логики - принцип когда пишу код - механизм

скажи мне в чем заключается принцип "наследования"?)

имхо, проблемы возникают тогда, когда люди слишком упарываются книжной тематикой, где всё расписано в рамках идеального сферического мира в вакууме) на практике оно абсолютно всегда сильно иначе)

ну то есть вот "продумывание куска бизнес-логики" - зачем тебе наследование? полиморфизм у тебя отдельно стоит

имхо, проблемы возникают тогда, когда люди слишком упарываются книжной тематикой, где всё расписано в рамках идеального сферического мира в вакууме) на практике оно абсолютно всегда сильно иначе)

нет. проблемы возникают когда люди бездумно читают пару книжек а потом думаю что они архитекторы и вообще все знают

одно и то же)

хм, вопрос с заковыкой - никогда не любил такие формулировки в общем и целом - воспринимаю наследование по аналогии с генетикой

ну просто проблема не в книжках где все "идеально", во многих этих книжках как раз особо подчеркивают что "ребят в реальной жизни все чуть по другому". Почитай того же Мэйерса, он хоть и идеалист но в своих книгах всегда пишет "вы не пытайтесь сразу придти к open/close например, устраняйте проблемы по мере возникновения"

хм, вопрос с заковыкой - никогда не любил такие формулировки в общем и целом - воспринимаю наследование по аналогии с генетикой

ну то есть механизм

не принцип

для принципа у тебя есть полиморфизм

я не понимаю 2х из 5 букв солид и мне не стыдно в этом признаться)

я не понимаю 2х из 5 букв солид и мне не стыдно в этом признаться)

а каких если не секрет?

могу сказать что большинство не понимают S и O

o и l. самые упоротые, имхо

o и l. самые упоротые, имхо

оооо так я могу объяснить за 5 минут) хочешь?)

это мы уже приходим к вопросу значения слов "принцип" и "механизм" в данном контексте

запускай)

это мы уже приходим к вопросу значения слов "принцип" и "механизм" в данном контексте

открой словарь и посмотри значения. Эти слова вполне конкретную семантику несут.

с примерчиками)

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

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

что такое наследование что такое полиморфизм является ли наследование механизмом для достижения полиморфизма?

тут я сдаюсь - в формулировках слишком плаваю, моего набора знаний пока для них не хватает а приводить свою интерпретацию текста из словаря/Википедии/etc не вижу смысла

O - Open/Close - принцип, согласно которому ты должен стараться писать код так, что бы его можно было расширять без модификаций. В идеале - любая фича тупо за счет нового кода и без единой правки старого кода. Пример - декорация. Ты можешь добавить поведение не меняя код оригинального класса. Основные виновники того что нам приходится менять код - оператор new (решается за счет инверсии управления, фабрики и т.д.), if-ы разных сортов (декорация, стратегии, полиморфизм тот же). Константы и т.д. тоже туда же. По факту 100% соблюдение этого принципа невозможно на практике. Как минимум потому что ты никогда не знаешь с какой стороны прилетит изменение. Потому наиболее эффективно этот принцип соблюдать когда тебе уже прилетело изменение (либо очевидно как оно будет меняться). I - Interface Segretation - принцип который буквально означает "маленькие специализированные интерфейсы лучше больших общего назначения". Идея такая - у тебя есть код, который зависит от какого-то класса. Разработчик класса когда его проектировал понятия не имел как он будет использоваться и потому просто пихал туда методы. В итоге у нас есть один больной интерфейс общего назначения. С другой стороны клиентскому коду нужны только 1-2 метода из всей этой пачки. И каждому нужны свои. Потому нам лучше выделить несколько интерфейсов каждый под клиента. Таким образом мы уменьшаем связанность и это облегчает и расширение поведения (декорация) и в целом уменьшает потенциальную возможность для разрастания каскада изменений. Еще это неплохой способ соблюсти LSP.

L, а не I)

L, а не I)

а ну сча, дай покурю, тут надо про разницу между интерфейсами и поведением, про прекондишены и посткондишены с инвариантами. Но в целом если коротко соль в том что если у тебя есть объект какого-то типа, и ты вдруг захотел сделать наследника от него, то тебе можно это сделать ТОЛЬКО если ты сможешь потом в коде подставить свой новый подтип и ничего не сломается. Таким образом мы соблюдем open/close

но спасибо в любом случае)

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

пример бы) желательно попроще, для джунов)

ну классический пример с квадратом и прямоугольником :)

эт для синьёров)

ну классический пример с квадратом и прямоугольником :)

не он бесполезен

пример бы) желательно попроще, для джунов)

List и Stack. У тебя у двух этих типов коллекций есть метод push и pop предположим. Только поведение у них будет разным, так?

ну то есть представь что у тебя использовался стэк а ты вдруг взял и подставил туда список

явно что-то сломается

а если так - это просто два разных типа. Они никак не объеденяются общим интерфейсом. У них может быть общим только интерфейс Countable например какой-нибудь который предоставляет информацию о длине коллекции.

а чем плох пример с квадратом?

потому что для обоих этих типов count будет иметь одинаковое поведение

а чем плох пример с квадратом?

сложно придумывать примеры адекватные. Да и люди начинают скатываться в демагогию на тему геометрических фигур вроде "ромб тоже может быть квадратом" хотя по факту LSP как раз таки тот прицип который позволяет избавиться от подобной дискуссии и смотреть только на требуемое поведение.

а вот примеры где объекты имеют простое и понятное поведение - тут проще

короч если у тебя появляются всякие if (obj is Something) то есть мнение что ты нарушил LSP (но это не 100%, только один из вариантов, самый распространенный)

ну то есть в целом все принципы SOLID они как бы о том "как приблизиться к достижению open/close"

и как следствие уменьшить эффект лавинообразного изменения кода

и нет смысла понимать 3 из 5-ти принципов, потому что это комплексная штука

ну и еще - нет смысла париться о этих принципах если у тебя нет изменений) Или еще нет изменений - всеравно скорее всего ты что-то не учтешь

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

вот, сформулировал введение)

а что такое это "к тому, что надо"?)

оно ж работает, зачем трогать)

разница в подходах вот в том что "оно работает".

ну то есть "оно сейчас работает"

да оно и потом будет, если не трогать)

согласись, глупо трогать то что работает, но если тебя попросили это что-то поменять - волей неволей придется потрогать

так?

SOLID это принципы, которыми ты должен руководствоваться что бы уменьшить количество вещей которые придется потрогать

если оно написано +/- вменяемо, пускай даже без соблюдения половины солидных требований, это будет не так сложно отрефакторить при большом желании. Вопрос цены в конечном счёте. что выйдет дешевле: рефакторинг какой-то дурнопахнущей херни, или бесконечное вылизывание кода до идеального состояния)

если оно написано +/- вменяемо, пускай даже без соблюдения половины солидных требований, это будет не так сложно отрефакторить при большом желании. Вопрос цены в конечном счёте. что выйдет дешевле: рефакторинг какой-то дурнопахнущей херни, или бесконечное вылизывание кода до идеального состояния)

воооот, ты правильные вопросы задаешь)

как ты определишь что этот кусок кода "дурно пахнет"?)

вот смотрю на юи и сразу определяю)

и еще вопрос - что дешевле - отрефакторить маленький кусочек кода или большой?

всё зависит от их сложности

всё зависит от их сложности

кого "их"? кусочков?

давай мы будем мерять сложность кусочков по количеству точек соприкосновения. У тебя есть точка в коде которая соединена с другой точкой и еще одна которая соединена с 10-ю точками

что проще отрефакторить? Ведь проще = меньше дефектов = дешевле

ну то есть это уже про рефакторинг как часть процесса разработки. Когда ты не ждешь что вот этот кусочек кода заваняет так что у тебя глаза будет резать а сразу подправишь - это не должно много времени занимать и явно будет дешевле чем на пару дней садиться рефакторить.

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

ога. я когда пришёл в процессинг работать, меня сразу посадили на проект с Илитой. Там было 3 десятка точек входа и все они вели редиректами в 1: вундервафлю на 9 тысяч строк кода, которая содержала свитч на полторы тысячи кейсов. С вложенными ещё к тому же) но ничего, когда случилось больше желание, подрефакторили довольно быстро. А вот тот факт, что этот монстр позволил привлечь огромное кол-во жирных проектов и был написан тремя калеками на коленке с точки зрения бизнеса вышел дешевле)

ога. я когда пришёл в процессинг работать, меня сразу посадили на проект с Илитой. Там было 3 десятка точек входа и все они вели редиректами в 1: вундервафлю на 9 тысяч строк кода, которая содержала свитч на полторы тысячи кейсов. С вложенными ещё к тому же) но ничего, когда случилось больше желание, подрефакторили довольно быстро. А вот тот факт, что этот монстр позволил привлечь огромное кол-во жирных проектов и был написан тремя калеками на коленке с точки зрения бизнеса вышел дешевле)

http://wiki.c2.com/?SingleChoicePrinciple

специально для тебя)

> тремя калеками на коленке с точки зрения бизнеса вышел дешевле) но ты же не знаешь дешевле или нет

много букв, явно для мидлов) с утра почитаю, спасибо)

помимо стоимости итогового решения бизнес еще интересует предсказуемость

если оно будет на 5% дороже но зато ты сможешь более-менее точно говорить когда что будет готово без этих "ну хз, там рефакторить надо", то это может быть стратегически более верным решением для бизнеса. Но случаи разные бывают.

но я повторюсь - я не зря сказал что open/close ради которого все и делается не достижим - ты должен вылизывать не до идеала (недостижим же) а просто что бы устраивало. Если тебя устраивает гигансткий свитч - ничего страшного

тем более если у тебя это в одном месте

и изолировано

гугл -> ницше, идеал

ну короч надеюсь ты понял.... SOLID это неплохой инструмент для того что бы определиться что и зачем рефакторить

проектировать через SOLID - глупо, это может быть только если развитие кода дальше для тебя очевидно

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

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

какая же?)

а оно точно будет работать так, как задумано?!

а оно точно будет работать так, как задумано?!

ну тут риск менеджмент надо...