ООП « Записки программиста

6Ноя/123

Еще немного о классах

Класс - это упрощенное описание каких-нибудь реальных (чаще, правда, выдуманных) вещей.

Вот, например, точка. Единственное, что есть у точки - это её координаты в пространстве. Это её параметры.
Как задать точку на плоскости? Надо нарисовать точку и подписать её: M(1,2), т.е. точка с именем M и координатами х = 1, у = 2.
Это её "конструктор". Т.е. мы "сконструировали" конкретную точку М с конкретными координатами.

На языке Java это будет выглядеть так:

class Point {                       //общее описание точек
    private double x, y;            //параметры точки

    Point(double ax, double ay) {   //конструктор
        x = ax;
        y = ay;
    }
}

Сконструируем точку

Point M = new Point(1, 2);

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

Т.е. данная строчка работать не будет:

Point M = new Point(); //пустые параметры
//или
Point M = new Point(1); //неполные параметры

Дальше. Класс включает в себя не только параметры, но и методы.
Что такое метод класса? Это вопрос, который мы можем задать или указание, что-либо сделать. Причем и вопрос и указания нужно адресовать уже конкретной сконструированной точке.

Научим точку сообщать свои координаты и перемещаться по одной из координатных осей:

class Point {                       //общее описание точек
    private double x, y;            //параметры точки

    Point(double ax, double ay) {   //конструктор
        x = ax;
        y = ay;
    }

    //запрос координаты Х
    double getX() {
        return x;
    }

    //запрос координаты Y
    double getY() {
        return y;
    }

    //указание сдвинуться по оси X на расстояние dx
    void moveX(double dx) {
        x = x + dx;
    }

    //указание сдвинуться по оси Y на расстояние dy
    void moveY(double dy) {
        y = y + dy;
    }
}

//использование
public class Main {
    public static void main(String[] args) {
        //создаём точку
        Point M = new Point(1, 2);
        //спрашиваем у созданной точки - скажи нам, точка М свои координаты X и Y
        System.out.println("Текущие координаты точки М: x = " + M.getX() + ", у = " + M.getY());
        System.out.println("Сдвинем точку по оси Х на 5 и по оси У на -1");
        //просим точку М - точка М, сдвинься на 5 по оси X
        M.moveX(5);
        //просим точку М - точка М, сдвинься на -1 по оси Y
        M.moveY(-1);
        //спрашиваем у точки М - скажи нам, точка М свои координаты X и Y
        System.out.println("Новые координаты точки М: x = " + M.getX() + ", у = " + M.getY());
    }
}

Еще раз повторю - методы вызываются у конкретной точки - сконструированного объекта.
Класс - это просто заготовка, шаблон, описание.
Т.е. пока точка не создана - мы как бы задумываем её нарисовать.
А вот когда сказали new, это значит, что мы нарисовали конкретную точку в конкретном месте координатной плоскости.

Записи вида

Point.getX();
//или
Point.moveX(5);

Не имеют смысла, потому что описание ничего не знает.
Это как если спросить у человека - "скажи мне координаты точки?"
Логично будет подумать, что он ответит - "какой именно?"
Также делает и компилятор.

Метки записи: Example, Java, ООП, Теория 3 Комментарии

4Сен/120

[ООП] Некоторые определения

По просьбе.
Материал выискивался как подготовка к Гос. экзаменам и представляет собой компиляцию кучи источников. Посему их не указываю.
Некоторые вещи были взяты у Гради Буча "Объектно-ориентированный анализ и проектирование"

Метки записи: ООП, Теория Читать полностью

1Сен/100

Объектно-ориентированное программирование. Введение.

Существует два основных способа проектирования программных систем – структурное проектирование, основанное на алгоритмической декомпозиции, и объектно-ориентированное проектирование, основанное на объектно-ориентированной декомпозиции. Разделение по алгоритмам концентрирует внимание на порядке происходящих событий, а разделение по объектам придает особое значение агентам, которые являются либо объектами, либо субъектами действия. Однако эти способы, по сути, ортогональны, поэтому нельзя сконструировать сложную систему одновременно двумя способами. Необходимо начать разделение системы либо по алгоритмам, либо по объектам, а затем, используя полученную структуру, попытаться рассмотреть проблему с другой точки зрения.

Алгоритмическую декомпозицию можно представить как обычное разделение алгоритмов, где каждый модуль системы выполняет один из этапов общего процесса. При объектно-ориентированной декомпозиции каждый объект обладает своим собственным поведением, и каждый из них моделирует некоторый объект реального мира. С этой точки зрения объект является вполне осязаемой вещью, которая демонстрирует вполне определенное поведение. Объекты что-то делают, и мы можем, послав им сообщение, попросить их выполнить некоторые операции.

Объектная декомпозиция имеет несколько преимуществ перед алгоритмической:
• объектная декомпозиция уменьшает размер программных систем за счет повторного использования общих механизмов, что приводит к существенной экономии выразительных средств;
• объектно-ориентированные системы более гибки и проще эволюционируют со временем, потому что их схемы базируется на устойчивых промежуточных формах. Действительно, объектная декомпозиция существенно снижает риск при создании сложной программной системы, так как она развивается из меньших систем, в которых мы уже уверены;
• объектная декомпозиция помогает нам разобраться в сложной программной системе, предлагая нам разумные решения относительно выбора подпространства большого пространства состояний.

В объектно-ориентированном анализе существует четыре основных типа моделей: динамическая, статическая, логическая и физическая. Через них можно выразить результаты анализа и проектирования, выполненные в рамках любого проекта. Эти модели в совокупности семантически достаточно богаты и универсальны, чтобы разработчик мог выразить все заслуживающие внимания стратегические и тактические решения, которые он должен принять при анализе системы и формировании ее архитектуры. Кроме того, эти модели достаточно полны, чтобы служить техническим проектом реализации практически на любом объектно-ориентированном языке программирования.

Фактически все сложные системы можно представить одной и той же (канонической) формой – в виде двух ортогональных иерархий одной системы: классов и объектов. Каждая иерархия является многоуровневой, причем в ней классы и объекты более высокого уровня построены из более простых. Какой класс или объект выбран в качестве элементарного, зависит от рассматриваемой задачи. Объекты одного уровня имеют четко выраженные связи, особенно это касается компонентов структуры объектов. Внутри любого рассматриваемого уровня находится следующий уровень сложности. Структуры классов и объектов не являются независимыми: каждый элемент структуры объектов представляет специфический экземпляр определенного класса. Объектов в сложной системе обычно гораздо больше, чем классов. С введением структуры классов в ней размещаются общие свойства экземпляров классов.

Структурный подход состоит в декомпозиции (разбиении) системы на элементарные функции, т.е., система разбивается на функциональные подсистемы, которые в свою очередь делятся на подфункции, подразделяемые на задачи и так далее. Процесс разбиения продолжается вплоть до конкретных процедур. При этом создаваемая система сохраняет целостное представление, в котором все составляющие компоненты взаимоувязаны.

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

В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие:
• SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы;
• DFD (Data Flow Diagrams) диаграммы потоков данных;
• ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".

На стадии проектирования системы модели расширяются, уточняются и дополняются диаграммами, отражающими ее структуру.

Перечисленные модели в совокупности дают полное описание системы независимо от того, является ли она существующей или вновь разрабатываемой. Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описания системы.

Метки записи: ООП, Теория Нет комментариев

Записки программиста Программирование и не только

Еще немного о классах

[ООП] Некоторые определения

Объектно-ориентированное программирование. Введение.

Рубрики

Архивы

Мета

Метки