Я вот хотел бы посоветоваться со знающими людьми. Как обычно создаются интерфейсы ? Только я о таком создании интерфейса, чтобы в нём действительно был смысл и это приносило пользу. Как я понимаю это сейчас: 1) Пишем какой то метод, например showPaginatedItems(); 2) Понимаем что этому методу нужна зависимость, от getItem(); getAllItems(); 3) Понимаем что в данном случае лучше создать интерфейс(я прав что лучше создавать в таком случае зависимость именно от интерфейса, а не от абстрактного класса, пишите если я чего то не понимаю) 4) Создаём интерфейс ... Потом первую его реализацию, которая тягает из базы items с помощью mysqli 5) Ну создадим вторую реализацию, тягающую items из postgresql Итог: по сути достигли цели, написали что зависим от getItem(); getAllItems(); результат которых что важно удовлетворяет showPaginatedItems() А также можем переключать, то как методы достигают этих целей. По сути идея создания интерфейса должна приходить, когда нашему коду(методу) нужны, например результаты деятельности какого либо компонента, описываем часть компонента с которой будем взаимодействовать в интерфейсе(в этом суть интерфейса, для таких случаев, как я сейчас это понимаю), ну и далее реализуем интерфейс. ЗЫ Понимаю может сложно получилось описать, если вы вникли, и вам есть что сказать, пишите ЗЫЫ Пишите когда вам на ум приходить идея создать интерфейс
Это называется инверсия зависимостей. Т.е. если классы разных уровней зависят друг от друга (к примеру, класс "Пользователь" сохраняет информацию в "Хранилище"), то лучше сделать "Хранилище" интерфейсом, а не конкретной реализацией, чтоб потом можно было подставлять разные. https://habrahabr.ru/post/158213/. Я до некоторых пор ленился всё это внедрять, но когда запорол архитектуру крупного проекта, понял, что стоит начинать
Сначала нужно выделить сущности. Определить - какой объект чем будет заниматься, какая у него роль, какие ответственности возлагаются на него, какие внешние воздействия на этот объект необходимы. Это и будет интерфейсом - неотъемлемой частью любого объекта. И уже потом будете решать - фиксировать этот интерфейс средствами языка, или нет.
Интерфейс бывает полезен для кодинга, т.к. в нем описан минимальный набор методов. Если есть желание какой-либо класс попробовать заменить другой реализацией, по интерфейсу сразу видно, какие методы необходимо реализовать, чтобы завелось. На один класс можно имплементировать несколько интерфейсов, поэтому в идеале все публичные методы должны быть покрыты интерфейсами.
можно ещё интерфейсом загородиться от неправильного типа объекта, указав в функции, какого типа аргумент она должна принимать. При этом по факту, объект может быть другого класса, но просто имплементирующий данный интерфейс. Интерфейс это как трафарет. А расскажи плс подробнее, а то что-то второй день о твоём сообщении думаю.
Ну на самом деле я не конкретно инверсию зависимостей имел в виду, а вообще принципы SOLID и принципы проектирования, инструменты типа UML и пр. Просто я достаточно долго сидел на простых проектах относительно, которые даже при примерном проектировании без учёта SOLID и др. у меня выходили достаточно изменяемыми и которые я успешно сдавал. А тут попался сложный проект, и сейчас, когда большая часть кода готова, я вижу все недостатки недопроектирования, и понимаю, что надо срочно этот скилл накачивать, поскольку получились и огромные классы, и тесные связи, да вообще мне код не нравится свой же.
я просто понять не могу, что там такого ты навертел, что нельзя за пару дней отрефакторить на впрыск зависимостей? Покайся, что сотворил.
Да не, отрефакторить можно, и придётся наверное, только это займёт больше времени, чем 2 дня, поскольку говнокода прилично накатал...
пример с базами плохой. какую пользу и смысл несёт возможность переключения между базами в каждом конкретном приложении? а по факту ты теряешь плюсы и той, и другой базы. приведи ситуацию, в которой тебе действительно понадобились интерфейсы и проектирование.
ну хз. Я как работодатель считаю что это хорошо. Когда ты начинаешь, я б даже сказал, пока не пустишь реальных людей делать реальную работу - ты не знаешь точно, какие функции и как должны быть. Говнокодить побырику - это хорошо. Если кто-то думает, что заранее знает - он ошибается. А рефакторить это хорошо. И быстро. Если делал месяц, то отрефакторить можно полностью всё идеально за неделю, т.к. уже знаешь всё.
Говнокод не рефакторится в принципе. Все, что можно делать с говнокодом - приделывать еще очередные костыли. Через годик такого костыляния - все развалится, особо если есть хоть какая-то ротация кадров. Работодатель будет терять деньги из-за разгребании очередных багов. И это хорошо, если весь говнокод был покрыт хотя бы функциональными тестами... но нужно же было бысто и дешево, так что тестов почти точно - нет. Хорошая архитектура - это как раз архитектура про рефакторинг. Весь ООП, все практики и методики, всякие буковки типа SOLID и т.п - они все решают вопрос уменьшения стоимости поддержки. За счет более легкого вхождения в проект, за счет более легкого и безконфликтного рефакторинга. Хорошая архитектура - это не про то, что бы создали 100500 интерфейсов и классов. Это о том, что бы создали ровно столько, сколько нужно, но правильно. Иначе получаетя, да, месяц пишем - неделю рефакторим, потом еще месяц пишем - две недели рефакторим, так как бизнес поменял требования. Офигенный бизнес, да... пока есть лохи, которых можно так разводить на деньги.
под рефакторингом я понимаю "переписать целиком". Т.к. известны точки входа и выхода, наиболее часто используемые и повторяемые куски кода и сложные моменты, то можно написать просто и коротко и очень быстро, хотя казалось, что этот выстраданный говнокод занял месяцы на своё рождение. ну это зависит и от того, какой результат хочется получить этому бизнесу. Во многих случаях и говнокоду будут рады.
Ну это не рефакторинг. Читай Фаулера. Переписать все заново можно через месяц, может быть. С достаточно небольшим числом багов, если есть QA или хотя бы какие-то тесты. И если у бизнеса есть время - а вот это почти никогда не бывает. К когда время дадут, через год...два... такое переписывание выльется в огромное число багов - там забыли, тут забыли. Это же говнокод, по нему не поймешь - это строчка - забытое условие или костыль под какой-то глюк. Даже с функциональными тестами переписывание сервера с нуля черезе год - огромная работа для QA по ловле багов. А самое главное - говнокодер никогда не напишет хорошую архитектуру. Т.е. по хорошему переписывание нужно давать другому человеку. А это еще больше багов, ибо новый человек, какой бы профессионал он не был, не может знать всех нюансов бизнес-логики, которая у говнокодера где-то в голове, но точно не в коде или вики
А суть в том, что базовые принципы вообще никак не зависят от того, что за проект, что будет. SRP зависит? Нет. Инверсия зависимостей? Инкапсуляция? А если уже говорить про выделение сущностный, сводного корня и т.п... поменяется, да. Может 5 раз, а может и 3... в какой момент начнешь "правильный код" писать? То, что через 3 месяца из кофеварки, внезапно, потребуется тостер, а кофе никто никогда не будет - это факт для любого развивающегося проекта. А вот как болезнено будет проходить эта переделка, и не сломает ли она кипячение воды, которой пользуется директор - это уже вопрос архитектуры.
Нет, зависит не от проекта, а от опыта его руководителя и/или исполнителя. Все остальное - лишь попытка маскировать собственное незнание.
работник приходит в компанию, которая использует битрикс. будет он использовать инверсию зависимостей? или пойдёт начальнику доказывать, что тот маскирует собственное незнание?
Извините, тут разговор о разработке нового проекта. Хотя, соглашусь, если на проект всем насрать, что будет через год и нужно побыстрому что-то слабать, то никакая архитектура не нужна, нужно брать битрикс Но нормальный специалист на это не пойдет, вы же понимаете.
насколько я понял, вопрос задал будущий специалист. и, как мне показалось, начал с очень распространённой ошибки: начал проектировать интерфейсы к "переключению баз данных". для одиночного проекта это очень и очень редко надо. поэтому я и написал задачу, которая, мне кажется, более полезна, чем проектирование ради проектирования
хуже от проектирования не станет, если оно правильное Я ничего не начинал. Почему то все поняли, что это был пример не относящийся к реальным проектам. А вы начали мне объяснять про практические аспекты.