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

Интернет обошла стороной одна интересная новость: стало известно о том, что, вероятно, в следующий стандарт языка программирования 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 (охота за привидениями)
Причина появления: непонимание концепций ООП, лень продумать архитектуру классов
Читать полностью »

Приветствую читателей.
В этом посте хотел бы показать две реализации паттерна «Стратегия». Один способ на основе наследования, другой на основе шаблонного класса. Итак приступим.
Сначала разберемся, что же такое паттерн «Стратегия»? К этому обратимся в википедию и вот что она говорит:

Стратегия — поведенческий шаблон проектирования, предназначенный для определения семейства алгоритмов, инкапсуляции каждого из них и обеспечения их взаимозаменяемости. Это позволяет выбирать алгоритм путем определения соответствующего класса. Шаблон Strategy позволяет менять выбранный алгоритм независимо от объектов-клиентов, которые его используют.

Так выглядит схема паттерна:

Паттерн «Стратегия» на C++ - 1
Читать полностью »

Пришла мне тут как-то мысль освоить PHP, а, как известно, лучший способ изучить язык – это создать на нем велосипед фреймворк. При ковырянии в различных форумах и топиках заинтересовала меня одна методология, которую пропагандируют в уважаемой компании «Яндекс» — БЭМ. Кто ещё не в курсе этой методологии, почитайте на официальной страничке. Так же на Хабре есть публикация «Верстка для самых маленьких. Верстаем страницу по БЭМу» от читателя xnim, в котором все объяснятся на конкретном примере. «Яндекс» написали свои модули и скрипты сборки проектов, однако выполнены они все на Node.js, а вот на PHP обнаружить что-то подобное мне не удалось (хотя, признаюсь честно, я особо и не искал). К тому же, PHP, как объектно-ориентированный язык, дает интересные возможности.

BemPHP: реализация методологии БЭМ средствами PHP - 1
Читать полностью »


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