- 1
- 2
- 3
- 4
- 5
- 6
public static class IntExtension
{
public static int NotMoreThan(this int i, int thanWhat){
return i < thanWhat ? thanWhat : i;
}
}
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+942
public static class IntExtension
{
public static int NotMoreThan(this int i, int thanWhat){
return i < thanWhat ? thanWhat : i;
}
}
непонятно что
No More!
Then what?
P.S. Ненавижу then и than. Вечно их путаю.
Мне if cond then expr1 else expr2 настолько въелось в мозг, что спутать их стало сложно.
Типа добавляет методы в уже существующий класс
Или это можно и снаружи метод к классу приделать? Тогда неплохая штука, да.
можно подумать, то, что функция без класса не может быть это проблема.
Но это действительно проблема. Класс - это тип данных, для которого определены не только его компоненты, но и функции для работы с ними.
Здесь же имеется какой-то странный тип данных без данных(!), к которому прикрепили функцию для работы с совершенно другим(!) типом данных.
Питушня, непорядок, беспредел, хватит это терпеть! Мы просто привыкли к этой жабологике, считаем её обыденностью и забыли уже наших старых товарищей - кресты и питонцы.
определения для partial классов может быть разрозненным по проекту, а method extensions в другом классе типа не могут?
Интересная штука. Надо было int сделать partial классом, чтобы можно было добавлять методы в int, а не на деревню к дедушке.
Но всё же ценности отдельных функций, свободных от давления кровожадных классов, это не снижает.
И вообще раз пошло такое дело - в большинстве языков ООП не тру. Насколько я помню Тру оно только в смолтоке и нескольких элитарных языках
ЗА СВОБОДУ ФУНКЦИЙ!
А свобода функций - это фп
А в J - свобода глаголов!
Вот и заворачивали бы func всё в какую-нибудь static $MyClass_cs$TempClass15::func, если внутри всё требуется в классах на блюдечке подавать. А пользователь (программист) чтоб этого не видел, пока ему не придётся лезть в скомпилированную питушню.
http://ideone.com/nmbYrf
Вот только что меня бесит - так это связь this внешного класса с внутренним классом в Java, если не писать лишний раз где-то слово "static". Не знаю, как в C#, а вот поведение в C++ мне больше нравится.
Передавай this в конструктор ребёнка руками, передавай руками, сука!
Нормально там всё, разве что немного неинтуитивно, что эта связь по-умолчанию включена. Мне вот жабьего поведения в крестах не хватало ;( Впрочем, его там в общем виде и не запилить из-за отсутствия gc.
Вот! Действительно.
А по-умолчанию оно там, походу, из-за того, что static класс внутри другого не особо то и нужен - его можно унести на один уровень с родителем и поставить уровень доступа package private.
Но это помогает эффективнее использовать тот самый ФОЛДИНГ, про который некогда говорил Пи.
А публичные классы как правило предполагают анальную зависимость от внешнего класса, и само его создание требуется только для получения типа для подстановки во всякие обработчики извне. Ну например
http://ideone.com/NssctQ
Слушай, тебя словно подменили! Мне нравится, как ты общаешься и троллишь. Респект!
403
У вас не все сайты вне рахи уже забанены?
Давайте каждый сам у себя будет троллить
скажи честно, ты упоролся? зачем там делегат?
наверное потому, что внутренний класс может выполнять всю черную работу, и быть необходимым только для класса, где он определен.
в данном примере, есть класс с заказами. ты их туда пушишь, указываешь продукт, стоимость и количество. данный класс хранит их в коллекции специальных контейнеров. при вызове метода OrderTotal возвращает сумму заказов.
не самый лучший пример конечно же, но представим например, есть один класс, который скажем производит загрузку файлов.
ты передаешь ему файл, протокол и URL, а он внутри в виде приватных классов имеет реализацию нужных тебе протоколов, и вызывает их. и получается, что не будет у одного класса методов
UploadFileHttp
UploadFileFtp
UploadFileFtps
UploadFileSftp
UploadFile....
давай только не будем начинать "можно же отдельно реализовать все эти аплоудеры".
internal имеет видимость внутри сборки, поэтому внутри моей сборки он будет как public, но если этот класс выполняет работу только внутри какого-то класса, я не вижу причин делать его internal, private будет в самый раз.
Он прячет часть реализации. Вложенные классы удобны, например, при реализации итераторов. Точный тип итератора не торчит наружу, доступен только через интерфейс.
По сути - это такой встроенный в язык фасад.
>> Я не особо понимаю необходимость
нет необходимости. Как и в ООП нет необходимости. Просто фича
http://ideone.com/k4Sprh
http://ideone.com/OGPlYZ
http://ideone.com/OlPG8p
Читать пробовал перед тем как писать?