или "потом пригодится"? если последнее - YAGNI

как пригодится так и заведешь

а интерфейс зачем тогда? если судя по названию реализация всегда одна

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

инструменты автоматического рефакторинга что ли не завезли

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

это не стоит настолько буквально воспринимать

как пригодится так и заведешь

Ой, мамочки

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

ну то есть у тебя у ЛЮБОГО объекта есть интерфейс, публичная часть, API

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

но ты в этом случае уже должен знать специфику

но ты в этом случае уже должен знать специфику

так да, я понимаю особенность конкретной реализации

Ой, мамочки

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

инструменты автоматического рефакторинга что ли не завезли

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

идея в том что бы у тебя сокрытие информации происходило, что внутри происходит

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

пример из жизни

Любой композер пакет

сек

ты торопишься

- был класс App\Orders\Order который зависил от App\Payments\AccountGenerator класса. - спусля пол года появилась необходимость сделать несколько реализаций. Теперь старый класс называется NxtAccountGenerator а интерфейс остался тем же, в итоге зависимый код ничего и не узнал

Любой композер пакет

опять же чинится ровно таким же способом.

и опять же в этом случае намного проще в плане "наверное будут другие реализации и моя реализация дефолтная и отличается тем-то тем-то"

о, я как раз эквайринг ща делаю

из говна и палок, но вас читать забавно)

так как реализовать shape.isFitInto(door) если shape и door - объекты? кто должен "раскрыть" свои параметры?

тот у кого больше информации для выполнения операции, information expert. Думаю здесь shape.ifFit() подходит

- был класс App\Orders\Order который зависил от App\Payments\AccountGenerator класса. - спусля пол года появилась необходимость сделать несколько реализаций. Теперь старый класс называется NxtAccountGenerator а интерфейс остался тем же, в итоге зависимый код ничего и не узнал

А если зависимый код экстендил класс AccountGenerator? Или создавал его инстанс через new?

А если зависимый код экстендил класс AccountGenerator? Или создавал его инстанс через new?

то автор сам дурак)

1. dependency injection 2. final класс

Т. е. вместо того, чтобы сразу позаботится о расширяемости своего модуля, обрубаем концы и вставляем палки в колеса? :)

Это основополагающий принцип: программировать на уровне абстракций, а не конкретных реализаций.

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

ХАХАХАХ!

с сферическом вакууме да, абстракции рулят

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

Что в подходе с интерфейсом этому противоречит?

лучший код что я видел это максимум скачала фреймворк и глянул на него и все,

Что в подходе с интерфейсом этому противоречит?

ничего, как и с классом без интерфейса

в более менее рабочем проекте всегда говны тонны

мне фраза нравится: я видел два типа проекта - рабочий и с хорошим кодом

Это основополагающий принцип: программировать на уровне абстракций, а не конкретных реализаций.

основополагающий принцип - information hiding, но про него мало кто помнит

с сферическом вакууме да, абстракции рулят

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

я думал вы тут науку на землю приземляете

Т. е. вместо того, чтобы сразу позаботится о расширяемости своего модуля, обрубаем концы и вставляем палки в колеса? :)

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

или вы чисто науку гнете?

если науку, то окай, я не прав

основополагающий принцип - information hiding, но про него мало кто помнит

Я знаю про инкапсуляцию, а про такое не слышал

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

а что такое ооп?)

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

есть такая мысль - premature generalization is root of all evil

Я знаю про инкапсуляцию, а про такое не слышал

вот об этом я и говорю. Икапсуляция для многих это геттеры и сеттеры

есть такая мысль - premature generalization is root of all evil

Это не обычно не про интерфейс :) про более высокие уровни.

Типа, если тебе нужен кастомер, не нужно начинать с класса HumanBeing.

Это не обычно не про интерфейс :) про более высокие уровни.

да про любые это уровни)

вот об этом я и говорю. Икапсуляция для многих это геттеры и сеттеры

К сожалению, но не улавливаю как это связано с темой сейчас.

Это не обычно не про интерфейс :) про более высокие уровни.

и да и нет - если ты просто так лепишь интерфейс - это по сути оно и есть

Типа, если тебе нужен кастомер, не нужно начинать с класса HumanBeing.

а если у тебя робот будет кастомером?

что за желание наследовать все?

идея с абстракциями очень простая

что за желание наследовать все?

Где ты его увидел?

ну ты ж сам про хуман бин упомянул

абстракции идут после конкретики

то есть сначала тебе надо решить "что у тебя есть" а уже потом обобщать

а многие начинают сразу интерфейсы липить и абстракции лишние

и да и нет - если ты просто так лепишь интерфейс - это по сути оно и есть

Объясни, плиз, как тогда "не просто так"

вот выше и объяснил

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

потому что не надо разрешать его "расширять"

пока мы не поняли как его юзают

К сожалению, но не улавливаю как это связано с темой сейчас.

другое название этого принципа - open/close principle. И еще одно название - protected variations.

это я про information hiding

это имеет непосредственное отношение к абстракциям, late binding и "расширяемости"

а многие начинают сразу интерфейсы липить и абстракции лишние

Ну, вот тут не соглашусь. Если сначала решить задачу на уровне интерфейсов и взаимодействия между объектами этих типов, то будет более глубокое понимание системы. И уже потом стоит приниматься за реализацию этих типов.

и инкапсуляция - она просто про "есть внутри и есть снаружи"

другое название этого принципа - open/close principle. И еще одно название - protected variations.

Ой, это что-то вообще не про то, но заводится, чувствую, не стоит.

Ну, вот тут не соглашусь. Если сначала решить задачу на уровне интерфейсов и взаимодействия между объектами этих типов, то будет более глубокое понимание системы. И уже потом стоит приниматься за реализацию этих типов.

1. стоимость исправления ошибок возрастает на порядки если твое глубокое понимание оказалось ложным 2. это работает только для очень простых задач

Ну, вот тут не соглашусь. Если сначала решить задачу на уровне интерфейсов и взаимодействия между объектами этих типов, то будет более глубокое понимание системы. И уже потом стоит приниматься за реализацию этих типов.

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

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

и под "отрефакторить" я не про когда люди месяц пилят и потом пытаются выбить неделю на рефакторинг, а 20-30 минут кодинг и 5-10 минут рефакторинга

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

Ой, это что-то вообще не про то, но заводится, чувствую, не стоит.

ты точно понимаешь про что это?

и под "отрефакторить" я не про когда люди месяц пилят и потом пытаются выбить неделю на рефакторинг, а 20-30 минут кодинг и 5-10 минут рефакторинга

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

у меня скорее так - кодишь неделю, потом день рефакторишь

у меня скорее так - кодишь неделю, потом день рефакторишь

это весьма не продуктивный способ)

попробуй)

оно так намного "чище" код выходит.

ну и еще принцип бойскаута

у меня проблема в том что все обстракции рисуются в процессе и с самого начала знаю примерно 50% как будет выглядит, остальное рисуется на ходу

ну это особенности говна в котором я сижу)

у меня проблема в том что все обстракции рисуются в процессе и с самого начала знаю примерно 50% как будет выглядит, остальное рисуется на ходу

ну так как раз для таких подходов это и нужно

"наперед" абстракции делать весьма трудозатратно

так в том и прикол, что есть хорошо и что есть плохо ясно в конце)

20 минут это так се конец)

но можно попробовать

20 минут это так се конец)

ну хз... сильно зависит от того как ты дробишь задачи

Проектировать не пробовал перед кодингом?

интересено как это выглядит

"наперед" абстракции делать весьма трудозатратно

Необосновано.

Необосновано.

пробовали. месяц проектирования и планирования, 3 месяца разработки, пол года все было хорошо а потом пришли изменения требований

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

И что, напроектировали такого, что не выдержало изменений?

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

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

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

К удивлению :)

ну это скорее не понимать, а быть источником этих бизнес-процессов. Тогда да, ты все знаешь наперед