![[Не совсем] MVC подход к разработке пользовательских интерфейсов в Delphi. Часть 2. Списки](https://www.pvsm.ru/images/-ne-sovsem-MVC-podhod-k-razrabotke-polzovatelskih-interfeisov-v-Delphi-chast-2-spiski.png "[Не совсем] MVC подход к разработке пользовательских интерфейсов в Delphi. Часть 2. Списки")
Предыдущая статья была посвящена всего одной галочке. Пора переходить к чему-то чуть более серьезному. Сегодняшняя тема — представление списков и связь GUI-списков с внутренними данными. Статья предназначена для Delphi-разработчиков.
Читать полностью »
Не буду писать красивых предисловий, потому что статья не развлекательная, а скорее техническая. В ней я хочу кратко рассмотреть простые приемы программирования пользовательского интерфейса классических desktop-приложений в среде Delphi.
Тех немногих, кто еще пользуется этой средой разработки, прошу под кат.
Читать полностью »
Предыстория
Сразу извиняюсь за сложность, но сложна как сама ситуация для применения этого, так и способ решения, но получается в результате красиво и эффективно :)
Началось с того, что описал одну проблемку о проблемах ООП. Потом случайно благодаря разговорам тут начал обдумывать паттерны проектирования. И в связи с темой «полное копирование объекта» вышел на паттерн Flyweight. Кто не знает — прошу вначале читайте о нем в Приемы объектно-ориентированного проектирования. Паттерны проектирования (Не в вики, а в оригинале).
Основная идея там такова:
Паттерн Flyweight описывает, как совместно разделять очень мелкие объекты без чрезмерно высоких издержек. Каждый объект-приспособленец имеет две части: внутреннее и внешнее состояния. Внутреннее состояние хранится (разделяется) в приспособленце и состоит из информации, не зависящей от его контекста. Внешнее состояние хранится или вычисляется объектами-клиентами и передается приспособленцу при вызове его методов.
Задача
Мы рассмотрим как это улучшить на конкретном примере. О биовычислениях буду говорить очень мало — но пример будет построен на этом. Суть биовычислений попытаюсь полностью вытравить, оставив только схему.
Предыстория
Сразу извиняюсь за сложность, но сложна как сама ситуация для применения этого, так и способ решения, но получается в результате красиво и эффективно :)
Началось с того, что описал одну проблемку о проблемах ООП. Потом случайно благодаря разговорам тут начал обдумывать паттерны проектирования. И в связи с темой «полное копирование объекта» вышел на паттерн Flyweight. Кто не знает — прошу вначале читайте о нем в Приемы объектно-ориентированного проектирования. Паттерны проектирования (Не в вики, а в оригинале).
Основная идея там такова:
Паттерн Flyweight описывает, как совместно разделять очень мелкие объекты без чрезмерно высоких издержек. Каждый объект-приспособленец имеет две части: внутреннее и внешнее состояния. Внутреннее состояние хранится (разделяется) в приспособленце и состоит из информации, не зависящей от его контекста. Внешнее состояние хранится или вычисляется объектами-клиентами и передается приспособленцу при вызове его методов.
Задача
Мы рассмотрим как это улучшить на конкретном примере. О биовычислениях буду говорить очень мало — но пример будет построен на этом. Суть биовычислений попытаюсь полностью вытравить, оставив только схему.
P.S. Если кому то интересна проблематика самих биовычислений по задаче сворачивания РНК/белков — делайте заказ напишу тогда отдельную статью.
Предыстория
Статья Неверное использование паттерна проектирования «Мост» / «Bridge» как то так получилось разделила аудиторию на двое. Далее я подумал, сказав А не сказать Б, будет не правильно. Нет я не отказываюсь от своих слов, но я нашел где и как я использовал паттерн «Мост». Т.к. его еще и неверно понимают, кажется альтернативное название «Описатель/тело» — меньше вводит в заблуждение.
Так где же? Оказалось в моем аналоге использования концепции MVC (Модель/Представление/Контроллер).
Поэтому вначале ознакомлю со своей вариацией «Бизнес-сущность — Визуализация — Контроллер». Я уже ее писал, но думаю мало кто с этим знаком. А затем посмотрим где же там «Правильный мост».
P.S. Мне тут выдали кредит доверия, и я обязался написать еще одну статью о усовершенствовании паттерна Flyweight — помню, пишу, надеюсь смогу опубликовать :)
Обсуждение многострадального шаблона Bridge на хабре, выявило много интересных мнений и заблуждений. Попробуем разобраться, реанимировать данный шаблон в глазах тех кто борется с формулировками оригинального каталога GoF, а интересующимся темой шаблонов показать несколько дополнительных штрихов.
«Мы не наделены даром предвидения, поэтому те, кто приписывает «банде четырех» экстраординарные способности, будут поражены хаотичностью нашего процесса разработки.»
Джон Влиссидес
«Когда мы писали нашу книгу, мы действительно пытались кое-чтоЧитать полностью »
Прочитав статью товарища tac, посвященную злополучному паттерну проектирования Bridge (от англ. — «Мост»), мне стало очень обидно и за Банду Четырех, чьи идеи были самым бессовестным образом осрамлены, и за сам паттерн, который был ужаснейшим образом дискредитирован в глазах менее опытных читателей. Не в силах больше смотреть на пылкие дебаты, разгорающиеся в комментариях, я решил спасти репутацию бедного паттерна, виновного лишь в том, что вот уже в который раз, он был неправильно истолкован.
Если вам еще не надоели статьиЧитать полностью »
Предистория
Я прочитал эту статью о паттерне проектирования «Мост». Увы, его очень часто используют не верно. Более того, я затем открыл книгу Приемы объектно-ориентированного проектирования. Паттерны проектирования. Оказалось и там авторы очень смутно декларируют причины его наличия и когда его использовать. Поэтому ниже я вам сообщу как и зачем подобное использовать.Что такое паттерн проектирования «Мост» на самом деле
Если знать объектно-ориентированное программирование, то со всей ответственностью заявляю, что знать о паттернах совершенно не обязательно. Паттерны это лишь частное, и не всегда самое удачное, решениеЧитать полностью »
