Comments 21
бесит, когда код пишут паттернами, бездумно, просто потому что они есть, потому что так «правильно», и вместо одной строчки кода у вас тоже строчка + новый файл с классом из десяти строкИ тут же
Не используйте публичные поля, у вас есть property и IDE пишет их за васВот когда понадобится перехватывать запись в Name, вот тогда и заменю его на property, а заранее то зачем?
А затем, что бы другому разработчику не надо было лазить в ваш код.Написали название с типом и Ctrl+Shift+C, все готово. Вам, что жалко?
Про паттерны, я все таки про что-то более крупное, мне не приходило в голову, что пропертю можно обозвать паттерном, хотя наверное можно.
Чем «свойство» спасёт стороннего разработчика от необходимости залазить в ваш код? Разве что у вас VCL-компонент, а свойство published, и тогда его можно настроить из IDE, но в примере это не так.
Я подумал, почему же все таки свойства, и понял вот что:
В отладке это действительно важно, и это частая ситуация, когда вам нужно посмотреть, где происходит присвоение. Под "залазит в код" я имел ввиду его изменение. Сторонний, очень условно, это ваш коллега, который использует, но не пишет, эту библиотеку.
Вот о чем я не написал, не здесь, ни в посте, так это о единообразии. Может быть, это вкусовщина, или даже мания, но меня бесит когда его нет. Когда в одном месте свойства, в другом поля. Или хуже того в одном классе и то и другое. Может быть это мое личное, но не порядочек.
Есть все таки семантическая разница, между полем и свойством. Чисто с технической точки зрения ее нет (если
property Name: string read FName write FName), но она как суслик - есть.
Под «залазит в код» я имел ввиду его изменение. Сторонний, очень условно, это ваш коллега, который использует, но не пишет, эту библиотекуВот это надо раскрыть… Что меняется для «коллеги, который пользуется библиотекой» при введении свойств?
Я понимаю манию на свойства в java/.net, там это объясняется тем, что библиотеки ORM или сериализации создают служебные прокси-классы — наследники ваших классов, и могут перекрыть геттеры/сеттеры, чтобы добавить нужное поведение (в java все методы по умолчанию виртальные). Но в Delphi-то зачем?
В дельфи разве нет брекпоинта на изменение переменной или поля? Точно?
и 3. Вы здесь противоречите самому себе. Если есть разница между полем и свойством - то и надо писать поля (закрытые или открытые) и только в НЕКОТОРЫХ случаях - свойства. Только когда нужно. А не писать единообразно и поля и свойства в виде пропертей. Нельзя "единообразно" писать, потому что да, между полем и свойством (и даже между приватным полем и публичным полей) - есть разница.
Так лишние строки из ниоткуда появляются, и какая от них польза, непонятно.
Вам за экономию строк платят? Нет? Тогда не стоит заниматься ерундой.
Вот когда понадобится перехватывать запись в Name, вот тогда и заменю его на property, а заранее то зачем?
Нет ни одной причины держать поле публичным кроме «прадед моего прадеда писал так». Нужно будет отлавливать запись — добавите в декларацию свойства сеттер вместо имени поля.
read FName write SetName?).писать же
property Name: string read FName write FName;
кстати почему запись хочет ловить, а чтение не хочет
При отладке какого-нибудь бага нередко возникает ситуация, когда в свойстве оказывается какое-то неожиданное значение, и в попытке узнать откуда оно там берётся — ставится точка останова на сеттере свойства.
Прадеды так не писали, мне кажется. Тотальное закрытие полей и гетеросеттеризация - относительно новый тренд.
Начал читать. Протёр глаза. Проверил календарь. Декабрь 2022 года, точно. Но ощущение, что читаю пост с sql.ru откуда-то из 2002, никак не проходит. Такой древностью повеяло, что аж страшно.
Автор, батенька, вы напрочь сварились в собственном соку. За то время, пока вы (судя по тону, в основном в одно лицо) разрабатывали ваш продукт, индустрия ушла уже очень далеко.
Я и сам не то что бы молод, и если бы я продолжал разрабатывать свой первый относительно успешный продукт с 2001 года по сей день, вероятно, написал бы что-то в таком же духе. Но я с тех пор трижды поменял технологический стек, а предметную область и того больше раз. Было тяжко каждый раз, но зато не застрял в прошлом. (А относительно успешным продуктом пускай лучше занимается молодёжь, уже без моего участия.)
Да просто чтение чужого кода, написанного с новым синтаксическим сахарком в очередном модном молодёжном стиле, здорово поднимает уровень осознанности того, что ты делаешь. Особенно хорошо, если этот чужой код на каком-то новом для тебя языке с другими акцентами.
Не тащите на себе это вечное легаси, в нём не будет счастья.
Вам со стороны виднее, спорить не буду. По фактической стороне:
Нет, я пишу не один, совсем даже не один. Вот этот рефакторинг (только рефакторинг) делает аж цельных три человека. Просто на мне большая нагрузка, это да. А в целом, над продуктом работает несколько десятков человек, и это только разработчиков, не считая тестирования и прочего...
Поверьте, я менял технологический стек, и у меня в багаже много всего разного, и очень древнего, и не слишком, в том числе и модного, молодежного. Тут вы ошиблись.
Не так всё однозначно.. Вы можете привести пример языка, который строит нативный exe в считанные секунды? Пишу в основном под десктоп, и это прям боль, ждать когда сборщик соизволит закончить работу. Что ява, что котлин, что qt, что электрон, все тормознутые донельзя. Плюс размер бинарников какой-то умопомрачительный.
А родная старая делфа - нажмёшь F9, пара секунд и форма на экране. Как же мне этого не хватает.
новый файл с классом из десяти строк
Это лучше, чем unit-братская могила на 10 000 строк, в которую напихано всё подряд.
Но при чём тут «паттерны»?
Если употребление паттерна улучшает качество кода, то его использование оправдано. А сколько там строк совершенно не важно.
По крайней мере у меня не зашли всякие там «Extract interface», ни в одной IDE, которой я пользовался.
Можно подумать, будто для Delphi много IDE.
Начните с «Extract Method», а там втянетесь.
Для меня самый удобный рефакторинг – Ctrl+R/Ctrl+H, Replace мощная штука, только регулярки я пишу со скрипом, ну никак они мне не даются.
Тупиковый путь, чреватый ошибками.
Говорят, у IntelliJ с рефакторингами хорошо
В IDEA он божественен.
У тебя не тестированная версия Delphi! Проверь каку!
Директиву $MESSAGE FATAL завезли ещё в каком-то дремучем году.
Нет никаких причин косплеить Turbo Pascal for DOS.
Result := Fields[I];
Exit;Можно просто Exit(Fields[I]);
Про паттерны, я же не написал что не надо их использовать. Весь пост про умеренность.
Рефактоинги - я писал: пользуйтесь. У меня, лично, не зашло. Про Replace спорить не буду, сомнительный путь, но работает иногда.
Про MESSAGE FATAL не знал, спасибо!
Exit(Result) - это если у вас, семерки нет в списке совместимостей ;)
Зачем нужно публичные поля загонять в приватные и делать проперти-геттеры-сеттеры? Что это дает? Ну, кроме мусора, конечно? Какие тайные знания появляются, какой функционал у системы появляется? Проперти нужны, если при при присваивании имеются действия, которые необходимо выполнять при присваивании. Много у вас таких филдов в приложении? Прям все? В шарпе взяли моду, все абсолютно поля делать приватными и геттеросеттеры плодить. В джаве - хоть и можно делать публичные поля, но джава-общество принципиально не согласно не заниматься ахинеей. При этом эти бессмысленные и бесполезные геттеросеттеры настолько всех задолбали, что даже придумали ломбок, который сам делает геттеросеттеры. И к чему все вылилось? Фактически, все публичные поля, которые должны быть по-хорошему объявлены публик (и не париться), и являются публик, но через жопу - через ломбок.
Сплошное применение геттеросеттеров вредит структуре проекта. Нарушает явное разделение полей на закрытые от внешнего мира и открытые. Они все - приватные, но НЕКОТОРЫЕ - с геттерами и/или сеттерами. Вместо того, чтобы просто увидеть "публик", надо анализировать взглядом, есть у него геттеросеттеры или нет. Ладно, если ломбок есть, там по собаке можно определить. А если через обычные методы? Шариться по коду?
Чем мне нравился Дельфи - так это тем, что там можно было делать публичные поля, и там где надо - приватные. И вы тоже тащите в Дельфи всю эту гомосятину с гетеросеттерами. "Рефакторите" хороший прямой код. Фу.
Вот уж не думал, что тема свойств будет так обсуждаться. Проходная совершенно. Забавно.
Как отрефакторить 2.5 млн строк кода