YS
поэтому и нужен иногда класс, исполняющий этот контракт
Size: a a a
2020 January 06
ДМ
поэтому и нужен иногда класс, исполняющий этот контракт
интерфейсы нужны для того, чтобы создать контракт, который могут реализовывать любые классы, которые их имплементят
если вы создаете интерфейс, чтобы потом реализовать его только для одного класса, то вопрос, зачем в этом случае интерфейс?
а если же не для одного, то мне как пользователю вашего кода, хотелось бы знать, какую стратегию обхода использует Iterator implements Iterator? Если у меня в коде есть еще такие итераторы как: EvenIterator, OddIterator и тд
если вы создаете интерфейс, чтобы потом реализовать его только для одного класса, то вопрос, зачем в этом случае интерфейс?
а если же не для одного, то мне как пользователю вашего кода, хотелось бы знать, какую стратегию обхода использует Iterator implements Iterator? Если у меня в коде есть еще такие итераторы как: EvenIterator, OddIterator и тд
АД
с этим я согласен
но тенденция такова, что со временем все начинают уходить от префиксов. Префиксы появились в венгерской нотации, когда еще не было крутых IDE, которые могли сказать нам о типе данных. Названия переменных и сущностей в первую очередь должны отражать то, для чего они были определены. А засилие префиксов и постфиксов только осложняет чтение и отвлекает от деталей(сошлусь на "Чистый код")
но тенденция такова, что со временем все начинают уходить от префиксов. Префиксы появились в венгерской нотации, когда еще не было крутых IDE, которые могли сказать нам о типе данных. Названия переменных и сущностей в первую очередь должны отражать то, для чего они были определены. А засилие префиксов и постфиксов только осложняет чтение и отвлекает от деталей(сошлусь на "Чистый код")
В этом не до конца согласен с автором с самого начала. С I все намного проще читается, не нужно гадать, класс это или интерфейс, или енам или ещё что-то. Главное читаемость
ДМ
В этом не до конца согласен с автором с самого начала. С I все намного проще читается, не нужно гадать, класс это или интерфейс, или енам или ещё что-то. Главное читаемость
а зачем гадать?)
AH
В этом не до конца согласен с автором с самого начала. С I все намного проще читается, не нужно гадать, класс это или интерфейс, или енам или ещё что-то. Главное читаемость
ДМ
В этом не до конца согласен с автором с самого начала. С I все намного проще читается, не нужно гадать, класс это или интерфейс, или енам или ещё что-то. Главное читаемость
такой простой вопрос всегда возникает
Раз нам хотелось бы сразу угадывать сущность, то почему бы не использовать следущее:
все интерфейсы с I
все классы с C
все enum с E
что там у нас еще?
вот тогда мы сразу видем все, только не уверен, что мы в читабельности не потеряли
Раз нам хотелось бы сразу угадывать сущность, то почему бы не использовать следущее:
все интерфейсы с I
все классы с C
все enum с E
что там у нас еще?
вот тогда мы сразу видем все, только не уверен, что мы в читабельности не потеряли
YS
для разных итераторов можно сделать разные интерфейсы, через extend оных.
> чтобы создать контракт, который могут реализовывать любые классы.
Почему это? Создать интерфейс даже для одного класса мне вполне нравится, читаемость повышается.
> чтобы создать контракт, который могут реализовывать любые классы.
Почему это? Создать интерфейс даже для одного класса мне вполне нравится, читаемость повышается.
YS
какой-то спор об общих договоренностях, не хочется - можно не использовать конечно :)
ДМ
для разных итераторов можно сделать разные интерфейсы, через extend оных.
> чтобы создать контракт, который могут реализовывать любые классы.
Почему это? Создать интерфейс даже для одного класса мне вполне нравится, читаемость повышается.
> чтобы создать контракт, который могут реализовывать любые классы.
Почему это? Создать интерфейс даже для одного класса мне вполне нравится, читаемость повышается.
зачем интерфейс для одного класса? что это дает с точки зрения семантики и вообще какие преимущества? Или нам просто захотелось больше кода написать?
я понимаю, когда это делается с упором на будущее, когда мы планируем работать с разными классами через один общий интерфейс
я понимаю, когда это делается с упором на будущее, когда мы планируем работать с разными классами через один общий интерфейс
ДМ
какой-то спор об общих договоренностях, не хочется - можно не использовать конечно :)
я хочу получить ответ на один простой ваш аргумент - "Создать интерфейс даже для одного класса мне вполне нравится, читаемость повышается." - как это повышает читабельность класса?
АД
а зачем гадать?)
Чтобы не пытаться "задиаить" интерфейс вместо сервиса, например. Чтобы визуально отличать абстракции в коде и т.д.
ДМ
Чтобы не пытаться "задиаить" интерфейс вместо сервиса, например. Чтобы визуально отличать абстракции в коде и т.д.
C с классами тоже пишешь?
YS
C с классами тоже пишешь?
а $ у Observable пишешь?:)
ДМ
а $ у Observable пишешь?:)
нет, смысл?
YS
Общие договоренности
ДМ
Общие договоренности
ну если в проекте так было заведено - да
безусловно styleguide это основное
вы же говорите, что объявление интерфейса даже если он будет реализован всего лишь одним классом(и больше реализаций не предполагается) повышает читабельность класса
безусловно styleguide это основное
вы же говорите, что объявление интерфейса даже если он будет реализован всего лишь одним классом(и больше реализаций не предполагается) повышает читабельность класса
ДМ
представим, что у нас нет styleguide, и мы пишем проект с нуля
почему в этом случае я должен писать $ или _ у private, или любой другой префикс?
почему в этом случае я должен писать $ или _ у private, или любой другой префикс?
ДМ
а $$
первый раз вижу два знака, это для чего?