Да, наверное в ваших словах есть доля правды. Однако мало просто пахать, надо пахать в нужном, правильном направлении, и тогда будут какие-то результаты.
Вот человек определился, в каком направлении, и усиленно начал пахать. Результат налицо :)
Скажем так, из круга знакомых у меня есть несколько примеров, как люди, не обладая вообще никакой гениальностью, исключительно упорным трудом, начиная со школьной скамьи, добивались впечатляющих результатов. И наоборот, будь ты хоть трижды гением, если сидишь на попе ровно и никуда не двигаешься - никуда и не придёшь.
Гений - 99% пота, как говорил Эдисон. Очень круто что человек смог собрать волю в кулак, и зарешать необходимые пункты для получения такой визы. Было бы желание, как говорится.
Вывод совершенно верный, вот только C++ тут в общем-то ни при чем. Если удариться в крайности, есть два варианта:
1. Низкоуровневая структура, представляющая собой отображение какой-то структуры в памяти и/или в файле (пример — структуры в WINAPI). Ни геттеры, ни сеттеры там никому не нужны (хотя их и можно было бы добавить)
2. Класс, реализующий какую-то высокоуровневую логику, напрямую не маппящийся в память и/или в файл — здесь скорее всего возникнет необходимость инкапсулировать какую-то логику, могут появиться get-only property (и, не дай бог, set-only), логика которых может быть (а может и не быть) чуть-чуть сложнее, чем return _value. Ничего плохого в этом нет, интерфейс отдельно, реализация отдельно.
Таким образом, нельзя на 100% сказать, что геттеры / сеттеры зло — разумный программист будет добавлять их там, где они имеют смысл, и не будет делать лишних движений там, где это никому не нужно.
Спасибо, было интересно. А чем не устраивает встроенная в Explorer сортировка? Тоже имею кучу всего в Downloads и по работе периодически приходится что-то оттуда вытаскивать, но для моих целей этого более чем достаточно:
Ещё интересный прикол, если в момент оплаты (после ввода одноразового кода на странице эквайринга) переключиться на другое приложение, а на карте нет средств (по ошибке не ту карту выбрал) — заказ зависает в непонятном состоянии, тоже решается только через саппорт. Ни отменить, ни оплатить повторно через приложение нельзя.
Очень круто, но если в вашей платформе создать заказ с промокодом, а ресторан его отменит — промокод сгорает, и иначе как через саппорт его не вернуть. Бывает чаще, чем хотелось бы. Лучше расскажите как вы оперативно фиксите баги :)
Откуда дровишки? Насколько я понимаю автомат считается корейским, но лицензию на него они купили у китайской компании Norinco, которая, в свою очередь, разработала его на базе АК-74.
Скорее всего примерно тем же боком, что и китайские танкостроители :) Всё-таки линейка называется Type а не АК, может быть кроме названия ещё что-нибудь поменяли.
Если мне не изменяет память — были как минимум пистолет и винтовка, однако они кроме объёма магазина ничем особо не выделялись, плюс надёжность была не на высшем уровне. Для повседневного прохождения в игре есть масса более эффективных вариантов от H&K :)
Каждому инструменту — своё применение.
Как-то раз помогал сыну маминой подруги парсить набор валидных объявлений переменных одним регулярным выражением (на подмножестве C, C#, Pascal — там потом ещё его друзья подтянулись) с поддержкой массивов и т.п. Регулярка должна была распознавать валидный код ровно до того места, где есть ошибка (если есть). Дичь конечно, но преподаватель у них вот так захотел. Вот там итоговое выражение получалось в экран размером, со всякими backtracking'ами и прочими прелестями. Компоновал итоговое выражение из более простых, иначе никак в такой ситуации. Для такой задачи на самом деле использовать регулярные выражения — бред, никто в здравом уме делать так не будет, для этого есть лексические и синтаксические анализаторы. Бедные студенты, мне было их искренне жаль.
Как верно подмечено выше, если у вас настолько сложный парсинг, что нужно компоновать выражения и/или использовать какие-то билдеры — скорее всего другой инструмент подойдёт лучше для этой задачи. И наоборот, если есть массив данных попроще — таких как номер телефона или email — обычные регулярные выражения подойдут как нельзя лучше, и никаких билдеров не нужно.
Когда-то смотрел Сипмпсонов в оригинале как раз для цели изучения разговорного языка, несколько сезонов смотришь с субтитрами, потом отключаешь. Что-то не понял — отмотал назад, включил субтитры, прочитал. Конечно на одних сериалах далеко не уедешь, но для восприятия на слух отличная тренировка.
Каждому инструменту — своё применение. Уверен что в каких-то предметных областях больше подходит один принцип, в других — другой. Главное на первоначальном этапе определиться, как будет удобнее, и делать именно так.
В защиту «стекового» принципа могу сказать, что часто бывает такое, что, например, все вью-модели (или контроллеры, или сервисы, что угодно) могут использовать какую-то общую функциональность, которая больше нигде не нужна. В «стековом» варианте вы можете для этого сделать какой-нибудь internal класс, который больше нигде не светится. В вашем же подходе придётся делать ещё одну отдельную сборку (ох уж этот Common) и напихивать всё туда, и скорее всего туда рано или поздно в одну кучу свалится всё — какая-то исключительно View-related функциональность, какая-то исключительно ViewModel-related, потом кто-нибудь положит туда методы расширения для десериализации (ну а чо, коммон же) и понеслась.
А как же фенотропил? Ноопепт рабочий, но по сравнению с фенотропилом - витаминки :) Вообще конечно с такими вещами нужно быть очень осторожным.
Да, наверное в ваших словах есть доля правды. Однако мало просто пахать, надо пахать в нужном, правильном направлении, и тогда будут какие-то результаты.
Вот человек определился, в каком направлении, и усиленно начал пахать. Результат налицо :)
Скажем так, из круга знакомых у меня есть несколько примеров, как люди, не обладая вообще никакой гениальностью, исключительно упорным трудом, начиная со школьной скамьи, добивались впечатляющих результатов. И наоборот, будь ты хоть трижды гением, если сидишь на попе ровно и никуда не двигаешься - никуда и не придёшь.
А как же whole number, это к какой категории относится?
Гений - 99% пота, как говорил Эдисон. Очень круто что человек смог собрать волю в кулак, и зарешать необходимые пункты для получения такой визы. Было бы желание, как говорится.
Спасибо, раскрыто много интересных моментов, про которые обычно никто не пишет.
Тут пусть каждый сам за себя отвечает, я лично говорю, особенно когда что-то не получается xD
1. Низкоуровневая структура, представляющая собой отображение какой-то структуры в памяти и/или в файле (пример — структуры в WINAPI). Ни геттеры, ни сеттеры там никому не нужны (хотя их и можно было бы добавить)
2. Класс, реализующий какую-то высокоуровневую логику, напрямую не маппящийся в память и/или в файл — здесь скорее всего возникнет необходимость инкапсулировать какую-то логику, могут появиться get-only property (и, не дай бог, set-only), логика которых может быть (а может и не быть) чуть-чуть сложнее, чем return _value. Ничего плохого в этом нет, интерфейс отдельно, реализация отдельно.
Таким образом, нельзя на 100% сказать, что геттеры / сеттеры зло — разумный программист будет добавлять их там, где они имеют смысл, и не будет делать лишних движений там, где это никому не нужно.
Как-то раз помогал сыну маминой подруги парсить набор валидных объявлений переменных одним регулярным выражением (на подмножестве C, C#, Pascal — там потом ещё его друзья подтянулись) с поддержкой массивов и т.п. Регулярка должна была распознавать валидный код ровно до того места, где есть ошибка (если есть). Дичь конечно, но преподаватель у них вот так захотел. Вот там итоговое выражение получалось в экран размером, со всякими backtracking'ами и прочими прелестями. Компоновал итоговое выражение из более простых, иначе никак в такой ситуации. Для такой задачи на самом деле использовать регулярные выражения — бред, никто в здравом уме делать так не будет, для этого есть лексические и синтаксические анализаторы. Бедные студенты, мне было их искренне жаль.
Как верно подмечено выше, если у вас настолько сложный парсинг, что нужно компоновать выражения и/или использовать какие-то билдеры — скорее всего другой инструмент подойдёт лучше для этой задачи. И наоборот, если есть массив данных попроще — таких как номер телефона или email — обычные регулярные выражения подойдут как нельзя лучше, и никаких билдеров не нужно.
В защиту «стекового» принципа могу сказать, что часто бывает такое, что, например, все вью-модели (или контроллеры, или сервисы, что угодно) могут использовать какую-то общую функциональность, которая больше нигде не нужна. В «стековом» варианте вы можете для этого сделать какой-нибудь internal класс, который больше нигде не светится. В вашем же подходе придётся делать ещё одну отдельную сборку (ох уж этот Common) и напихивать всё туда, и скорее всего туда рано или поздно в одну кучу свалится всё — какая-то исключительно View-related функциональность, какая-то исключительно ViewModel-related, потом кто-нибудь положит туда методы расширения для десериализации (ну а чо, коммон же) и понеслась.