3.4Kпросмотров
23 июля 2024 г.
📷 ФотоScore: 3.7K
В Java Swing есть много разных способов размещать компоненты внутри окошек. В давние стародавние времена я выбрал некий GroupLayout, который давал максимальный контроль. Потом я узнал, что его не рекомендуется использовать вручную и он вообще для этих редакторов, где мышкой интерфейс набрасывают, ну да ладно. До сих пор использую его, но там, чтобы указать как именно себя должен вести компонент, надо указать в правильном порядке комбинацию из трех параметров. Логика какая-то наверняка в этом всем есть, но я никогда ее не осознаю и я никак не могу понять по этим параметрам как компонент будет отображаться: растянутым на всю ширину(высоту), средненько или будет занимать минимальную ширину(высоту). Поэтому давно еще создал методы-расширения, чтобы было более понятно. addComponentShrink - этот будет ужат до минимума. addComponentNotResize - этот будет нормально отображаться, но не будет растягиваться. Теперь решил подчистить весь код, чтобы не осталось ни одного вызова с этими тремя параметрами. Вывод 1: далеко не всегда понятно, что код, который вот щас по гайдам из интернета сделан, будет непонятен при прочтении в будущем. Надо постоянно следить и скрывать такую непонятную логику в методах с нормальным названием. На картинке видна разница. Вывод 2: методы-расширения весьма полезны в таких вот Fluent-вызовах методов, в которых return this. Поэтому я все больше и больше начинаю уважать ларавелевский ::macro(), который позволяет делать тоже самое в PHP, в котором нет поддержки методов-расширений.