- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
public static ListBox GetListBox()
{
var list = _customList as ListBox;
if (list != null)
{
return list;
}
return null;
}-
C# / Говнокод #13862
+137
Наверное это бояный пример говнокода, но все же я скопировал его собственными руками
Запостил:
Smekalisty,
27 Сентября 2013
Follow us!
Ваш капитан.
это проверка типа, если у _customList тип ListBox, то вернется ссылка на объект _customList иначе вернется null.
Зачем это было сделано хз. Видимо может быть само поле помечено типом object.
И типа супер-пупер полиморфно.
Адекватная причина только одна - там может быть не только листбокс.
> супер-пупер полиморфно
Ага, настолько полиморфно, что пришлось корячить неполиморфный геттер под конкретный тип ;)
если перегибать - то по интерфейсу с полями на метод. ну вы поняли.
ООП превращает людей в похуистов.
> по интерфейсу на метод
Ну это уже точно перегиб. Все-таки связанные друг с другом методы должны быть в одном интерфейсе.
Страшно, имхо, только тогда, когда и частное и общее суют в одно поле. После чего с частными случаями работают каким-то особым способом, а с общим - другим, обобщенным. И везде ифы, касты, свичи... и в else вызовы обобщенных методов :)
P.S. Я не отрицаю, что для производительности это может оказаться полезным.
врядли. для производительности хорошо правило без исключений, исключения слишком дороги. да и будить лишние сущности дороговато в плане ресурсов. (если у нас 1е6 посетителей в секунду)
Ну вот взглянем на тот же RandomAccess и сортировку. Здесь разделение на два случая только ускоряет работу :)
Примеров, когда какое-то дополнительное знание может сделать код более быстрым, довольно много.
P.S. Хотя, может быть, более правильным было бы вообще не смешивать интерфейсы с последовательным и произвольным доступом... В том же линуксе не зря блочные и символьные устройства разделены...
например, вместо if(a)o[a] else o.[b] просто o.a или что-то вроде на всю логику - которая условна, но в данный момент естественна и линейна. потом будет другая, но не менее линейная
Но вообще, если копать глубже, даже ваш код — излишество, так как у листов должен быть минимальный общий интерфейс, и он, в принципе, есть.
Так это верхний код, где нам похуй ;) Где же в нем излишество?
Нижний код это скорее фоллбек, на случай если очень хочется вызвать что-то специализированное, а архитектуру менять не хочется. И в нем излишества не больше, чем в коде ОП'а.
Я про нижний конечно же.
PS
Код опа нельзя принимать за эталон. :)
С другой стороны, по коду после вызова этого метода будут разбросаны проверки на нулл. Так что это была полумера.
>Так что это была полумера.
+1.
Имхо удобнее получить ClassCastException, чем потом везде проверять. Или не проверять и получить NPE.
>_customList as ListBox
Сахар, который особо не спасает.
Или можно остановиться на локализации взаимодействия с этим типа-ListBox'ом до нескольких методов чтения/записи, каждый из которых вначале содержит граничное условие "если не ListBox вернуть пустую коллекцию или никуда ничего не писать".
Но в любом случае, проверки и взаимодействие с необязательным элементом беспощадно выделить.