Comments 26
Навеяно вот этим постом:
www.caffeinatedcoder.com/should-we-change-the-way-we-name-interfaces-in-net/
www.caffeinatedcoder.com/should-we-change-the-way-we-name-interfaces-in-net/
В джаве есть ключевые слова extends и implements, а в C# нет, поэтому без префикса не понятно от чего отнаследован класс. Да и удобно это: если смотреть через Object Browser, то все типа расположены в алфавитном порядке, поэтому все интерфейсы располагаются рядом. И опять же IntelliSense никто не отменял.
*все типы
Если бы стандартной нотацией был вариант, взятый из Java, то интерфейсы отображались бы цельной группой над или под группой классов.
Касательно наследования вижу как минимум такой вариант: класс всегда идет первым, остальные перечисленные — интерфейсы ввиду отсутствия множественного наследования в языке C#.
Касательно наследования вижу как минимум такой вариант: класс всегда идет первым, остальные перечисленные — интерфейсы ввиду отсутствия множественного наследования в языке C#.
обязательно нужно
ISomething это не круто, а общепринято.
Я понимаю, что это общепринято, вопрос в том, разумно ли это. Т.е. нравится ли нам стандартная нотация потому, что это хорошая нотация, или потому, что это _стандартная_ нотация?
Потому что это удобно. Даже открывая чужой код (если конечно его не писал урод), мы видим, что у нас интерфейсы, а что классы. Да и новичкам удобно, жаль, что в Джаве такого не сделали.
Ок, рассмотрим все объявляемые элементы языка C#:
1. классы
2. интерфейсы
3. перечисления
4. делегаты
Еще можно отдельно выделить абстрактные классы. Так почему же мы не выделяем их, соответственно, как C, I, E, D, A? :)
1. классы
2. интерфейсы
3. перечисления
4. делегаты
Еще можно отдельно выделить абстрактные классы. Так почему же мы не выделяем их, соответственно, как C, I, E, D, A? :)
Если честно, то я, в свое время, сходу принял венгерскую нотацию и с удовольствием ей следовал.
Отвечу по-порядку:
1. Классу нет нужды быть с приставкой, их можно оставить, как есть, всем понятно, что это переменная, это экземпляр класса, а не примитивный тип (который, вдобавок, в интелисенс и выделяется по-особому). И потом, некоторых товарищей просто воротит от MFC модели именования классов.
2. Уже.
3. И да и нет. Было бы неплохо их отделить, но не критично в прочтении кода. Вдобавок, их можно рассматривать как класс с открытыми переменными.
4. Делегаты это члены класса, это не объекты и они не могут существовать вне рамок своих хозяев.
5. Абстрактные классы. Они нам ни к чему, мы можем иметь объект приведенный к какому-либу интерфейсу, но нам ни к чему такой же объект приведенный к абстрактному классу. Мы ведь не можем вызывать его методы, т.к. в отличии от интерфейса никто не проследит, кем он реализован и не запустит нужный метод.
6. Структуры. Фактически, те же классы. Неплохо было бы отделять, но то же не критично.
Отвечу по-порядку:
1. Классу нет нужды быть с приставкой, их можно оставить, как есть, всем понятно, что это переменная, это экземпляр класса, а не примитивный тип (который, вдобавок, в интелисенс и выделяется по-особому). И потом, некоторых товарищей просто воротит от MFC модели именования классов.
2. Уже.
3. И да и нет. Было бы неплохо их отделить, но не критично в прочтении кода. Вдобавок, их можно рассматривать как класс с открытыми переменными.
4. Делегаты это члены класса, это не объекты и они не могут существовать вне рамок своих хозяев.
5. Абстрактные классы. Они нам ни к чему, мы можем иметь объект приведенный к какому-либу интерфейсу, но нам ни к чему такой же объект приведенный к абстрактному классу. Мы ведь не можем вызывать его методы, т.к. в отличии от интерфейса никто не проследит, кем он реализован и не запустит нужный метод.
6. Структуры. Фактически, те же классы. Неплохо было бы отделять, но то же не критично.
1. Согласен в виду их преобладания
2. :)
3. Спорно, но пропущу
4. Где это вы видели делегаты как члены класса? Делегат это вполне себе тип, который наследуется от MulticastDelegate и объявляется с помощью ключевого слова delegate. По хорошему каждый делегат объявляется в отдельном файле, как и классы, и, соответственно, Конвенция DEventHandler была бы вполне ничего ;) Хотя здесь есть выход — все делегаты и так заканчиваются на Handler.
5. Не скажите, в некоторых местах знать, что в метод передается абстрактный класс, так же важно, как знать, что передается интерфейс или конкретный класс. Так что вполне себе нотация — AController
6. Одно из правил, которому я неизменно следую — Structures are evil :) Хотя здесь SPoint смотрелось бы вполне ничего.
Итого из удобных мест, где можно использовать такую же нотацию, выделяем:
1. Перечисления
2. Абстрактные классы (Можно дописывать суффикс Base)
3. Структуры
Почему в стандартной нотации эти элементы не выделяются? :)
2. :)
3. Спорно, но пропущу
4. Где это вы видели делегаты как члены класса? Делегат это вполне себе тип, который наследуется от MulticastDelegate и объявляется с помощью ключевого слова delegate. По хорошему каждый делегат объявляется в отдельном файле, как и классы, и, соответственно, Конвенция DEventHandler была бы вполне ничего ;) Хотя здесь есть выход — все делегаты и так заканчиваются на Handler.
5. Не скажите, в некоторых местах знать, что в метод передается абстрактный класс, так же важно, как знать, что передается интерфейс или конкретный класс. Так что вполне себе нотация — AController
6. Одно из правил, которому я неизменно следую — Structures are evil :) Хотя здесь SPoint смотрелось бы вполне ничего.
Итого из удобных мест, где можно использовать такую же нотацию, выделяем:
1. Перечисления
2. Абстрактные классы (Можно дописывать суффикс Base)
3. Структуры
Почему в стандартной нотации эти элементы не выделяются? :)
1. В проектах писали либо EnumXXX либо XXXEnum
2. Слово Base очень кстати для абстрактных классов
3. Не вижу необходимости, скорее всего из-за того, что крайне редко пользуюсь ими
«Почему в стандартной нотации эти элементы не выделяются? :) „
— этот момент остаётся на усмотрение команды/разработчика.
2. Слово Base очень кстати для абстрактных классов
3. Не вижу необходимости, скорее всего из-за того, что крайне редко пользуюсь ими
«Почему в стандартной нотации эти элементы не выделяются? :) „
— этот момент остаётся на усмотрение команды/разработчика.
Суффикс Base дописывается в большинстве случаев. Исключений, даже в .NET библиотеке, я на вскидку не припомню (MulticastDelegate не в счет, это делегат, а не просто абстрактный класс).
Кстати, по поводу делегатов, вы их много наследуете? :) Нет же, их чаще всего используют с ключевым словом delegate и все. Понятно, что они специфичны, но у каждого из них (абстрактного и потомка) есть ключевое слово Delegate в названии. Стоит игра свеч?
Другое дело, что есть блоги, в которых разработчики из Microsoft пишут следующее: blogs.msdn.com/kcwalina/archive/2005/12/16/BaseSuffix.aspx
Почитайте в основном комментарии. Народ не любит венгерскую запись, да и в официальном руководстве по C# эта нотация не одобряется. Вот и получается, именовать как-то надо, но кто-то против даже простых суффиксов или префиксов, кто-то предлагает свой вариант, а пока нету стандартов, то всякий делает по-своему. И это ребята из MS, которые занимаются разработкой фреймворка.
Кстати, по поводу делегатов, вы их много наследуете? :) Нет же, их чаще всего используют с ключевым словом delegate и все. Понятно, что они специфичны, но у каждого из них (абстрактного и потомка) есть ключевое слово Delegate в названии. Стоит игра свеч?
Другое дело, что есть блоги, в которых разработчики из Microsoft пишут следующее: blogs.msdn.com/kcwalina/archive/2005/12/16/BaseSuffix.aspx
Почитайте в основном комментарии. Народ не любит венгерскую запись, да и в официальном руководстве по C# эта нотация не одобряется. Вот и получается, именовать как-то надо, но кто-то против даже простых суффиксов или префиксов, кто-то предлагает свой вариант, а пока нету стандартов, то всякий делает по-своему. И это ребята из MS, которые занимаются разработкой фреймворка.
Да это разумно, потому что если этот проект будет писать другой программист, то он не будет ломать голову над тем, почему интерфейс без префикса I.
Мне префикс ни разу не мешал, а иногда даже помогал. Например, когда производиться рефакторинг и из класса X нужно удалить зависимость от класса Y, я ввожу интерфейс IY, который реализует Y, и уже от которого зависит X. Фишка в том, что я не думаю над именем этого интерфейса. Программируя на Java, я бы завис на процессе выбора имени:)
Мне префикс ни разу не мешал, а иногда даже помогал. Например, когда производиться рефакторинг и из класса X нужно удалить зависимость от класса Y, я ввожу интерфейс IY, который реализует Y, и уже от которого зависит X. Фишка в том, что я не думаю над именем этого интерфейса. Программируя на Java, я бы завис на процессе выбора имени:)
1. Резонно, но дискуссия немного не о стандартности нотации, а о ее полезности («а что было бы, если бы ЭТА нотация была стандартной?»)
2. Хороший пример :) +1 в сторону «I»
Я и сам ярый сторонник нотации I, просто стало интересно — это сила привычки и нелюбви к джаве (хаха, мы не в джаве, у нас есть «I»!) или такой подход несет определенные объективные выгоды?
2. Хороший пример :) +1 в сторону «I»
Я и сам ярый сторонник нотации I, просто стало интересно — это сила привычки и нелюбви к джаве (хаха, мы не в джаве, у нас есть «I»!) или такой подход несет определенные объективные выгоды?
С теоретической точки зрения — разработчику должно быть пофиг однородно, класс это или интерфейс в коде, где он используется. Это Java, она «правильная».
С другой стороны, более практичным оказывается разделять класс и «чистый» класс-интерфейс. Это С#, он несколько более практичный.
Ну и капелька религиозности — .net это улучшеный COM, а там ISomething — это закон :)
С другой стороны, более практичным оказывается разделять класс и «чистый» класс-интерфейс. Это С#, он несколько более практичный.
Ну и капелька религиозности — .net это улучшеный COM, а там ISomething — это закон :)
Sign up to leave a comment.
Стоит ли придерживаться нотации ISomething для интерфейсов в C#?