Программирование мобильных телефонов на Java


Программирование мобильных телефонов

  • Введение
  • Глава 1. Устройство мобильных телефонов
  • Глава 2. Платформа Java 2 Micro Edition
  • Глава 3. Средства разработки мобильных приложений
  • Глава 4. Телефонные эмуляторы
  • Глава 5. Механизм работы приложений Java 2 ME
  • Глава 6. Классы пользовательского интерфейса
  • Глава 7. Программирование графики
  • Глава 8. Техника создания игр
  • Глава 9. Мобильная мультимедиа-библиотека
  • Заключение
  • Приложение 1. Основы языка Java
  • Приложение 2. Справочник по Java 2 Micro Edition

     

    Программирование на Java

  • Введение
  • Глава 1. Встроенные типы данных, операции над ними
  • Глава 2. Объектно-ориентированное программирование в Java
  • Глава 3. Пакеты и интерфейсы
  • Глава 4. Классы-оболочки
  • Глава 5. Работа со строками
  • Глава 6. Классы-коллекции
  • Глава 7. Классы-утилиты
  • Глава 8. Принципы построения графического интерфейса
  • Глава 9. Графические примитивы
  • Глава 10. Основные компоненты
  • Глава 11. Размещение компонентов
  • Глава 12. Обработка событий
  • Глава 13. Создание меню
  • Глава 14. Апплеты
  • Глава 15. Изображения и звук
  • Глава 16. Обработка исключительных ситуаций
  • Глава 17. Подпроцессы
  • Глава 18. Потоки ввода/вывода
  • Глава 19. Сетевые средства Java
  • Приложение. Развитие Java

  • 

    3fb01dc2


     

     

    Design patterns

    В математике давно выработаны общие методы решения типовых задач. Доказательство теоремы начинается со слов: "Проведем доказательство от противного" или: "Докажем это методом математической индукции", и вы сразу представляете себе схему доказательства, его путь становится вам понятен.

    Нет ли подобных общих методов в программировании? Есть.

    Допустим, вам поручили автоматизировать метеорологическую станцию. Информация от различных датчиков или, другими словами, контроллеров температуры, давления, влажности, скорости ветра поступает в цифровом виде в компьютер. Там она обрабатывается: вычисляются усредненные значения по регионам, на основе многодневных наблюдений делается прогноз на завтра, т. е. создается модель метеорологической картины местности. Затем прогноз выводится по разным каналам: на экран монитора, самописец, передается по сети. Он представляется в разных видах, колонках чисел, графиках, диаграммах.

    Естественно спроектировать такую автоматизированную систему из трех частей.

    • Первая часть, назовем ее Контроллером (controller), принимает сведения от датчиков и преобразует их в какую-то единообразную форму, пригодную для дальнейшей обработки, например, приводит к одному масштабу. При этом для каждого датчика надо написать свой модуль, на вход которого поступают сигналы конкретного устройства, а на выходе образуется унифицированная информация.
    •  Вторая часть, назовем ее Моделью (model), принимает эту унифицированную информацию от Контроллера, ничего не зная о датчике и не интересуясь тем, от какого именно датчика она поступила, и преобразует ее по своим алгоритмам опять-таки к какому-то однообразному виду, например, к последовательности чисел.
    • Третья часть системы, Вид (view), непосредственно связана с устройствами вывода и преобразует поступившую от Модели последовательность чисел в график, диаграмму или пакет для отправки по сети. Для каждого устройства придется написать свой модуль, учитывающий особенности именно этого устройства.

    В чем удобство такой трехзвенной схемы? Она очень гибка. Замена одного датчика приведет к замене только одного модуля в Контроллере, ни Модель, ни Вид этого даже не заметят. Надо представить прогноз в каком-то новом виде, например, для телевидения? Пожалуйста, достаточно написать один модуль и вставить его в Вид. Изменился алгоритм обработки данных? Меняем Модель.

    Эта схема разработана еще в 80-х годах прошлого столетия [То есть XX века. — Ред. ] в языке Smalltalk и получила название MVG (Model-View-Controller). Оказалось, что она применима во многих областях, далеких от метеорологии, всюду, где удобно отделить обработку от ввода и вывода информации.

    Сбор информации часто организуется так. На экране дисплея открывается поле ввода, в которое вы набиваете сведения, допустим, фамилии в произвольном порядке, а в соседнем поле вывода отображается обработанная информация, например, список фамилий по алфавиту. Будьте уверены, что эта программа организована по схеме МУС. Контроллером служит поле ввода, Видом — поле вывода, а Моделью — метод сортировки фамилий. В третьей части книги мы рассмотрим примеры реализации этой схемы.

    К середине 90-х годов накопилось много подобных схем. В них сконцентрирован многолетний опыт тысяч программистов, выражены наилучшие решения типовых задач.

    Вот, пожалуй, самая простая из этих схем. Надо написать класс, у которого можно создать только один экземпляр, но этим экземпляром должны пользоваться объекты других классов. Для решения этой задачи предложена схема Singleton, представленная в листинге 3.5.

    Листинг 3.5. Схема Singleton

    final class Singleton{

      private static Singleton s = new Singleton(0); 

      private int k;

      private Singleton(int i){k = i;} 

      public static Singleton getReference()(return s;} 

      public int getValue(){return k;} 

      public void setValue(int i){k = i;} 

    public class SingletonTest {

      public static void main(String[] args){ 

        Singleton ref = Singleton.getReference(); 

        System.out.println(ref.getValue()); 

        ref.setValue(ref.getValue() + 5); 

        System.out.println(ref.getValue()); 

      } 

    }

    Класс singleton окончательный — его нельзя расширить. Его конструктор закрытый — никакой метод не может создать экземпляр этого класса. Единственный экземпляр s класса singleton — статический, он создается внутри класса. Зато любой объект может получить ссылку на экземпляр методом getReference () , Изменить состояние экземпляра s методом s etValue() или просмотреть его текущее состояние методом getValue() .

    Это только схема — класс singleton надо еще наполнить полезным содержимым, но идея выражена ясно и полностью.

    Схемы проектирования были систематизированы и изложены в книге [7]. Четыре автора этой книги были прозваны "бандой четырех" (Gang of Four), а книга, коротко, "GoF". Схемы обработки информации получили название "Design Patterns". Русский термин еще не устоялся. Говорят о "шаблонах", "схемах разработки", "шаблонах проектирования".

    В книге GoF описаны 23 шаблона, разбитые на три группы:

    1. Шаблоны создания объектов: Factory, Abstract Factory, Singleton, Builder, Prototype.

    2. Шаблоны структуры объектов: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy.

    3. Шаблоны поведения объектов: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template, Visitor.

    Описания даны, в основном, на языке C++. В книге [8] те же шаблоны представлены на языке Java. Той же теме посвящено электронное издание [9]. В книге [10] подробно обсуждаются вопросы разработки систем на основе design patterns.

    Мы, к сожалению, не можем разобрать подробно design patterns в этой кни-те. Но каждый программист начала XXI века должен их знать. Описание многих разработок начинается словами: "Проект решен на основе шаблона", и структура проекта сразу становится ясна для всякого, знакомого с design patterns.

    По ходу книги мы будем указывать, на основе какого шаблона сделана та или иная разработка.

     

    -
    



    Copyright © vzlom-1.ru 2020-2021