Ответы пользователя по тегу ООП
  • Что значит сокрытие?

    @Mercury13
    Программист на «си с крестами» и не только
    Это значит: должно быть сложно или невозможно вывести объект из «адекватного» состояния (которое называется инвариант класса). Все чувствительные поля при этом прячутся от посторонних глаз. (Разумеется, могут быть «небезопасные» методы, но тогда пользователь сам себе злобный буратино).

    PHP управляет памятью сам (что-то мне кажется, что метод управления памятью там «бросай объект и шут с ним»). Но давайте представим себе, что надо вызывать команду «уничтожить объект», и дальнейшее обращение к освобождённому указателю некорректно. Попробуем сделать объект «указатель множественного владения».

    В каждом из управляемых объектов налаживаем счётчик; при переприсваивании на счётчике будет такая цифра, сколько указателей «смотрят» на объект. Счётчик упадёт до нуля — объект уничтожается. Соответственно, поле управляемого объекта «счётчик» и поле указателя «указатель на объект» скрываются. «Адекватное состояние» я уже описал: «на счётчике будет такая цифра, сколько указателей «смотрят» на объект. Счётчик упадёт до нуля — объект уничтожается».
    Ответ написан
  • Как разобраться, что происходит в этом заголовочном файле?

    @Mercury13 Куратор тега C++
    Программист на «си с крестами» и не только
    Учи понятие «единица компиляции». Тут, к сожалению, есть и вещи, которые должны быть в CPP-файле, и вещи, которые должны быть в H-файле.

    #pragma pack(1)
    Структуры данных нам нужны «один в один», без байтов заполнения.

    struct FileHeader 
    struct MAPINFO

    Формат BMP. Не забывай, что формат BMP записывается с нижней строки!

    Функция Open читает картинку «один в один», Save пишет «один в один», GetMapInfo и GetFH выдают какие-то заголовки нашего BMP.

    Остаётся GetMap(), который, по идее, должен выдавать матрицу цветов, но реально действует только для 32-битного BMP и никак не инкапсулирует ни ширину-высоту матрицы, ни тот факт, что формат BMP пишется с нижней строки.

    За этот код — тройка с минусом.

    А теперь чего ваш код НЕ поддерживает, но, по идее, должен, чтобы выполнить вашу задачу.
    1. Создание BMP нужного размера с нуля, а не загрузка из файла.
    2. Инкапсулировать матрицу пикселей. Желательно так, чтобы был быстрый доступ к строкам как к буферам в памяти, для простоты переноса информации из старого BMP в новый, на 30×30 пикселей больший.
    3. Если вы ограниченно поддерживаете формат BMP — вылетать с ошибкой, если версия неподдерживаемая (например, не то количество цветов).

    Задача именно своими силами наладить поддержку BMP? А то в Builder’е есть TBitmap.
    Ответ написан
  • Зачем в абстрактном базовом классе создавать конструктор?

    @Mercury13 Куратор тега C++
    Программист на «си с крестами» и не только
    Абстрактные классы делят на интерфейсы и частично реализованные. Грань между ними такова:
    • Интерфейс не имеет данных.
    • У интерфейса все неабстрактные виртуальные методы представляют собой или эталонное поведение, или самую частую реализацию. В обоих случаях, если что, их надо не расширять, а переписывать с нуля.

    Так вот, для интерфейсов таких конструкторов, разумеется, не нужно.

    Например, между абстрактным потоком и файлом Win32 может быть такая иерархия: Stream → HandleStream → File. Stream — интерфейс, даже если там есть что-то типа
    // virtual
    unsigned long long Stream::remainder() const { return size() - pos(); }


    HandleStream содержит уже данные (дескриптор Win32), и это уже частично реализованный класс, который крутится вокруг этого дескриптора: в деструкторе вызов CloseHandle, конструктор может принимать дескриптор, полученный каким-то «левым» образом.
    HandleStream::HandleStream(HANDLE aHandle) : fHandle(aHandle) {}
    HandleStream::~HandleStream() { close(); }
    
    void HandleStream::close()
    {
      if (Handle != INVALID_HANDLE)  { // не помню, как там эта константа в Win32
        CloseHandle(fHandle);
        fHandle = INVALID_HANDLE;
      }
    }

    Вот в таких полуреализованных классах, разумеется, конструктор может инициализировать те данные, которые там есть.
    Ответ написан
  • Как уменьшить связанность классов?

    @Mercury13
    Программист на «си с крестами» и не только
    1. Что такое Container и для чего он нужен? Возможно, от этого дела удастся избавиться или заменить интерфейсом?
    2. Не должен конструктор Graph брать в параметры Parser. Наоборот, Parser функцией parse() должен возвращать Graph.
    3. Config стоит разбить на несколько частей: одна специфична для Graph, вторая для Parser. Как их объединять — зависит от того, кому какие настройки нужны.
    Ответ написан
  • Нужно ли создавать интерфейсы для одного класса?

    @Mercury13
    Программист на «си с крестами» и не только
    1. Если из класса можно вытащить какую-то абстракцию. Например, из объекта «файл» можно вытащить абстракцию «поток». Личное — объект Project реализует интерфейс Modifiable с двумя функциями: modify() и isModified().

    2. Для упрощения юнит-тестирования при условии владения.
    Предположим, у нас есть класс «класс» (школьный) и класс «ученик». Ученик знает, в каком он классе.
    В такой ситуации получается «клубок»: если надо делать ученика, то надо делать и класс.
    Этот замкнутый круг можно разорвать, сделав интерфейс ISchoolClass и унаследовав от него класс. При юнит-тестировании заменяем класс на какую-то заглушку.
    Ответ написан
  • Как сделать разную реализацию одной и той же функции класса в C++?

    @Mercury13 Куратор тега C++
    Программист на «си с крестами» и не только
    Перенести пользовательскую функциональность в другое место — так называемый «слушатель».
    using EvClick = void (*)();
    
    Class Model{
    public:
      void click() { if (fOnClick) fOnClick(); }
      void setOnClick(EvClick x) { fOnClick = x; }
    private:
      EvClick fOnClick = nullptr;
    }

    Подобные слушатели есть в любой визуальной оконной библиотеке: VCL, Qt. В VCL так и есть, за исключением вписанных в синтаксис свойств. В Qt для этого используют сигналы-слоты.

    Наладить передачу любых данных в эту функцию — шаблон «команда».
    class ClickEvent {
    public:
      int x, y;
      virtual ~ClickEvent();
    }
    
    using EvClick = void (*)(ClickEvent&);
    Ответ написан
  • Зачем прописывать методы в Interface когда можно так же в классе?

    @Mercury13
    Программист на «си с крестами» и не только
    Ответ явоспецифичный. Потому что один класс может реализовать сколько угодно интерфейсов, но наследуется лишь от одного класса.

    Ответ концептуальный. Ромбическое наследование. От А наследуются B и C, от них обоих наследуется D.
    1) Если в A есть поле, в D что, это поле будет в двух экземплярах? А если оно protected и в B мы добавили метод, который его меняет?
    2) Если B и C переопределяют какой-то метод foo(), как быть D? А если нужна и версия B.foo(), и C.foo(), и они обе вызывают A.foo — получатеся D.foo вызовет A.foo дважды? А если в C есть второй метод bar(), который вызывает foo() и начинает вести себя не так, как надо, если мы берём реализацию B.foo()?
    В общем, множественное наследование — хорошая штука, но ромбическое — штука опасная. В языке, где любое множественное наследование неизменно ромбическое, всё, что остаётся — делать такие условия, при которых ни 1, ни 2 не сработает.
    Одно из таких условий — унаследоваться от одного класса и нескольких интерфейсов. 1) У интерфейса нет полей, и 2) эталонная реализация, существующая в некоторых языках программирования, в любом случае менее приоритетна, чем конкретная реализация из класса. Вызывать ту и другую нет смысла: если программист написал свою сверх эталонной — значит, он хочет сделать то же другим путём.
    Ответ написан
  • Нарушают ли указатели и разименование в c++ принципы ООП?

    @Mercury13 Куратор тега C++
    Программист на «си с крестами» и не только
    Не будем встревать в холивар «должен ли указатель быть объектом». Примем, что указатель — простейший тип, ради совместимости и эффективности.
    К простейшему типу инкапсуляция и наследование неприменимы.
    А вот для полиморфизма указатели очень нужны. Динамический полиморфизм — это когда под одним фасадом могут оказаться разные объекты.
    1. По копии их передавать невозможно, только по указателю/ссылке.
    2. Их нельзя уничтожать под одну гребёнку. А значит, если мы их передаём в чьё-то другое владение, надо удостовериться, что они созданы в «куче» и у «фасада» есть виртуальный деструктор.

    Есть ещё два принципа ООП — абстракция и принцип Лисков. Первый имеет отношение к указателям постольку, поскольку есть полиморфизм. Второй — гугли «ковариантные/контравариантные указатели».
    Ответ написан
  • Почему в C++ нужно строить всю программу на ООП (длинный вопрос)?

    @Mercury13 Куратор тега C++
    Программист на «си с крестами» и не только
    Задача ООП: 1) Локализовать изменения состояния объекта (инкапсуляция); 2) связывать разные кирпичики данных через стандартные интерфейсы (полиморфизм).

    Простейший тетрис не слишком велик, чтобы его писать на чистом ООП.
    Но представьте себе, мы начинаем налаживать настраиваемое управление джойстиком или клавиатурой. И тогда у нас появляется такой код.
    enum {
      BT_LEFT = 1,
      BT_RIGHT = 2,
      BT_ROTATE = 4,
      BT_SOFTDROP = 8,
      BT_HARDDROP = 16,
      BT_PAUSE = 32,
      BT_CONNECTED = 32768,   // бит, указывающий, что контроллер подключён
    };
    class Controller {  // интерфейс
    public:
      virtual unsigned poll() const = 0;   // сочетание битов BT_XXX
      virtual ~Controller = default;
    };

    Классы Keyboard и Joystick поддерживают интерфейс Controller, и подмена клавиатуры на джойстик и наоборот ничего не изменит.
    Вот вам полиморфизм.

    Текстовый редактор превращаем в многооконный — берём класс Editor и пристраиваем его не к программе в целом, а к MDI-окошку. Вот вам инкапсуляция — локализованное изменение состояния.

    Я как-то мучил движок Doom. Он написан в самом настоящем объектном стиле на чистом Си! Хотя и там были проблемы: сетевой код был куда хуже по качеству, чем сам движок. Писали разделённый экран, глобальную переменную netgame разделили на две, multiplayer и netgame и долго-долго правили баги, где multiplayer, где netgame (было дело, участник десматча ввёл IDKFA, это сработало и вызвало рассинхронизацию). А код пользовательского интерфейса — вообще медвежуть!
    Ответ написан
  • Почему в интерфейсе могут быть только public методы?

    @Mercury13
    Программист на «си с крестами» и не только
    Private — на что? Ведь тот, кто пойдёт этот интерфейс реализовать, их не увидит.

    С protected штука более сложная. Дело в том, что в классическом интерфейсе ноль кода и данных, и эти protected должен вызывать — кто — разумеется, потомки. Преждевременно увековечивать внутреннюю архитектуру — зачем?

    Встречается ещё такая штука, как «прокачанный интерфейс» — не знаю, как он правильно называется по ООП. Там есть две новых вещи: 1) утилиты — невиртуальные функции, которые представляют собой стандартный сценарий пользования интерфейсом; 2) штатные реализации — некоторым виртуальным функциям придумывают реализацию, которая как-то работает и пользуется другими виртуальными, но потомок, если захочет, может написать более эффективную версию.

    Вот например, утилита.
    // write Intel word
    void st::Stream::writeIW(uint16_t w)
    {
        write(&w, sizeof(uint16_t));
    }
    Утилита не часть интерфейса, и лучший синтаксис для утилит — методы-расширители C#. На худой конец подойдёт простая функция типа Streams.writeIW(stream, 10);.

    Вот, например, штатная реализация.
    // Возвращает остаток потока
    // cu_minus = clipped unsigned minus
    virtual Pos remainder() { return cu_minus<Pos>(size(),pos()); }
    Если в языке нет штатных реализаций, строят класс, где эти функции чем-то реализованы — не всегда, но часто можно унаследоваться от этого класса.

    Раз утилита пользуется обычными общедоступными функциями, нет никакого смысла её кидать в protected (теоретически private/protected могут быть некоторые части сложных утилит). Штатные реализации — тем более, это такая же часть интерфейса, как абстрактные size() и pos().
    Ответ написан
  • Как реализовать наследование статического поля/метода, если это возможно?

    @Mercury13 Куратор тега C++
    Программист на «си с крестами» и не только
    Первое. Объясни, для себя и для меня, что собой представляет объект Command?

    Моё видение — разделить объекты Command (введённая пользователем и разобранная строка) и Program (программа, реализующая команду). Также я нарисовал — хочешь, используй, хочешь, нет — объект Console (консоль ввода-вывода) и System (окружение программы вроде текущего каталога, переменных окружения, файловой системы).

    Я тут работаю со значениями и указателями, в терминах C++03, но, возможно, вас заинтересуют умные указатели C++11.

    std::string commandLine = console.getSomeCommandLine();
    Command command;
    std::string error;
    if (!command.parse(commandLine, error)) {
      console.err().writeln(error);
      return;
    }
    Program* program = system.findProgram(command.programName);
    if (!program) {
      console.err().writeln("Bad command or file name");
      return;
    }
    Console redirectedConsole = console.redirectStreams(command);
    program->exec(redirectedConsole, system, command.getArguments());


    Второе. Возвращай ссылки, это быстрее.
    const std::vector<std::string>& getArguments() const;
    const std::vector<std::string>& getOptions() const;
    Ответ написан
  • Как определить метод класса, чтобы объект в него передавался не по ссылке?

    @Mercury13 Куратор тега C++
    Программист на «си с крестами» и не только
    UPD. Теперь понял, о чём вы. В таком виде нельзя.
    Ответ написан
  • Объясните толком про интерфейсы в ООП (Delphi). Как их использовать?

    @Mercury13
    Программист на «си с крестами» и не только
    Интерфейсы в Delphi отвечают за две малосвязанных вещи.
    1. Множественное наследование. Об этом уже рассказали до меня, повторяться не буду.
    2. Подсчёт ссылок (для этого реализатор должен корректно поддерживать _AddRef и _Release, но это уже другой вопрос, и подходящая реализация есть в TInterfacedObject).
    Связано это с тем, что Delphi должен был поддерживать Microsoft COM, а там автоматическое управление через подсчёт ссылок.
    Так что интерфейсы часто приплетают только потому, что удобно работать с подсчётом ссылок.

    Вот, например, моя библиотека (обёртка cURL для Delphi) под названием curl4delphi: https://github.com/Mercury13/curl4delphi
    На что тут ICurl? А на то, что это объект с подсчётом ссылок, и для него не надо вызывать деструктор. Пропадает последняя ссылка — объект исчезает. Вот и всё.
    Из-за автодеструкторов, «киллер-фичи» Си++, я в Си++ так не поступал бы.
    Ответ написан
  • PHP функциональный язык или объектно-ориентированный?

    @Mercury13
    Программист на «си с крестами» и не только
    PHP изначально задумывался скриптовым языком — языком процедурного программирования с динамической типизацией и возможностью вписать пару строк, не оформляя тело. Таким он и остаётся поныне, с вкраплениями ОО. Немного функциональщины, конечно, есть, но это не делает PHP — как, впрочем, Java или C++ — настоящим функциональным языком.
    Ответ написан
  • Паскаль. Переменные и массивы внутри классов?

    @Mercury13
    Программист на «си с крестами» и не только
    Что творится? Не компилируется?
    А не компилируется из-за непонимания концепции эквивалентности типов. В отличие от Си, внешне одинаковые типы не эквивалентны! Для эквивалентности надо, чтобы их цепочки type A = B; вели к одному «предку». Для этого существует оператор type.
    const
      FieldSize = 10;
      MaxShips = 10;
    type
      TField = record
        cells : array [1..FieldSize, 1..FieldSize] of integer;
        nLive : array [1..MaxShips] of integer;
      end;
      TGame = class
        Field : TField;
        constructor Create(const Field : TField);  
      end;

    Возможно, эквивалентность ослабили в Delphi, не проверял. А в BP именно так.

    Возможно, вы также сделали известную ошибку начинающего дельфиста:
    var
      x : Test;
    ....
    x.Create(a, b);     // неверно!
    x := Test.Create(a, b); // верно!


    Есть одно исключение из этой эквивалентности типов.
    type
      DaInt = array of integer;
    
    procedure DoSomething1(var x : array of integer);
    procedure DoSomething2(var x : DaInt);

    Эти команды обе действуют, но не эквивалентны!

    Первое — нововведение TP7, параметр типа «открытый массив», массив любой размерности. Статический, динамический, строчка 2D-массива — всё подойдёт. Действуют Low, High и (для D4+) Length.

    Второе — нововведение D4, динамический массив, которому можно изменять длину через SetLength.
    Ответ написан
  • Как освободить память в java?

    @Mercury13
    Программист на «си с крестами» и не только
    1. Самое простое. var = null; Если нужно ещё и мусорщика пустить — ну пусти, System.gc();
    2. Если нужно, чтобы объект не удерживался — WeakReference. Как только объект исчезнет, слабая ссылка перещёлкивается в null. Бывает нужно: 1) если объекты-дети переживают своих владельцев, и при этом потерять владельца — это несмертельно; 2) когда строим какой-нибудь временный список.
    3. Не выдавать безымянный объект наружу, если он переживает создателя. В безымянных объектах есть ссылка на создателя. Выдавать лямбду: если создатель не нужен, ссылки никакой не будет.
    4. Аналогично с внутренними классами — если он переживает создателя, делай его static.
    5. String.intern, если вы работаете с кучей мелких одинаковых строк. Ну или наладить свой кэш :)
    6. Использовать объектные пулы и прочие структуры, снижающие нагрузку на мусорщик.
    7. Разбивая строки на мелкие кусочки, использовать паттерн doSomething(String data, int start, int length), не вытягивая подстроку физически. Использовать StringBuilder.
    Ответ написан
  • Стоит ли вынести объявление типов в отдельный файл?

    @Mercury13 Куратор тега C++
    Программист на «си с крестами» и не только
    Стоит!
    Назовите этот хедер как-нибудь defines.h
    Ответ написан
  • Как разнести класс по файлам?

    @Mercury13 Куратор тега C++
    Программист на «си с крестами» и не только
    Принцип прост. В .h можно ставить только то, что не производит кода. Как только в проекте появится второй CPP и задействует этот хедер, код будет произведён дважды, и компоновщик (cl/ld/ilink) будет ругаться, что переменная или функция в двух экземплярах. Что именно не производит кода…
    • Определения макросов. Они в принципе кода не производят.
    • Объявление любого типа. Оно лишь говорит об устройстве этого самого типа; код же производят те, кто этим типом пользуются.
    • Шаблоны. Код производит не сам шаблон, а факт расшаблонивания. Разумеется, шаблон может расшаблониться в двух единицах компиляции, но с этим автоматически бороться научились.
    • inline—  код производит не сам inline, а факт включения. inline бывает как явный ключевым словом, так и неявный — в теле класса.
    • Прототипы и extern — они говорят: код есть, но где-то не здесь.
    • Constexpr C++11. Они подставляют значение.
    • Некоторые const в зависимости от компилятора. Например, на Borland const double производит код, а const int — нет.

    Производят код и в хедерах запрещены.
    • Переменная без extern, даже const.
    • Функция, которая не inline.
    • Полностью специализированный шаблон, в котором не осталось шаблонных параметров (template<>).

    Не производят кода, но и лучше закинуть в CPP.
    • Некоторые скрытые (private) inline и шаблоны, если они не используются из хедера.
    Ответ написан
  • Как объяснить кусок кода C++?

    @Mercury13 Куратор тега C++
    Программист на «си с крестами» и не только
    Весь этот код (за исключением Close) — автогенерируемый.

    ///// Защита от повторного включения
    #ifndef Unit1H
    #define Unit1H
    
    ///// Хедеры VCL. Причём всё это сделано так, чтобы упростить написание ценой удлинения
    ///// компиляции. Более громоздкий, но и более удачный вариант.
    ///// В H:
    /////   namespace Controls { class TLabel; }
    /////   using namespace Controls;
    ///// В CPP:
    /////   #include <Controls.hpp>
    ///// Вот таким образом можно (было) избавиться от каскадного подключения
    ///// хедера Controls. А то каждый, кто использует главной форму,
    ///// автоматически подключает эти хедеры.
    #include <Classes.hpp>
    #include <Controls.hpp>
    #include <StdCtrls.hpp>
    ///// Только от Forms.hpp избавиться таким макаром нельзя:
    ///// мы наследуемся от TForm.
    #include <Forms.hpp>
    
    ///// Класс формы. Все формы наследуются от TForm.
    class TForm1 : public TForm
    {
       ///// Особое право доступа Borland, для совместимости с Delphi.
       ///// Поля и свойства published не просто public, но включаются
       ///// в структуру рефлексии (aka reflection или introspection)
       ///// и программа о них знает при выполнении.
       ///// Применительно к формам — published-поля доступны
       ///// загрузчику.
    __published: // IDE-managed Components
       ///// Компоненты, которые мы установили на форме редактором.
    TLabel *Label1;
    TButton *Button1;
       ///// События, которые мы прописали в редакторе.
       ///// __fastcall — модель вызова, аналогичная Delphi.
       ///// Именно такая модель вызова принята в обработчиках
       ///// событий.
    void __fastcall Button1Click(TObject *Sender);
       ///// Пользователь пока не прописал никаких своих
       ///// полей и функций.
    private: // User declarations
    public: // User declarations
       ///// Конструктор. Раз уж у формы нетривиальный конструктор —
       ///// по правилам Си++ его надо повторить в подклассе.
       ///// Снова-таки, модель вызова __fastcall: в формах Delphi
       ///// используются т.н. виртуальные конструкторы, 
       ///// когда по имени класса можно создать объект этого класса.
       ///// Фабричный метод, только немного лучше.
       ///// Но это значит: у всех подчинённых классов
       ///// должен быть один и тот же набор параметров
       ///// и модель вызова.
    __fastcall TForm1(TComponent* Owner);
    };
    //---------------------------------------------------------------------------
    ///// Как известно, переменная объявляется один раз.
    ///// Поскольку хедер может подключаться к огромному числу CPP,
    ///// её объявляют как extern (она есть, но в другом месте).
    ///// Макрос PACKAGE раскрывается в __declspec(package),
    ///// чтобы эту штуку можно было собрать как пакет.
    extern PACKAGE TForm1 *Form1;
    //---------------------------------------------------------------------------
    #endif

    Модель вызова — это как технически мы вызываем подпрограмму. Какая память и какие регистры на это используются, и кто подчищает стек. Ищи в Википедии.
    Ответ написан
  • Для чего используются "методы по умолчанию" на практике?

    @Mercury13
    Программист на «си с крестами» и не только
    Это приближает интерфейсы Java к примесям.

    1. Очень часто бывает, что у какой-то функции есть реализация, опирающаяся на другие функции — либо базовая неоптимальная, либо вообще единственно возможная. Чаще всего это избыточные функции-утилиты. Пишу на Си++
    class Stream {
    public:
      virtual void write(size_t length, const void* data) = 0;
    
      // пишет в поток word в машинном порядке байтов
      void writeW(uint16_t data) {
        write(2, &data);
      }
    };

    За что вообще так ненавидят множественное наследование? За дублирование данных! Вот у нас некая штука, без единого поля данных — почему в Java она класс, а не интерфейс?

    2. Какую-то функцию переопределяют настолько редко, что лучше сделать ей реализацию на месте. Опять Си++.
    class ErpConnector {
    public:
      // 80% модулей не могут экспортировать данные в систему управления
      //   предприятием — напишем базовую реализацию.
      virtual bool canExportData() const { return false; }
      virtual void exportData() const {}
    };


    3. И просто документирование, как оно должно себя вести :) Из реального проекта, снова Си++.
    void im::DateGrouper::toFirstDateOfPeriod(dt::Date& aDate, int aStart) const
    {
        aDate = toDate(toInt(aDate, aStart), aStart);
    }

    Класс служит для группировки дат в периоды (недели, месяцы, годы). aStart — это дополнительный int, позволяющий начать год с февраля или месяц с 15-го. Эта функция переводит дату «на месте» в первую дату периода. Она крайне неоптимальна (дату в число, затем число опять в дату) и потому переписана почти во всех в реализациях.
    void im::MonthGrouper::toFirstDateOfPeriod(dt::Date& aDate, int aStart) const
    {
        if (aDate.day < aStart)
            aDate.addMonthsMechanical(-1);  // механически вычесть 1 месяц; дата может стать неверной.
        aDate.day = aStart;
        aDate.fixupTo1();    // неверную дату привести к 1-му числу следующего месяца
    }


    Но по крайней мере понятно, как она должна работать.
    Ответ написан