- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
public static ListBox GetListBox()
{
var list = _customList as ListBox;
if (list != null)
{
return list;
}
return null;
}
Си диез / Говнокод #13862
0
Наверное это бояный пример говнокода, но все же я скопировал его собственными руками
Запостил: 
Smekalisty,
(Updated )
Ваш капитан.
это проверка типа, если у _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 вернуть пустую коллекцию или никуда ничего не писать".
Но в любом случае, проверки и взаимодействие с необязательным элементом беспощадно выделить.