Кстати, главный вопрос: офис или удаленка(не фриланс) ? Сильно застряну "в прошлом", если начну с удаленки?)

Так и знал, что нужно выбирать Spring, а не Laravel ?

у ларавель дебильная структура модулей но в целом норм

у Симфони получше но это потому что со спринга крали

у Симфони получше но это потому что со спринга крали

В симфони чате поднималась эта тема) Но я в основном спа приложухи бацаю, от ларки беру по минимуму, так что все не плохо ( но это не точно)

Кстати, главный вопрос: офис или удаленка(не фриланс) ? Сильно застряну "в прошлом", если начну с удаленки?)

всё зависит от твоей самоорганизованности и твоего представлении об идеальном рабочем месте (комфортное место в офисе или ноут на природе/пляже)

сам целюсь уйти однажды на пляж жаркой страны

сам целюсь уйти однажды на пляж жаркой страны

Я 2 раза не осилил офис, так что сейчас на удаленку ) Просто интересно послушать мнение в целом)

это такой же вопрос об идеальном паттерне для апи)

зависит только от самого тебя

при любом выборе важно разделять место где ты работаешь от места где ты отдыхаешь

Я 2 раза не осилил офис, так что сейчас на удаленку ) Просто интересно послушать мнение в целом)

собери волю в кулак и иди на офис

ищи себе команду

один ты далеко не уедешь

ну то есть уедешь но ехать будешь долго

и не ной что мол "ну это ж надо на работу ходить и работу работать"

это такой же вопрос об идеальном паттерне для апи)

это как вообще?

это как искать "идеальный паттерн для ecommerce"

или там "идеальный паттерн для банка"

всем привет. какой паттерн больше к api подходит? я нашел два похожих - посредник и фасад

вот так @fes0r

Ладно, тогда из всех 45и вакансий (минус 20: Middle/senior) постараюсь выбрать что-то годное :D Спасибо )

вот так @fes0r

ты под API что подразумеваешь?

ну я понимаю апи это проект, который в зависимости от полученного запроса (например в _POST) дергает либо заранее выбранные запросы к базе или к внешнему API

вот так

тогда адаптер)

ок)))

это как вообще?

ну а вообще это такой же неверный вопрос, как я уже понял

https://www.youtube.com/watch?v=bVwZquRH1Vk

интересно расказывает (PS: формат спорный - отвлекает сильно)

интересно расказывает (PS: формат спорный - отвлекает сильно)

есть интересное исследование которое говорит, что когда ты слушаешь что-то на расслабоне, то как бы и не факт что ты вообще слушаешь

потому лекции в университетах и не эффективны

могз не думает

есть интересное исследование которое говорит, что когда ты слушаешь что-то на расслабоне, то как бы и не факт что ты вообще слушаешь

Не не в раслабоне дело. Динамический Background отвлекает - что-то прошло, что-то пробежало, проехало. Ну это лично мне. Хотя идея интересная

или полиция в бобик зашла, ага)

хз, меня не отвлекает

меня аж укачало :)

или полиция в бобик зашла, ага)

https://www.youtube.com/watch?v=9SOFqWYpf9Y

https://www.youtube.com/watch?v=9SOFqWYpf9Y

Да тоже интересный формат :) Взгляд на FP “с другой стороны” :D

ага, во второй части там и про раст, и про типы вообще)

https://www.youtube.com/watch?v=9SOFqWYpf9Y

"Автозак Конф 2017 Russia"?

Выделить все самое главное путем "скрытия" всего мещающего :D Насчет эттапа: Добиваю солид на практике (Лисков так и не понял :D), паралелльно смотрю паттерны

lsp - допустим есть тип Птица и есть подтипы: орёл, цапля, воробей. Все птицы умеют летать и во всех местах программы вместо птицы можно будет подставить три эти реализации и всё будет работать. Substitutability is a principle in object-oriented programming stating that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e. an object of type T may be substituted with any object of a subtype S) without altering any of the desirable properties of T (correctness, task performed, etc.). More formally, the Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called (strong) behavioral subtyping, Но есть ещё пингвин, который летать не умеет но он ЯВЛЯЕТСЯ птицей, добавляем пингвина в нашу программу и опять говорим всем птицам лететь, все выполняют команду, пингвин бросает UnsupportedOperationException. Или пингвин должен летать, т.к. он ЯВЛЯЕТСЯ птицей или он не должен быть птицей. Пингвин это нарушение lsp, пример из реального мира: java collection framework.

lsp - допустим есть тип Птица и есть подтипы: орёл, цапля, воробей. Все птицы умеют летать и во всех местах программы вместо птицы можно будет подставить три эти реализации и всё будет работать. Substitutability is a principle in object-oriented programming stating that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e. an object of type T may be substituted with any object of a subtype S) without altering any of the desirable properties of T (correctness, task performed, etc.). More formally, the Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called (strong) behavioral subtyping, Но есть ещё пингвин, который летать не умеет но он ЯВЛЯЕТСЯ птицей, добавляем пингвина в нашу программу и опять говорим всем птицам лететь, все выполняют команду, пингвин бросает UnsupportedOperationException. Или пингвин должен летать, т.к. он ЯВЛЯЕТСЯ птицей или он не должен быть птицей. Пингвин это нарушение lsp, пример из реального мира: java collection framework.

Классное объяснение, даже нагляднее чем квадрат и прямоугольник)

Классное объяснение, даже нагляднее чем квадрат и прямоугольник)

Ох уж этот хабр)

lsp - допустим есть тип Птица и есть подтипы: орёл, цапля, воробей. Все птицы умеют летать и во всех местах программы вместо птицы можно будет подставить три эти реализации и всё будет работать. Substitutability is a principle in object-oriented programming stating that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e. an object of type T may be substituted with any object of a subtype S) without altering any of the desirable properties of T (correctness, task performed, etc.). More formally, the Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called (strong) behavioral subtyping, Но есть ещё пингвин, который летать не умеет но он ЯВЛЯЕТСЯ птицей, добавляем пингвина в нашу программу и опять говорим всем птицам лететь, все выполняют команду, пингвин бросает UnsupportedOperationException. Или пингвин должен летать, т.к. он ЯВЛЯЕТСЯ птицей или он не должен быть птицей. Пингвин это нарушение lsp, пример из реального мира: java collection framework.

Спасибо большое )

Ох уж этот хабр)

при чём тут хабр? Я это ниоткуда не брал

при чём тут хабр? Я это ниоткуда не брал

Я ж не тебе

На хабре статья про солид и там lsp с квадратом и прямоугольником описывается

На хабре статья про солид и там lsp с квадратом и прямоугольником описывается

ага, там еще в коментах какой то чувак забавно прям упёрто отстаивал альтернативную точку зрения

Обычно официальные обьяснения паттернов и принципов слишком сухие, а человек намного лучше понимает аналогии.

ага, там еще в коментах какой то чувак забавно прям упёрто отстаивал альтернативную точку зрения

Решение простое однако) Два класса, делов то

мне про паттерны вот нравится сайтец https://refactoring.guru/ru

ну там ток банды 4 разбираются

lsp - допустим есть тип Птица и есть подтипы: орёл, цапля, воробей. Все птицы умеют летать и во всех местах программы вместо птицы можно будет подставить три эти реализации и всё будет работать. Substitutability is a principle in object-oriented programming stating that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e. an object of type T may be substituted with any object of a subtype S) without altering any of the desirable properties of T (correctness, task performed, etc.). More formally, the Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called (strong) behavioral subtyping, Но есть ещё пингвин, который летать не умеет но он ЯВЛЯЕТСЯ птицей, добавляем пингвина в нашу программу и опять говорим всем птицам лететь, все выполняют команду, пингвин бросает UnsupportedOperationException. Или пингвин должен летать, т.к. он ЯВЛЯЕТСЯ птицей или он не должен быть птицей. Пингвин это нарушение lsp, пример из реального мира: java collection framework.

в таком случае больше интерфейсов == лучше

мне про паттерны вот нравится сайтец https://refactoring.guru/ru

http://designpatternsphp.readthedocs.io этот не плох

в таком случае больше интерфейсов == лучше

lsp = остальные 4 принципа, очевидно же (нет) :D

мне не оч понравился, там некоторые слишком сухо описаны

мне не оч понравился, там некоторые слишком сухо описаны

Паттерны в целом скучная затея

мне про паттерны вот нравится сайтец https://refactoring.guru/ru

а мне про запахи кода

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

Кто то хочет поспорить, нарушает ли java collection framework lsp или нет?

а вот про Cohesion & Coupling мне непонятно до конца, что считается модулем в объяснениях,что внутри модуля должна быть высокая связанность

Кто то хочет поспорить, нарушает ли java collection framework lsp или нет?

а какая разница)

а вот про Cohesion & Coupling мне непонятно до конца, что считается модулем в объяснениях,что внутри модуля должна быть высокая связанность

Я солид не добил, а тут уже grasp

Чертов ооп

а мне про запахи кода

ну да я щас рефакторинг фаулера читаю, там тоже глава про запахи, но на сайте как то живее описана

да там неплохо описано

ну да я щас рефакторинг фаулера читаю, там тоже глава про запахи, но на сайте как то живее описана

Интересная книга )

некоторые советвы слишком капитанские

ERROR: S client not available

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

пишется к чему приводит

типо параметретизация метода

ну да я щас рефакторинг фаулера читаю, там тоже глава про запахи, но на сайте как то живее описана

читал хорошая как и совершенный код

но эти книги надо читать с неким опытом

и написано что addRow(5) лучше чем addFiveRow()

а какая разница)

Ну вообще то хотелось бы знать точно, я думаю что скорее да чем нет, но в то же время то что некоторые методы могут работать или бросать исключения написано в интерфейсе, но если я получу к примеру 5 экземпляров этого интерфейса, я не могу узнать в каком из каких я могу вызывать определённые методы или нет, вот если бы был флаг isUnmodifiable тогда да, но его нет.

ну тут вопрос скорее философский в Java collection

это очень популярная штука

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

поэтому Java collection скорее воспринимать как данность а хорошо или плохо

хз, всегда что то хорошо что то плохо

и написано что addRow(5) лучше чем addFiveRow()

мне кажется, такой пример очевиден без объяснений )

имхо естественно

это очень популярная штука

Это да, но если долго время смотреть туда и не только, то можно увидеть всякие нехорошие штуки. Но это скорее относиться к первым версиям, а те классы уже не выпилить т.к. обратная совместимось. Но и в некоторых местах тоже встречаются нарушения но не так часто.

Помогите разобратсья в ситуцации. Был класс сохряняющий емайлы, и там было 7 зависимостей инжектом(логгер, файлсистем, энтитиманагер и т.д короче в основном все служебные) я добавил 8(токенайзер). Ну естественно я решил что 8 зависимостей это перебор, и решил слегка разбить класс. В итоге вынес отдельно все дела для работы с файловой системой, и убрал логирование из основного класса, добавив обертку с помощью деокрирования. В итоге уменьшил зависимости до 4, но создал 2 доп класса, которые не имею смысла в отрыве от основного. То есть по факту я не уменьшил число зависимостей, а просто пробросил их на уровень выше. На ревью мне скзаали, что раз сделал можно и оставить, но смысла большого в этой моей работе нет. Так вот сосбтсвенно вопрос, как определить, что класс обладает слишком большим числом зависиомостей, и рефакторинг действительно необходим??

понятно что srp и все такое, но все таки в реальных проектах дела не всегда так хороши как в теоретических примерах

понятно что srp и все такое, но все таки в реальных проектах дела не всегда так хороши как в теоретических примерах

Как называются те два класса что не имеют смысла?

Как называются те два класса что не имеют смысла?

Util D:

MeaninglessClassOne и MeaninglessClassTwo )

EmailFileSaver и LockerEmailSaver

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

А lockerEmail что делает?

Ну а основной класс EmailSaver там сохарнения мыла в базу, сохранение аттачментов и т.д

А lockerEmail что делает?

блокировку осуществляет в базе

я поэтому и декоратор применил, т.к блокировка вызывается преед сохранением, а снимается после, т.е удобно было обернуть основной код

и есть еще класс Email?

да, но он не передается в конструктор

это ENtity

она в парамтеры метода save передается

я поэтому и декоратор применил, т.к блокировка вызывается преед сохранением, а снимается после, т.е удобно было обернуть основной код

Сделай интерфейс EmailStorage, и реализации DBStorage, FileStorage и т.д. и декораторы к ним StorageLogger и что то там еще.