Больше гибкости!!! И прыгающие шарики.

Прошла пара дней с тех пор,как я выпустил свою первую библиотеку. И вот, я выпускаю первое к ней обновление, и програмку “Скачущие шарики”, иллюстрирующую её применение . Если интересно, прошу под кат.

Если вы посмотрите в исходный код, то теперь там найдёте новый класс ExeptionMiscarriage.

public class ExeptionMiscarriage extends Throwable{
    private String info ="Object didn't ready";
    public ExeptionMiscarriage(String info){
        this.info =info;
    }

    public ExeptionMiscarriage() {
       
    }
    /**
     * @return the info
     */
    public String getInfo() {
        return info;
    }

    /**
     * @param info the info to set
     */
    public void setInfo(String info) {
        this.info = info;
    }
    public void addInfo(String info) {
        this.info =  this.info   info;
    }   
}

Не сложно догадаться, что это Исключение “выкидыша”. Что это значит? Теперь, если пользователь не заполнил все необходимые поля в панели создания объекта и нажал на кнопочку “ОК”, вы можете сформировать это исключение, и наполнить его информаицией. И пользователю будет выдано модальное окошко ошибки, в котором будет ваша информация.

Диалог не прекратится, а продолжит действовать, пока пользователь не введёт всю необходимую информацию для формирования вашего объекта, или же не нажмёт “Отмена”. Второе улучшение библиотеки касается расширяемости.  По ходу написания программы “Скачущие шарики”, мне понадобилось использовать мою библиотеку не совсем в стандартной ситуации. Я хотел сделать диалог выбора цвета. Панель выбора цвета существует - JColorChooser. И вот ведь незадача: я не могу сообщить её в конструктор своего диалога, так как она не является наследником FactoryPanel. Вот он, камень преткновения и проектировочный тупик. Наследовать от 2-х классов в Java нельзя. Даже, если я наследую от JColorChooser и реализую интерфейс ObjectFactory. То это не сможет явно привести к FactoryPanel во -первых :потому, что так делать нельзя. Если у нас есть:

 
class A{}
interface I{}
class B extends A,implements I{}
class С extends A,implements I{}

Мы не можем Объект класса C явно привести к B. Но, даже, если бы это было возможно-в конкретной ситуации этого сделать было бы нельзя, так как у JColorChooser нет в потомках JPanel. Но зато, у него есть JComponent. JComponent является наследником всех Swing UI элементов. Поэтому, я пересмотрел свою библиотеку и в свой диалог я буду принимать JComponent. Конечно, в целях обратной совместимости, я оставил FactoryPanel, но переименовал её в FactoryComponent. Это не вызовет проблем при разработке панели в визуальном редакторе. Вы по-прежнему, после разработки переопределяете наследника с JPanel на FactoryComponent. Но из за мухи в супе, описанной выше, такой фокус не пройдёт с JColorChooser. Поэтому, я решил, сделать ещё один конструктор в ComplexDialog. ComplexDialog(JFrame parent, Object mainpanel, String title, boolean modal); Как видите - Тип главной панели-настройщика – Object. То есть , я могу сообщить туда всё, что душе угодно. Но в самом конструкторе я проверяю:

 
        settingscomponent = (JComponent)mainpanel;
        objectFactory = (ObjectFactory)mainpanel;

Если вы скормили моему диалогу какое-то непотребство - вывалится исключение о несоответствии типов.  Вернёмся к задаче: Нам надо скормить JColorChooser в ComplexDialog. Если скормим без приправы, ComplexDialog- выплюнет исключение, как я и описывал выше. Поэтому, мы наследуем от JColorChooser и при этом реализуем интерфейс ObjectFactory.

 
    public class MyColorChoser extends JColorChooser implements complexdialog.ObjectFactory{

        @Override
        public Object getResult() throws ExeptionMiscarriage {
           return getColor();
   }

Видите, как классно! Теперь мы можем создать объект типа MyСolorСhoser и успешно скормить его моему диалогу в качестве Object. Так как JColorChooser потомок JComponent, а MyСolorСhoser ещё и реализовывает ObjectFactory- значит диалог скушает этот объект с большим удовольствием. Здесь, в папке examples/example2 ,лежит программа “Скачущие мячики” ,в которой реализованы 2 диалоговых окна моей библиотеки. Первое окно (добавления мячика) показывает, как работают исключения-выкидыши. Второе- показывает, как скормить чужие компоненты моей библиотеке. Дабы вам не было сильно скучно - в самой програмке скачут шарики, как в реальной жизни: с ускорением, вязкостью воздуха, коэффициентом упругости и прочими вкусностями. Для добавления шарика-нажмите кнопочку “Add”,она вызовет мой диалог, и вы не сможете нажать OK, пока не заполните все поля и не выберете цвет. Если вы читаете эту статью, наверно вы - программист. А ,значит , вас не испугает перспектива залезть в код и посмотреть, как добавляются шарики. Я специально, сразу кинул в цикле 20 шариков с разной начальной скоростью и прочим. Поэкспериментируйте с разным количеством шариков, динамической начальной скоростью(очень интересны получаются функциональные зависимости), меняющимися цветами, динамическим коэффициентом упругости.Попробуйте изменить вязкость среды, время обновления рассчётов, временной коэффициент- я специально создал его, чтобы при очень больших масштабах( я сбрасывал мячик с 10 километров на начальной скорости 100 метров в секунду) всё происходило немного быстрей, чем в реальной жизни. Ибо скучно. Только осторожно! Меня эта штука затянула на целый вечер, поэтому, я и пишу статью сегодня, а не вчера :-) Всем спасибо. Постараюсь радовать вас новыми интересными идеями, библиотеками, програмками и прочим. И ,конечно, до бесконечности совершенствовать библиотеку ComplexDialog.

За редакцию хочется выразить благодарность,Алисе Брыль. 

Читать дальше......