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

в 17:38, , рубрики: c++, ооп, паттерн стратегия, паттерны, Программирование

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

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

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

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

в 15:34, , рубрики: framework, php, БЭМ, веб-дизайн, велосипедостроение, верстка, ооп, яндекс

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

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

в 11:55, , рубрики: анализ, Анализ и проектирование систем, аристотель, логическая парадигма, моделирование предметной области, онтология, ооп, парадигмы, Семантика

Здравствуйте.

Эта замечательная статья подтолкнула меня опубликовать давние мысли, касающиеся моделирования предметной области с помощью объектно-ориентированного программирования.

К актуальности изложенных в статье идей, приходишь подспудно (не имея возможности выразить по причине того, что парадигме моделирования в терминах теории множеств не учат в вузах, будущих «программистов», по крайней мере), долго работая с ООП и реляционными базами данных:

Каждый раз при моделировании предметной области, оперируя терминами ООП (сейчас говорим не об этапе бизнес-анализа, а о последующем этапе реализации модели в коде), для всех сущностей предметной области приходится реализовывать в коде и схеме БД следующий паттерн, состоящий их «подсущностей», связанных между собой:

  • класс/таблицу вида «Машины» (здесь и далее класс употребляю в терминах ООП);
  • класс/таблицу вида «Список машин»;
  • класс/таблицу вида «Машина».

Далее с помощью механизмов ООП и реляционной модели «подсущности связываются между собой.

Причем термины „сущность“ и „подсущность“ применимы именно к модели предметной области в терминах теории множеств,
а в терминах ООП/реляционной модели уместны термины „метасущность“ и „сущность“ соответственно.
Надеюсь, понятно, почему? — ООП/реляционная модель являются более низкоуровневыми механизмами, и сущность предметной области приходится конструировать, нет в них средств, которые нативными образом позволили бы отразить сущность предметной области.

А далее следуют ожидаемые проблемы:

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

в 7:25, , рубрики: .net, dependency injection, Блог компании СКБ Контур, ооп, Проектирование и рефакторинг

Да-да, вы все правильно поняли, это статья об еще одном велосипеде — о моем Dependency Injection (DI) контейнере. За окном уже 2015-ый год, и самых разных контейнеров на любой вкус и цвет полным полно. Зачем может понадобиться еще один?

Во-первых, он может просто образоваться сам собой! Мы в Эльбе довольно долго использовали этот контейнер, и некоторые из описываемых в статье идей (Factory Injection, Generics Inferring, Configurators) изначально были реализованы поверх него через публичное API.

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

В-третьих, DI-контейнер — относительно простая штука. Он очень хорошо поддается разработке в режиме TDD, за счет чего делать его становится весело и приятно.

Эта статья — не введение в DI. На эту тему есть много других прекрасных публикаций, в том числе и на Хабре. Скорее здесь собран набор рецептов приготовления DI так, чтобы получившееся блюдо было вкусным, но не острым. Если у вас DI-контейнер в продакшене или вы написали свой собственный самый лучший контейнер, то здесь отличное место для холиваров о том, чей контейнер круче!
Читать полностью »

в 10:54, , рубрики: c++, Анализ и проектирование систем, именованные параметры, ооп, пользовательские типы, Программирование, проектирование

Время от времени вдруг начинает хотеться именованных параметров в C++. Не так давно была статья, да и сам какое-то время назад писал на эту тему. И вот что удивительно — со времен той своей статьи я участвую в новом проекте без необходимости тащить за собой старый код, и как-то удивительным образом всего этого описанного собой же не использую. Т.е. в вопросе разобрался, восхитился перспективами… и продолжил работать по-старинке! Как же так? Лень? Инерция? Ответ постараюсь дать под катом.
Читать полностью »

в 19:37, , рубрики: Delphi, FireMonkey, mobile development, open source, tdd, testing, ооп, Проектирование и рефакторинг

Часть 1.
Часть 2.
Часть 3. DUnit + FireMonkey
Часть 3.1. По мотивам GUIRunner
Часть 4. Serialization

Здравствуйте, дорогиее.

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

Сейчас наш проект выглядит так:

MindStream. Как мы пишем ПО под FireMonkey. Часть 5. Тестирование - 1
Читать полностью »

в 14:21, , рубрики: монады, ооп, Программирование

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

Итак, в этой публикации вы не найдете ответы на следующие вопросы:
1. Что такое монада?
2. Где и как использовать монады?
3. Почему монады лучше, чем их отсутствие?
Читать полностью »

в 11:16, , рубрики: DDD, php, Анализ и проектирование систем, качество кода, ооп, проектирование

Статья, можно сказать, о наболевшем.
Из-за низкого порога вхождения, привычке к связке с MySQL, отсутствия необходимости сборки, отсутствия строгой типизации и других факторов, проекты, написанные на PHP, зачастую не блещут качеством и содержат много нагромождённых запросов в базу, вместо красивого чистого кода.

PHP — скриптовый язык, сервер отвечает на запрос и объекты умирают. Да, это не desktop-приложение.
Но это не значит, что объекты предметной области, с которыми мы должны работать, не нужны вовсе.
Наоборот! Они нужны, они должны помогать нам сохранять и восстанавливать их состояние, после их удаления из памяти.

На PHP можно и нужно писать качественный код, в прочем это вообще не зависит от языка!
В первую очередь статья будет полезна для новичков, но думаю не помешает и бывалым разработчикам. Возможно, и в вашем проекте всё не так, как хотелось бы?
Читать полностью »

в 12:26, , рубрики: javascript, ReactJS, ооп

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

var A = {
    doStuff (){}
}

var B = {
    doStuff (){}
}

var C = React.createClass({
    mixins: [A, B]
});
//упс... ошибка, потому что React не может решить какой из doStuff унаследовать

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

в 4:43, , рубрики: class, inherit, inheritance, inherited, javascript, node.js, override, класс, наследование, ооп

Краткая заметка про наследование в Node.js - 1В JavaScript существует множество разных способов наследования, классового и прототипного, фабричного и через примеси, прямого и непрямого, а так же гибриды нескольких методов. Но у Node.js есть его родной способ с применением util.inherits(ChildClass, ParentClass). До недавнего времени я использовал нодовский способ только для встроенных классов (когда нужно сделать своего наследника для EventEmitter, Readable/Writable Stream, Domain, Duffer и т.д.), а для моделирования предметной области применял общеупотребительные для всего JavaScript практики. И вот, впервые, понадобилось реализовать собственную иерархию системных классов, не наследников от встроенных, но и не классов предметной области, а классов, массово поражаемых в системном коде сервера приложений Impress. И простого использования util.inherits уже как-то не хватило, поискал я статьи и не найдя полностью всего, что мне нужно, изучил примеры наследования в исходниках самой ноды, подумал и сделал пример родного нодовского наследования себе на память и написал эту небольшую заметку, чтобы она, надеюсь, помогла еще и вам. Сразу предупреждаю, что реализация вызова метода родительского класса из переопределенного в дочернем классе метода, мне не очень нравится из-за громоздкости, поэтому, приветствую альтернативные способы и приглашаю коммитить их в репозиторий или в комментарии к этой заметке.

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

1...1020...313233...40...48
Главная   |  Архив новостей  |   Android  |   Google  |   Apple  |   Microsoft  |   Информационная безопасность  |   Веб – разработка
Публикации RSS  |  Комментарии RSS
https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js