Рубрика «паттерны проектирования» - 6

[Почти] MVC подход к реализации пользовательского интерфейса в Delphi. Часть 3. Объекты
В предыдущих частях статьи (1, 2) я показал, каким образом можно организовать работу с внутренними данными приложения и пользовательским интерфейсом через одну точку входа — модель. Изменения модели автоматически отражались в пользовательском интерфейсе. При этом для упрощения в качестве модели я использовал простые property класса формы, setter которых может привести GUI интерфейс к текущему состоянию модели. В данной части статья я покажу, как интерфейс может реагировать на изменения самих объектов внутри приложения.
Читать полностью »

[Не совсем] MVC подход к разработке пользовательских интерфейсов в Delphi. Часть 2. Списки

Предыдущая статья была посвящена всего одной галочке. Пора переходить к чему-то чуть более серьезному. Сегодняшняя тема — представление списков и связь GUI-списков с внутренними данными. Статья предназначена для Delphi-разработчиков.
Читать полностью »

MVC подход к разработке пользовательских интерфейсов в Delphi. Часть 1. Галочка
Не буду писать красивых предисловий, потому что статья не развлекательная, а скорее техническая. В ней я хочу кратко рассмотреть простые приемы программирования пользовательского интерфейса классических desktop-приложений в среде Delphi.
Тех немногих, кто еще пользуется этой средой разработки, прошу под кат.
Читать полностью »

image

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

Если спросить у десяти разработчиков о паттернах проектирования и о том, какая книга является лучшим источником информации по этой теме, то 9 из 10 назовут знаменитую книгу банды четырех и будут правы. GoF – является классическим каталогом паттернов в том виде, в котором он был описан Кристофером Александером 35 лет назад и все еще остается бесценным справочником для любого программиста.

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

Любой знакомый с книгой о паттернах, написанной Бандой Четырёх знает, что паттерны, описанные в книге, представляют собой элегантные решения, проверенные временем. К сожалению, выделение этих паттернов из преемственного кода невозможно, потому что никто не знает, что они предложили эти паттерны, когда писали преемственный код. Поэтому следующий текст представляет из себя паттерны для широких масс. Представленные в этом документе паттерны представляют собой решения, пережившие многих. Наслаждайтесь чтением, но не используйте на практике!

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

Предыстория

Сразу извиняюсь за сложность, но сложна как сама ситуация для применения этого, так и способ решения, но получается в результате красиво и эффективно :)

Началось с того, что описал одну проблемку о проблемах ООП. Потом случайно благодаря разговорам тут начал обдумывать паттерны проектирования. И в связи с темой «полное копирование объекта» вышел на паттерн Flyweight. Кто не знает — прошу вначале читайте о нем в Приемы объектно-ориентированного проектирования. Паттерны проектирования (Не в вики, а в оригинале).

Основная идея там такова:

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

Задача

Мы рассмотрим как это улучшить на конкретном примере. О биовычислениях буду говорить очень мало — но пример будет построен на этом. Суть биовычислений попытаюсь полностью вытравить, оставив только схему.

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

Предыстория

Сразу извиняюсь за сложность, но сложна как сама ситуация для применения этого, так и способ решения, но получается в результате красиво и эффективно :)

Началось с того, что описал одну проблемку о проблемах ООП. Потом случайно благодаря разговорам тут начал обдумывать паттерны проектирования. И в связи с темой «полное копирование объекта» вышел на паттерн Flyweight. Кто не знает — прошу вначале читайте о нем в Приемы объектно-ориентированного проектирования. Паттерны проектирования (Не в вики, а в оригинале).

Основная идея там такова:

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

Задача

Мы рассмотрим как это улучшить на конкретном примере. О биовычислениях буду говорить очень мало — но пример будет построен на этом. Суть биовычислений попытаюсь полностью вытравить, оставив только схему.

P.S. Если кому то интересна проблематика самих биовычислений по задаче сворачивания РНК/белков — делайте заказ напишу тогда отдельную статью.

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

Предыстория

Статья Неверное использование паттерна проектирования «Мост» / «Bridge» как то так получилось разделила аудиторию на двое. Далее я подумал, сказав А не сказать Б, будет не правильно. Нет я не отказываюсь от своих слов, но я нашел где и как я использовал паттерн «Мост». Т.к. его еще и неверно понимают, кажется альтернативное название «Описатель/тело» — меньше вводит в заблуждение.

Так где же? Оказалось в моем аналоге использования концепции MVC (Модель/Представление/Контроллер).

Поэтому вначале ознакомлю со своей вариацией «Бизнес-сущность — Визуализация — Контроллер». Я уже ее писал, но думаю мало кто с этим знаком. А затем посмотрим где же там «Правильный мост».

P.S. Мне тут выдали кредит доверия, и я обязался написать еще одну статью о усовершенствовании паттерна Flyweight — помню, пишу, надеюсь смогу опубликовать :)

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

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

Кратко о шаблонах GoF (Gang of Four – «банда четырех»)

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

«Когда мы писали нашу книгу, мы действительно пытались кое-чтоЧитать полностью »

Прочитав статью товарища tac, посвященную злополучному паттерну проектирования Bridge (от англ. — «Мост»), мне стало очень обидно и за Банду Четырех, чьи идеи были самым бессовестным образом осрамлены, и за сам паттерн, который был ужаснейшим образом дискредитирован в глазах менее опытных читателей. Не в силах больше смотреть на пылкие дебаты, разгорающиеся в комментариях, я решил спасти репутацию бедного паттерна, виновного лишь в том, что вот уже в который раз, он был неправильно истолкован.

Если вам еще не надоели статьиЧитать полностью »