ООП *

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

Хотелось бы остановиться и посмотреть на развитие языков программирования с точки зрения развития пользовательских типов данных (ПТД).
Сразу хочу оговориться, под пользователями понимаются программисты, как люди, пишущие код на этих языках. Ну, и те, кто этот код сопровождает или просто читает.

Пользовательские типы данных — это типы данных, которые могут быть созданы пользователем на основе того, что доступно в языке.

Пользователи желают иметь примерно такие типы данных

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

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

В этой статье я попытаюсь поделиться своим опытом в проектировании пользовательской бизнес-логики. Это явно не претендует на полноценный ликбез, т.к. я всего лишь вспоминаю то, через что прошёл лично я, какие ошибки я допустил, и как мне их удалось (или не удалось) исправить в будущем. Наверняка, опытные системные архитекторы уже все проходили и знают, однако надеюсь, что некоторые советы таки будут полезны.
Мы использовали (и используем) клиентскую часть на WPF/Silverlight, WCF сервисы и СУБД Oracle, Postrges, MsSQL. Код написан по MVVM, использована Prism для модульности и навигации. Не могу точно сказать, какие из тезисов подойдут для других платформ и языков.

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

Итак, поехали.

Как всем известно, в lua нет как таковых классов и объектов. Однако есть метатаблицы и синтаксический сахар.
С помощью указанных механизмов достаточно просто реализовать подобие классов.
В итоге и получается нечто такое:

Всё это конечно хорошо, даже при определённой сноровке можно реализовать наследование…
Но где public и private члены класса? Дефакто в этом примере они все public. Да ещё и надо помнить, где использовать двоеточие:

MyClass:myFunc()

а где просто одну точку:

MyClass.myOtherFunc()

А статические члены класса? Неужели придётся отказываться?

Данный текст рассматривает вкратце особенности объектно-реляционного отображения (Object-Relational Mapping — ORM) и вводит новое понятие реляционного отображения коллекций (Collection-Relational Mapping — CoRM), предлагая обсудить перспективы и возможности технической реализации новой концепции долговременного хранения состояния объектов

Давно хотел написать на эту тему. Первым толчком послужила статья Miško Hevery "Static Methods are Death to Testability". Я написал ответную статью, но так и не опубликовал ее. А вот недавно увидел нечто, что можно назвать «Классо-Ориентированное Программирование». Это освежило мой интерес к теме и вот результат.

«Классо-Ориентированое Программирование» — это когда используются классы, состоящие только из статических методов и свойств, а экземпляр класса никогда не создается. В этой статье я буду говорить о том, что:

• это не дает никаких преимуществ по сравнению с процедурным программированием
• не стоит отказываться от объектов
• наличие статических членов класса != смерть тестам

Хотя эта статья про PHP, концепции применимы и к другим языкам.

Большинство фанатов ООП одновременно и фанаты полиморфизма. Многие хорошие книги (взять хотя бы «Рефакторинг» Фаулера) даже впадают в крайность и утверждают: если вы используете проверки типов во время выполнения (такие как операция instanceof в Java), то вы, скорее всего, в душе ужасный монстр. Из тех, что пугают маленьких детей операторами switch.

Вообще говоря, я признаю, что использование instanceof и его аналогов обычно является следствием недостаточных навыков ООП проектирования. Полиморфизм лучше проверок типов. Он делает код гибче и понятнее. Однако есть по крайней мере один распространенный случай, когда вы точно не сможете использовать полиморфизм. Причем случай этот распостранен настолько, что может уже считаться паттерном. Я бы с удовольствием применил в нем полиморфизм, честно. И если вы знаете как это сделать — расскажите мне. Но не думаю что это возможно. По крайней мере точно не в статических языках типа Java или C++.

Определение полиморфизма

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

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

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

Доброго времени суток, товарищи.

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

Проблема

Я занимаюсь разработкой ресурса для кросс-постинга в социальные сети. Изначально продукт был предназначен только для Вконтакте и Facebook и для работы с API было выделено по одному контроллеры и по одной модели, плюс модель для работы с cURL. Пока была необходимость работать только с двумя социальными сетями такая классовая структура проекта не выглядела удручающей. Но стоило добавить работу ещё с несколькими соц. сетями, стало очевидно что такая модель ведёт к хаосу и полному бардаку как на стороне работы с API так и на стороне клиента. Чего стоит ветвление из 10 else if для просмотра данных пользователя или 10 ajax запросов для отправки сообщений в социальные сети. Было принято решение отрефакторить весь этот ужас, воспользовавшись паттерном Фабрика. Всё представлялось просто: описываем интерфейс с общим функционалом работы с API, делаем фабричный класс и единственный контроллер, который будет реквайрить фабричный класс. Но как только начали переносить функционал на новую парадигму, нас осенило. Вся работа в бд, пользовательскими данными, логами и https держится на CI моделях и библиотеках. Тут то я понял как был неправ, когда писал в курсовой что CodeIgniter не накладывает ограничений на разработчика — ещё как накладывает. Стоит немного шагнуть в своём решении за рамки модели MVC, возникает проблема — как включить это решение в проект.

(Дата публикации оригинала — 12.04.2013)
Выбор JavaScript MVC фреймворка — тяжёлая работа. Нужно учесть много факторов, и число вариантов выбора может быть огромно. Достаточно взглянуть на проект ToDoMVC (о нем по-русски).

Я работал с 4 фреймворками: Angular, Backbone, CanJS и Ember. Поэтому решил сделать сравнение, чтобы помочь вам решить, какой из них использовать. Я выделю несколько факторов, которые вы можете использовать при выборе. Каждый фактор будет иметь оценку от 1 до 5 (больше — лучше). Я старался быть беспристрастным, но, конечно, оценки основаны на личном опыте.

Доброго времени суток!

Данный пост предназначен для новичков, начинающих разбираться с ООП на php, и старающихся действовать в соответствии с этим стилем.

Речь пойдет о расширении класса SoapClient(). Что это такое, и с чем его едят, вкупе с установкой — описано в этом посте.

Конкретно я задался вопросом работы с soap, когда на работе получил задачу о взаимодействии наших приложений с серверами заказчика. Т.к. большинство логики в наших приложениях написано в процедурном стиле, то и я изначально собирался запихнуть работу с soap в несколько функций. Но когда понял, что получается по меньшей мере — некрасиво, очень громоздко, и довольно-таки неудобно, решил расширить класс SoapClient.

Идея данной заметки — как гипотезы — появилась уже довольно давно, и все как-то не получалось… Но вот «на днях» (к моменту публикации — уже неделях) увидел подтверждение своего предположения что называется «из первых рук» (см. Kent Beck's answer to Unit Testing: Did the notion of using setup() and teardown() methods in test fixtures originate from JUnit?) и решил-таки воплотить эту задумку.

Эта статья — попытка ответить на вопрос 11-летнего олимпиадника: «Зачем нужны паттерны?» Ещё не отправил, выношу на общий суд и прошу любой критики. Цель — не дать исчерпывающий ответ, а вызвать новые вопросы.

Итак

Как учат программированию в школе? Вам дают формочки и учат делать куличики из песка. Это хорошо, надо ведь с чего-то начинать.

Боже, временами я просто ненавижу объектно-ориентированное программирование.

Наверное, я не один такой. Бессмертные слова Эдсгера Дейкстры гласят:

«Объектно-ориентрованное программирование — это исключительно плохая идея, которую могли придумать только в Калифорнии.”

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

Что-то вроде предисловия

Статья «Как два программиста хлеб пекли» сначала мне показалась просто шуткой — настолько абсурдно выглядят попытки выстроить какой-то «дизайн», основываясь на тех «требованиях», которые выдвигает «менеджер». Но в каждой шутке есть доля правды… В общем, возник вопрос к самому себе: а как в данной ситуации сработает тот подход, которого я стараюсь придерживаться в своей практике? То, что выросло при попытке дать ответ, собственно, и представлено далее.

Каждый раз когда речь заходит о Go приходится слышать один и тот же вопрос:

Является ли Go объектно-ориентированным языком?

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

Понадобилось мне прикрутить Lua к проекту на C++. Писать обертки в ручную — лень (слишком много писать), готовые не подходили по тем или иным причинам. Решил написать свою. А потому задался вопросом, как максимально упростить интерфейс? От одной только мысли об этом в голову лезли жутчайшие конструкции из шаблонов. Так оно в последствии и оказалось, но гораздо проще, чем представлялось.

В C++11 появились шаблоны с переменным числом аргументов, это позволяет писать шаблонные функции/классы так, как в C++03 было невозможно вовсе. Такие шаблоны сильно упрощают задачу.

Первым делом понадобилось написать обертку над простейшими действиями с интерпретатором (можно было бы обойтись простыми вызовами к C API Lua, но держать в памяти кучу индексов различных значений в стеке мне не хочется. Поэтому я обернул их в несколько функций, которые помимо того, что избавляют от необходимости передавать в каждую функцию указатель на состояние интерпретатора, практически не требуют индексов, так как они имеют значения по умолчанию.

В итоге хотелось увидеть интерфейс близкий к следующему:

lua.export_function(some_function);

Многие фреймворки любят магию и сложные многоуровневые массивы для передачи параметров. Что первое, что второе — зло с точки зрения истинно-ленивого программера, который любит IDE и доки всегда под рукой, а не тыкать в интернет/тело вызываемого метода. Мы можем победить это, как образец взяв параметры метода из одного фреймворка и создав ООП-билдер.

Доброго времени суток. Предлагаю вашему вниманию вторую статью из цикла о Low Level Smalltalk (LLST). Кто не в курсе о чем идет речь, тем рекомендую прочитать предыдущую, обзорную статью, где рассказывается о том, что такое llst и зачем он был создан.

В этой части мы сконцентрируемся на самом языке Smalltalk, его синтаксисе и «правилах игры».

В последующих частях мы плавно перейдем к особенностям реализации виртуальной машины и внутреннему представлению объектов в памяти. Затронем вопросы организации менеджера памяти и сборщика мусора. Поговорим мы и о байткодах виртуальной машины. Узнаем, как текст метода Smalltalk превращается в последовательность команд. Наконец, мы проследим путь от загрузки образа в память машины до процессов, происходящих при посылке сообщений между объектами, а так же узнаем как реализуются замыкания в блоках.