Рубрика «ооп» - 31

Возможно, вам знаком способ, которым ключевое слово super в языке Java позволяет передавать управление методу (или конструктору) базового класса. В Perl 6 есть нечто похожее. Но в мире с множественной наследуемостью и миксинами нет смысла называть эту функцию super. Поэтому она называется nextsame.
Пример:

class A {
    method sing {
        say "а после умерла.";
    }
}

class B is A {
    method sing {
        say ("зимой и летом стройная," xx 4).join(" ");
        nextsame;
    }
}

class C is B {
    method sing {
        say "в лесу родилась ёлочка,";
        say "в лесу она росла.";
        nextsame;
    }
}

Читать полностью »

Добрый день, коллеги!

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

Моделирование функциональных и физических событий в логической парадигме - 1

В этой статье я продолжаю давать определения терминам в рамках логической парадигмы. Я развиваю мысль о том, что такое реальность и о том, как мы ее моделируем. Я подчеркиваю тот факт, что мир, в котором мы живем, — это иллюзия. Мы даже не знаем, есть ли мы на самом деле, или наше существование — тоже иллюзия. Наше «Я» думает, что существует, но существует оно в мире иллюзий. Все, что мы видим, и что моделируем, — мы видим иллюзию и моделируем иллюзию.
Читать полностью »

Интернет обошла стороной одна интересная новость: стало известно о том, что, вероятно, в следующий стандарт языка программирования C будут добавлены средства ООП, а именно — классы. При этом судить о том, будет ли это реализовано — ещё рано, так как данный документ не был окончательно принят и не добавлялся в черновой вариант следующего стандарта. Предложение реализовать это поступило ещё в далёком 1995 году неким Robert Jervis, но было принято на WG14 только сейчас.

Попробуем поделить шкуру неубитого медведя и посмотрим, чем это грозит и что это нам даст.
Читать полностью »

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

Подробности описания модульной структуры изложены по вышеуказанной ссылке, но если вы еще не знакомы с этим материалом, то вкратце: масштабируемые JavaScript-приложения строятся на трёх китах, а точнее — на трёх паттернах: Медиатор, Фасад, Модуль.

Основные критерии в реализации:
Читать полностью »

Введение

Как недавно было сказано в публикации в «Честные приватные свойства в прототипе», существует два лагеря JavaScript-разработчиков:

  • те, что готовы терпеть префиксы, как обозначение сокрытия свойствметодов;
  • те, что не готовы терпеть псевдо-инкапсуляцию.

Я отношу себя ко второму лагерю и решаю проблему объявлением всего класса в его конструкторе, что позволяет использовать private/public в любой комбинации с static.
Читать полностью »

Долгое время я изучал паттерн MVC. Больше полутора лет прошло с тех пор, как я впервые с ним познакомился и в течение всего этого времени я никак не мог упорядочить в своей голове зоны ответственности трех составляющих паттерн компонентов.

MVC — это сложное, но потрясающе изящное архитектурное решение. Я не представляю, во что бы превратились современные приложения без данного паттерна.

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

Я решил собрать всю недостающую информацию в одном месте. Это и стало причиной для написания статьи.

tl;dr: читаем итог. Остальных прошу устроиться поудобнее.
Читать полностью »

Привет!

За последние 10 лет(С днем рождения, prototype.js!) было написано очень много библиотек для эмуляции полноценного ООП в javascript.
Все они, так или иначе, решали задачу реализации приватных членов класса.

Копьев сломано много и в итоге разработчики разделились на 2 части:
Первая прячет приватные свойства в scope конструктора и отказывается от использования прототипов(создает методы для каждого экземпляра объекта заново), вторая просто использует соглашение в именах вроде "_privateProperty" и по сути никак не инкапсулирует данные.

Читать полностью »

Наименование: Functional Decomposition (функциональная декомпозиция)
Другие наименования: No Object-Oriented AntiPattern «No OO»
Масштаб: приложение
Рефакторинг: объектно-ориентированный реинжиниринг

Функциональная декомпозиция — хорошая практика процедурного программирования, так как она позволяет разделить приложение на отдельные функциональные модули.

К сожалению функциональную декомпозицию невозможно напрямую отразить в иерархии классов и поэтому иногда возникают проблемы, описываемые в статье.
Читать полностью »

Рассмотрим, в качестве примера, следующую ситуацию. У нас имеется класс User с полями, описывающими пользователя. Имеется класс Phone, который является родительским для классов CellPhone и SatellitePhone. В классе User есть поле содержащее список телефонов пользователя. В целях уменьшения нагрузки на БД мы сделали этот список «ленивым». Он будет загружаться только по требованию.

Выглядит это все примерно так

public class User {
    ...

    @OneToMany(fetch = FetchType.LAZY)
    private List<Phone> phones = new ArrayList<Phone>();

    public List<Phone> getPhones() {
        return phones;
    }
}

public class Phone {
    ...
}

public class CellPhone extends Phone {
    ...
}

public class SatellitePhone extends Phone {
    ...
}

В такой конфигурации при запросе списка телефонов конкретного пользователя мы можем получить как список проинициализированных объектов-телефонов (например, если они уже есть в кэше), так и список proxy-объектов.
В большинстве ситуаций нам не важно с чем именно мы работаем (реальным объектом или его proxy). При запросе какого-либо поля какого-либо объекта — proxy-объект автоматически проинициализируется, и мы получим ожидаемые данные. Но если нам нужно узнать тип объекта, то все идет наперекосяк.
Читать полностью »

«Я точно не знаю, что делает этот класс, но я уверен, что это важно!»

У паттернов проектирования — типовых решений, есть антиподы — типовые ошибки в проектировании. О паттернах проектирования написано достаточно книг, о антипаттернах — единицы. Вашему вниманию представлен вольный перевод статьи с сайта SourceMaking, описывающий один из таких антипаттернов (всего на сайте в разделе Software Development Antipatterns их представлено 14).
Антипаттерны проектирования: Poltergeists - 1
Наименование: Poltergeists (полтергейсты)
Другие наименования: Gypsy (цыган), Proliferation of Classes (рост количества классов), Big DoIt Controller Class
Масштаб: приложение
Рефакторинг: Ghostbusting (охота за привидениями)
Причина появления: непонимание концепций ООП, лень продумать архитектуру классов
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js