Ну вот об этом и речь. Возьмем условный б/у или заводской вел, на нем как правило стоит какая-то ОЕМная кенда на стальном корде, древние камеры, получаем по 1.5 кг. веса резины и камеры, это реальные цифры на 27.5 веле с резиной 1.9 и шире. При переходе на новую резину, большинство кантрийных покрышек идут весом 700-800 г. (те же айконы), заливаешь туда пусть даже 150 мл. гермета, и получаешь неплохой сброс по весу. Ясное дело, что если до этого стояли даже гейлайт покры пусть и на металическом корде, по весу столько сбросить не получится.
Ну я б не сказал что вес на колесах - это бонус. Колесо это маховик, а резина как раз находится на его краю, и для разгона надо все это дело проворачивать. Если бы мы говорили за какой-нибудь вынос/седло/флягодержатель, то про вес можно было бы сказать что это бонус. А на колесах вес это чуть ли не ключевой фактор.
Если есть условный б/у вел, и хочется улучшить ходовые характеристики, то замена резины целесообразна в двух случаях: когда резина стоит не под то покрытие, по которому ездит ездок. И когда резина стоит камерно, а обода позволяют поставить бескамерно и скинуть кило с колес. В остальных случаях, я бы сказал так: мягкая накатистая и прилипчивая резина имеет мягкий компаунд, который сожрется на асфальте пока ты едешь к споту, поэтому не вижу смысла тратить за покрышку больше 30 евро на повседнев.
Например, когда это невозможно?
Ну и что от чего тут наследовать? Ору с местных экспертов.
Тут походу никто не слышал про composition over inheritance.
ТС все правильно делает, что не использует наследование. Было бы не плохо на живом примере понять, чего добивается ТС, и какая логика между тем же "Транспортным автомобилем" и "3Д-автомобилем". Если между ними нет никакой связи - можно использовать несколько отдельных классов/структур. Если между ними есть связь - то семантически, это одна и та же единица, которая имеет как логику, так и представление (3Д - например).
Полный бред. Наследование вообще уже признано тупиковой ветвью развития. Уже давно поняли, что лучше использовать механизм примесей/трейтов и встраивание (embedding).
Делается вообще не так: есть класс автомобиль, если класс двигатель, есть класс трансмиссии, есть класс кузова и т.д., все они встраиваются в автомобиль, и каждый из них взаимодействуют друг с другом. Есть паттерн bridge, через который двигатель передает мощность на колеса (мостом в данном случае выступает класс трансмиссии). И это все должно либо встраиваться друг в друга, либо быть сиблингами в иерархии. Но никак не наследоваться. Даже двигатель с турбой по сути это двигатель + турбо. Нет тут наследования. DI нужно юзать. Тогда и код будет тестируемый и поддерживаемый.
Solmyr, должно быть несколько интерфейсов, например Automotive, с методами gas, brake, turn_left, turn_right, интерфейс Display, с методом render, и так далее.
А сам класс автомобиля должен реализовывать (или нет) нужные вам интерфейсы. И принимать нужно не инстанс класса, а интерфейс, закрывающий детали реализации.
А сами свойства должны быть закрыты getterами и setterами, если их чтение/изменение предусмотрено.
Умные люди (или параноики) хранят пароли в чем-то вроде ваульта, и закрывают это лдапом или керберосом. А имея доступ к файловой системе, точно так же можно прочитать переменные окружения.
Не нужно вообще использовать в 2к20 MyISAM. А если тормозит SELECT COUNT(*), то надо подумать, нужно ли вообще вам точное количество строк, если да, то зачем? Для пагинации, или просто юзеру показать количество товаров в категории. Если для пагинации, то нужно юзать курсор и next-next пагинацию. Если для того, чтобы показать примерное количество строк в таблице, брать аппроксимизированные данные из таблицы information_schema.
О какой именно смазке речь? Производитель/модель?
- Приводишь аргументы что б/у может быть более правильным выбором.
- Тебе говорят, что у б/у устаревшие стандарты.
- Кидаешь ссылку на б/у за практически ту же цену, но с более современными стандартами.
- В ответ слышишь: "И?".
