Абстрактный класс не является паттерном. Абстрактный класс, это синтаксическая возможность языка объявить некий служебный класс (который не может инстанциироваться), который может быть воткнут в иерархию между интерфейсом и полной его, интерфейса, реализацией, дабы застолбить базовую реализацию некоторых методов. Может служить заменой интерфейсу (и служит, скажем, в с++). Никакого отношения к композиции он не имеет. Выбор между наследованием и композицией это немножко из другой оперы.
Такое чувство, что совсем молодой иностранный специалист написал свои первичные соображения после относительно непродолжительного использования Java. Абстрактные классы оказывается есть вещь второй важности. Как и наследование с generics. :)
А наш человек старательно перевёл это, ибо полагает, что всё что пишет иностранец — есть круто по определению. Как при Петре 1. Этот молодой иностранный парень имеет право писать всё что хочет в своём блоге. Но к чему это распространять?
Если кто-то считает, что оригинальный автор уже силён в разработке, откройте по ссылке его блог и ужаснитесь как это всё забавно выглядит. :)
Вот бы вы ещё с помощью какого-нибудь модного облачного инструмента сделали картинки меньше трёх мегабайт размером (штуки три, как минимум, несколько тяжеловаты).
А должен был следить? За всем не уследишь. Потому и открыл Вашу заметку. Видимо ожидая увидеть вначале абзац примерно с вот тем, что вы написали только что выше. И далее уже относительное сравнение с другими ноутами. От того что вы перечислили кучу технологий, якобы доступных с C7, увы я много нового не узнал. Они и без C7 доступны.
Похоже, автор написал заголовок и забыл его. Мысль его растеклась вширь. И, сев на видимо любимого конька, автор стал перечислять всякие сервисы, мессенджеры, расширения файлов, реализации Линукса, производителей ноутбуков и т.д которые он знает. Количество упоминаний технологий/инструментов на единицу печатной площади получилось велико. Разумеется, автор со всем этим ворохом плотно и ежедневно работает.
Не понятно одно — каким боком тут некий Acer C7? Видимо типа — и вот вся эта свалка шевелится на Acer C7. Дивитесь люди. :)
Так прямо в Java доступны все методы, что были в том скрипте. FXML — это альтернативный вариант описания. Как бы красива фишка не была, но если она избыточна по сути и требует времени на изучение, то она является тормозом. Зачем Java разработчику использовать некий, пусть и красивый, скрипт, если он может использовать не менее элегантный язык Java?
Так ведь они и не обязаны там быть. Одни и те же вещи можно делать разными способами. В JavaFX стилизация делается иначе. Просто JavaFX появилась позже чем WPF и у людей возникает соблазн искать в новой библиотеке полный технологический аналог уже знакомого им подхода. Не найдя его, они грят, что у-у-у… как всё запущено, надо закопать и тд и тп. Обычная эмоциональная реакция. А по сути, в JavaFX можно всё что угодно стилизовать через CSS. И это гораздо привычнее для многих.
Она не умерла, а довольно быстро развивается. Был просто резкий переход после версии 1.3. До версии 1.3 включительно, использовался свой скриптовой язык для описания сцены. Когда Oracle купил Sun, они сделали резкий шаг, убрали этот язык и сказали что есть Java, к чему там ещё скриптинг таскать? И версия JavaFX 2 вышла уже без него, интенсивно развивается и уже стала частью JDK (по сути это замена Swing). И кстати, не очень корректно утверждение, что она слабее SilverLight. Я бы сказал, что корректнее сравнивать c WPF, И там уже решать. Предлагающие её закопать или её никогда не видели или имеют некое свое внутреннее эмоциональное предубеждение, неимеющее ничего общего с технической стороной вопроса.
Я действительно не очень въезжаю о каких мифических шаблонах идёт речь.
Что бы стилизовать приложение/контрол существует много способов. Разумеется, что строя сцену вы можете указывать разные значения свойств и действий на события как параметры инициализации контролов или же создавая анонимные классы для более сложного поведения.
Далее, не меняя класса, вы можете стилизовать сцену, корневой узел, любой из узлов или все нужные типы узлов (скажем, радиокнопки) путём указания им собственных CSS. Поддерживается версия CSS 2.2 с элементами 3.0 и собственными расширениями. Скажем вы можете указать параметр shape для контрола как SVG цепочку рисовки и контрол будет перерисован как вы хотите.
Для списков элементов существует возможность описать свою фабрику, которая будет предоставлять ваш собственный Cell для рисовки в данном списковом элементе.
Если этого мало, то вы можете просто написать свой класс отвечающий за Skin контрола и воткнуть его туда. Вся рисовка делегирована в этот класс.
Если вам мало обработчиков событий, вы можете полностью написать свое поведение контрола путём реализации своего класса Behavior. Эта часть будет более открытой в Java 8.
Если вам нужна анимация, то вы можете создать несколько объектов называемых TimeLine, которые описывают как будут меняться кадры и привязать их к свойствам любых узлов сцены. Они будут в своём потоке анимировать контролы.
Можно связать свойства в цепочки, тем самым также обеспечивая зависимость свойств одних контролов от значения других. Упрощённо говоря, поменялось значение, автматом поменялся цвет и положение.
Насчёт SO — наверное соглашусь. Трудно сказать как и почему они вдруг закрыли тут и не закрыли там. Возможно, действительно модераторы не успевают.
По поводу остального… Ну, вы вываливаете фейерверк довольно общих вопросов, ответ на каждый из которых это маленькая лекция. Что-то типа — ну а как ваша машина поедет, как работает ваш двигатель, как вы гарантируете работу тормозов, где вы добываете топливо…
Контролы я размещаю не просто в элементе дерева, а в элементе дерева который умеет распологать контролы в пространстве по умному. Это так называемые Layout панели. Их несколько разных родных и появляются новые сторонние в силу открытости. Они и будут отвечать за правильное расположение.
Взаимодействовать между собой контролы могут как угодно. Начиная от стандартной передачи ссылок друг на друга и заканчивая связыванием их свойств.
Байндинг на данные я могу декларативно описать в FXML.
С внешними источниками данных я могу взаимодействовать сотней разных способов. Например создать модель, которая будет содержать поля Properties и они будут автоматически связаны со свойствами контролов.
Беспредметный какой-то разговор.
Я пока не вижу никакого такого дефекта, который позволил бы назвать JavaFX огрызком по сравнению с WPF.
Да, верно. SO закрывает дискуссию, если вопрос не попадает в формат Да/Нет. Но, на самом деле SO хитрый. :) Он не против того, что бы люди пообсуждали и такие вопросы. И закрывают они их только если вопрос стал реально неактуален.
Вот гляньте на вашу ссылку. Судя по первому ответу (январь 2010) и до закрытия, прошло почти три года! Почти три года SO позволял обсуждать этот вопрос. :)
По поводу Вашей задачи… я не очень понял проблему. В JavaFX свойства контролов объявлены как собственный тип Property (IntegerProperty, DoubleProperty...). Все они реализуют ObservableValue интерфейс и байндинг с другими свойствами. То есть я могу прицепиться к событиям изменения свойства явно (если мне нужна сложная обработка) или связать его с другим свойством, если условие простое (типа навёл мышь — поменялся цвет)
Другими словами, не вижу никакой проблемы реализовать ваш сценарий стандартными средствами. Возможно будут нюансы, тружно сказать. Вещь пока новая. Сам разбираюсь неспешно. Да и развивается очень быстро.
Вы действительно очень ленивы. Ибо даже не удосужились прочитать, что ваша ссылка на StackOverflow уже неактуальна и closed as not constructive. Она была создана в 2010 году до появления JavaFX 2 и сейчас полностью устарела. Все ваши пункты давно закрыты.
А почитав детальнее, вы возможно бы в чём-то и свой велосипед не изобретали бы. :)
По правде говоря, я не считаю, что они в одной весовой категории. Я считаю, что JavaFX уже стала на голову выше. С момента появления JavaFX 2. Я, разумеется, могу привести и доводы, но пока хотелось бы несколько Ваших.
Развёрнутый разбор не нужен. Просто тройка пунктов вида — JavaFX есть огрызок потому, что там нет/плохо сделано таких вещей как…… которые крайне важны и до совершенства отточены в WPF.
Старательно прошёлся и проминусовал неприятные мне топики и карму. Так и не смог задействовать весь ресурс висящий на моей бомбе. Редко я это делал. Нда. Но вот и Картунова проминусовал. И других Милководов. Чёт как-то до этого не делал. По привычке ожидал, что несовпадающее со мной мнение, ещё не повод, что бы оценивать человека. Пусть даже и виртуально. Но селя-ви… :-)
ЗЫ: И даже yegorg наконец то поставил минус. Держался до последнего. Ждал. :-)
Такое чувство, что совсем молодой иностранный специалист написал свои первичные соображения после относительно непродолжительного использования Java. Абстрактные классы оказывается есть вещь второй важности. Как и наследование с generics. :)
А наш человек старательно перевёл это, ибо полагает, что всё что пишет иностранец — есть круто по определению. Как при Петре 1. Этот молодой иностранный парень имеет право писать всё что хочет в своём блоге. Но к чему это распространять?
Если кто-то считает, что оригинальный автор уже силён в разработке, откройте по ссылке его блог и ужаснитесь как это всё забавно выглядит. :)
Не понятно одно — каким боком тут некий Acer C7? Видимо типа — и вот вся эта свалка шевелится на Acer C7. Дивитесь люди. :)
Что бы стилизовать приложение/контрол существует много способов. Разумеется, что строя сцену вы можете указывать разные значения свойств и действий на события как параметры инициализации контролов или же создавая анонимные классы для более сложного поведения.
Далее, не меняя класса, вы можете стилизовать сцену, корневой узел, любой из узлов или все нужные типы узлов (скажем, радиокнопки) путём указания им собственных CSS. Поддерживается версия CSS 2.2 с элементами 3.0 и собственными расширениями. Скажем вы можете указать параметр shape для контрола как SVG цепочку рисовки и контрол будет перерисован как вы хотите.
Для списков элементов существует возможность описать свою фабрику, которая будет предоставлять ваш собственный Cell для рисовки в данном списковом элементе.
Если этого мало, то вы можете просто написать свой класс отвечающий за Skin контрола и воткнуть его туда. Вся рисовка делегирована в этот класс.
Если вам мало обработчиков событий, вы можете полностью написать свое поведение контрола путём реализации своего класса Behavior. Эта часть будет более открытой в Java 8.
Если вам нужна анимация, то вы можете создать несколько объектов называемых TimeLine, которые описывают как будут меняться кадры и привязать их к свойствам любых узлов сцены. Они будут в своём потоке анимировать контролы.
Можно связать свойства в цепочки, тем самым также обеспечивая зависимость свойств одних контролов от значения других. Упрощённо говоря, поменялось значение, автматом поменялся цвет и положение.
Ну вот навскидку варианты…
Нашёл тут на SO вопрос человека из мира WPF. Он также искал какие-то templates и не мог понять, что подходы есть разные. Там также есть развернутый ответ:
stackoverflow.com/questions/12383533/javafx-2-0-style-template-existing-control
По поводу остального… Ну, вы вываливаете фейерверк довольно общих вопросов, ответ на каждый из которых это маленькая лекция. Что-то типа — ну а как ваша машина поедет, как работает ваш двигатель, как вы гарантируете работу тормозов, где вы добываете топливо…
Контролы я размещаю не просто в элементе дерева, а в элементе дерева который умеет распологать контролы в пространстве по умному. Это так называемые Layout панели. Их несколько разных родных и появляются новые сторонние в силу открытости. Они и будут отвечать за правильное расположение.
Взаимодействовать между собой контролы могут как угодно. Начиная от стандартной передачи ссылок друг на друга и заканчивая связыванием их свойств.
Байндинг на данные я могу декларативно описать в FXML.
С внешними источниками данных я могу взаимодействовать сотней разных способов. Например создать модель, которая будет содержать поля Properties и они будут автоматически связаны со свойствами контролов.
Беспредметный какой-то разговор.
Я пока не вижу никакого такого дефекта, который позволил бы назвать JavaFX огрызком по сравнению с WPF.
Вот гляньте на вашу ссылку. Судя по первому ответу (январь 2010) и до закрытия, прошло почти три года! Почти три года SO позволял обсуждать этот вопрос. :)
По поводу Вашей задачи… я не очень понял проблему. В JavaFX свойства контролов объявлены как собственный тип Property (IntegerProperty, DoubleProperty...). Все они реализуют ObservableValue интерфейс и байндинг с другими свойствами. То есть я могу прицепиться к событиям изменения свойства явно (если мне нужна сложная обработка) или связать его с другим свойством, если условие простое (типа навёл мышь — поменялся цвет)
Другими словами, не вижу никакой проблемы реализовать ваш сценарий стандартными средствами. Возможно будут нюансы, тружно сказать. Вещь пока новая. Сам разбираюсь неспешно. Да и развивается очень быстро.
А почитав детальнее, вы возможно бы в чём-то и свой велосипед не изобретали бы. :)
Развёрнутый разбор не нужен. Просто тройка пунктов вида — JavaFX есть огрызок потому, что там нет/плохо сделано таких вещей как…… которые крайне важны и до совершенства отточены в WPF.
Не могли бы вы написать несколько весомых доводов/пояснений, почему JavaFX является куцым огрызком в сравнении с WPF?
sourcemaking.com/design_patterns/strategy
ЗЫ: И даже yegorg наконец то поставил минус. Держался до последнего. Ждал. :-)