В настоящий момент я не могу придерживаться утверждения обозначенного в заголовке к данной теме.
Ребята из гугл тим, завалили службу маппинга имен для app engine && sites. Старый сломанный мапинг, удалить нельзя, а новый нельзя добавить. И все случилось под новый год!!!
Моя страничка www.axet.ru лежит с 18 декабря (возможно 18-24 судя по статистики с google analytics).
http://www.google.com/support/forum/p/Google+Apps/thread?fid=6421087ef73ca90a00047bcc2829fe1c&hl=en
среда, 30 декабря 2009 г.
вторник, 22 декабря 2009 г.
Rhythmbox shoutcast
Если кто то хотел запустить шут-каст радио на своем линукс-rhythmbox плеере, а такого плагина не смог найти. То теперь эта мечта может осуществится. Я набросал пару строчек и теперь они выложены в интернете как плагин для этого плеера.
Версия совсем сырая, не доработан интерфейс, нету ни какого обновления\сохранения плей листов скаченных с сервера, но со своей основной функцией он уже сейчас справляется.
Если мне будет очень скушно, напишу еще немного кода и сделаю нормальный интерфейс.
Адрес сайта: http://code.google.com/p/rhythmbox-shoutcast/
Версия совсем сырая, не доработан интерфейс, нету ни какого обновления\сохранения плей листов скаченных с сервера, но со своей основной функцией он уже сейчас справляется.
Если мне будет очень скушно, напишу еще немного кода и сделаю нормальный интерфейс.
Адрес сайта: http://code.google.com/p/rhythmbox-shoutcast/
четверг, 17 декабря 2009 г.
Обман GoF (В сокращении)
Понимаю нежелание читать огромные тексты. Поэтому приведу тут сокращенный вариант.
1. В книге постоянно путаются базовые определения. Классы называются объектами, объекты на памяти интсанциированными классами и вперемешку между собой. Такой подход очень сильно путает начинающего читателя, который может подумать что так оно и есть. И еще больше запутаться, в место того что бы наводить порядок в своей голове.
2. В книге дается не достаточно конкретные инструкции о правилах применения паттернов. Что в свою очередь, так же сильно усложняет материал для начинающего программиста разобраться в том что же это такое паттерн, и когда его надо приминять.
3. Книга не отвечает на вопросы качественной разработки, и реюз кода. Они создают обратное явление направленное на рождение кода, и акцентирование внимание только на объектной модели на памяти.
4. Авторы книги создали культ программирования объектов на памяти, вместо программирования кодом. В результате получается не читаемый проект не подверженный статистическому анализу.
В статье я даю некоторый анализ этих действий и причин приведших к образованию указанных явлений. Кроме того, даю некоторые советы.
1. В книге постоянно путаются базовые определения. Классы называются объектами, объекты на памяти интсанциированными классами и вперемешку между собой. Такой подход очень сильно путает начинающего читателя, который может подумать что так оно и есть. И еще больше запутаться, в место того что бы наводить порядок в своей голове.
2. В книге дается не достаточно конкретные инструкции о правилах применения паттернов. Что в свою очередь, так же сильно усложняет материал для начинающего программиста разобраться в том что же это такое паттерн, и когда его надо приминять.
3. Книга не отвечает на вопросы качественной разработки, и реюз кода. Они создают обратное явление направленное на рождение кода, и акцентирование внимание только на объектной модели на памяти.
4. Авторы книги создали культ программирования объектов на памяти, вместо программирования кодом. В результате получается не читаемый проект не подверженный статистическому анализу.
В статье я даю некоторый анализ этих действий и причин приведших к образованию указанных явлений. Кроме того, даю некоторые советы.
четверг, 10 декабря 2009 г.
Обман GoF (Книга)
При выборе новой темы для журнала, или новой книги для изучения я стараюсь придерживаться простого правила: если материал в книге кажется абсурдным, мало информативным или ложном этот материал не достоин упоминания в моем журнале. Таким образом, можно добиться повышение общего качества материалов доступных в сети. Чем меньше будет ссылок на ерунду, тем быстрей про не забудут. Поэтому я не пишу (стараюсь) про дураков, глупости и авторские фантазии, что бы про них быстрей забыли или вообще не узнали.
Однако, сегодня я сделаю исключение. И напишу об одной такой книге, которую считаю полностью недостойной внимания. Во всяком случае считаю не допустимым базированию обучения по шаблонному (паттерному) программированию на этой книжке. Хоть на мой взгляд эта книжка просто напичкана такими липовыми определениями, и ее содержимое (шаблонное программирование) лучше изучать по другим источникам. Но в силу ее популярности, считаю нужным поместить информацию на нее в своем журнале. Дело в том, что эта книга является чуть ли не библией некоторых горе разработчиков, которые стараются скакать по звонким, лишенным сути технологиям тем самым приукрашивая свои липовые наработки.
Я говорю об достаточно известном труде, который мне достался в переводе А. Слинкина. Книга называется "Приемы объектно-ориентированного проектирования Паттерны проектирования". Иначе известная как GoF (Gang of Four) (Design Patterns Elements of Reusable Object-Oriented Software).
Конечно, я сделаю небольшую оговорку, я читал именно перевод на русский. Оригинал возможно не содержал таких серьезных ошибок. И возможно я буду напрасно строчить тексты указывающие на недочеты. Но не смотря на возможные опусы перевода, в книге встречаются целые абзацы, содержимое которых у меня взывает откровенное возмущение. Поэтому нахожу важным поделится своим мнением, возможно эти выводы помогут кому-то не сделать ошибок в самом начале в выборе заведомо ложных утверждений. Что в последствии может привести к ловинному образованию ложного комка понятий, которые ни как не смогут выстроится в правильном направлении.
Итак разберемся с понятиями, которые являются фундаментом для понимания книги.
Ворох терминов используемых не согласованно и часто не правильно, будут только усугублять содержимое, которое выстраивается поверх обозначенных примитивов. Объект, класс, экземпляр класса, совсем забытое и почти не встречающееся, но не менее важное: среда исполнения - все это вместо четко обозначенных значений слов, превращается прямо на глазах у читателя в кашу взаимозаменяемых терминов.
В книге нету четкого определения основных терминов, которые они используют. Давайте их перечислим, с правильным вложенным в них смысла:
Что, кстати, относится к определению объекта, которое не правильно дается в книги, объекта как совокупность данных и функций. Это определение было прочитано авторами из какого-то космического триллера, современной попсовой литературы. Понятие объекта никогда не включало алгоритмы их обрабатывающие. Особенно это имеет отношение к С++, о котором они пишут. Почему? Если сказать просто, то вы одним определением переменной можете обратиться к любым данным и любой области памяти просто определив A* a; на желаемую область памяти и работать с ней. Что подтверждает что данные на которые указывает класс, есть нечто абстрактное то, что посчитал разработчик данными.
Далее необходимо вспомнить, что процесс заполнения С++ шаблонов типами называется не созданием объекта, а инстанциацией класса. А результирующая сущность - классом или инстанциированным классом. Понятие же объекта может использоваться только к куску памяти, инициализированному в среде исполнения.
На мой взгляд "дизайн паттерн", это еще одна революционная идея, которая была искусственна привита и раздута в первую очередь для бизнеса, помогающая делать из процесса разработки показуху. В редких случая помогает разработчикам лучше представлять о том, как необходимо работать с данными.
Я находил подобную концепцию в среде КОБРА (CORBA). Когда цель разработки сделать не код эффективным, а управление процессом разработки. Сделав предсказуемый результат по времени и по приемлимому качеству в разработке вы напроч убиваете эффективное решение. Видимо этот заразный подход проник и в С++. Автор языка которого, был на как раз на стороне тврческих людей, изобретая творческий красивый язык в котором было бы приятно работать.
И еще раз я хочу уточнить, что не плохо когда каждый человек это маленький винтик в процессе. Плохо когда этот винтик ничего не значит и ничего не понимает. В этом случае его легко обмануть и сделать из него дойную корову, забыв напрочь про идею и вообще живых людей.
Я вообще много раз говорил о том, что новое в программирование это забытое старое (и один раз сказал в совсем журнале, в черновике "Это не история повторяется..."). Так те люди, которые придумали новую концепцию в программирование и стали супер-звездами рассказав миру про MVC (дизайн паттерн работы с данными, где данные отделяются от метода их отображения и алгоритмами обрабатывающими их), совсем не такие современные. На самом деле, эти ребята были двоечниками-маркетологами, которые вообще не знали, что такое машина Тьюринга и то, что она на этих принципах и работает.
То есть то, что было прародителем всех современных компьютеров, уже давно в себе содержало основное определине разделения данных (ленты) и их механизма работы с ним (то что читает и мотает ленту). За то теперь, мы можем легко показать заказчикам концепцию на которой строется наша система, показать решения которые используются для ее построения, показать группу разработчиков включая архитектора, программиста, администратора, менежера и еще пачку людей из общего процесса. То в таком случае гораздо проще получить бюджет, чем показать одного программиста строчащего прозрачный код на лету.
Не надо смотреть на меня косо, я не говорю что у такого подхода есть одни минусы. Я говорю о том, что страшно, когда мы сидящие напротив мониторов и вбивающие *((void*)0)=0 не хотим понимать, как создается модель разработки и, что за профессия такая, давать безполезные советы с названием "Системного архитектора". И я хочу показать эту профессию в ее естественном, не извращенном бизнесом, понятии.
Бизнес говорит, ваш Хумен ресурс говорит, ваш менеджер говорит, что надо работать как надо, и никто не понимает, что нужно делать на самом деле. А я хочу пролить свет на эту пролему, убрать это однобокое всоприятие обязанностей и задач и начать наконце концов работать вместе. Работать командой которая понимает свои функции, природу решения задачи свойственной не только бизнес решениям, но и адаптированию их на уровне среды исполнения (эффективных дизайн паттернов, в отношении этой самой среды), а не тупо дает возможность зарабатываеть денег владельцу компании. Ведь когда каждый участник процесса понимает свои и обязанности своего товарища, команда легко видит халтуру и халтурщиков, прикрывающихся звонкими формулами.
Сейчас я хочу разрушить миф об "Дизайн паттернах".
Начнем с плюсов. Вернее с тех определений которые, выдвигаются в пользу мнимых преимуществ, от использования дизайн паттернов.
Я ни коим образом не могу согласится с определением "повторного использования кода" данного авторами в книге. Авторы утверждают, что повторным использованием является наследование классов и при том же не является использование библиотечных функций. То есть, если вы унаследовались от класса, то вы повторно используете функции это класса. Вопрос: зачем тогда наследовать если вам просто нужна таже самая логика? Если вы используете функции класса работы с данными, то вы должны создать экземпляр этого класса и работать с данными методами этого класса. То есть просто создать его экземпляр на памяти (объект). И в том что вы создали объект, никакого повторного использования кода нет и быть не может. Ведь когда вы вызываете системную функцию для выделения памяти вы не повторно используете системную функцию вызова памяти. Другими словами ведь из за того что вам на ум не пришло писать свои функции работы с памятью, вы не можете утверждать, что экономите уже написанный код.
Видимо авторы хотят указать на другой аспект наследования - оно нужно, что бы переопределить логику объекта. То есть изменить концепцию работы класса с данными. Или иначе: сделать подстановку новой реализации.
Если же говорить об повтором использовании, то это целая вереница условий: атомарность функций, классов, отсутствие глоабльных объектов и фиговин так любимых горе-дизайн-паттер разработчиками называемыми Сингелтон (еще один гвоздь, почему дизайн паттерн плох).
Соответственно, речь о том что с помощью паттернов повторное использование кода увеличивается это утверждение не имеет силы. Паттерны придуманы для того что бы облегчить коллективное производство, соогласование действий в случае одновременного создания большого объема кода уменьшает это самое повторное использование. Во вторых, уже упомянутый Сингельтон, ставит вообще крест на наследовании и повтороном использовании кода, так как переопределение таких конструкций вообще не возможно.
Авторы демонстрируют пример наследования, у которого в недостатоках указывается наследование и отсутсвие возможнсти для переопределния иерархии наследования вовремя выполнения. Такую конструкцию лучше себе вообще не представлять перед сном. А как аргумент в пользу шаблонов проектирования, такой апофеоз вообще стыдно предъявлять.
Видимо этот вывод не спешно делается из авторских утверждений о том, что код должен быть сам по себе, а объекты на памяти сами по себе. В результате получить не читаемый код, с множество виртуальных конструкций-объектов на памяти. Автор хочет показать что его орлиный взор, способен заниматься отладкой таких воздушных замков?
Лишний раз идет подтверждение о том что создается не продукт, готовый к использованию. А создается бизнес решение для высасывания денег на поддержку виртуальной среды построенной на блестящих дизайн паттерн идеях. Конечно бизнес не виноват, он живет по правилам которые придумал не он, а государство - ему надо зарабатывать рубль. И программист не виноват он написал по заданию. И архитектор не виноват, который нарисовал пару десятков дизайн-паттернов на доске делал это по этой вот книжке. Просто в этой истории все вместе, тихо погружаются в абсурд ни кто не задаваясь вопросом: "а хорошо ли это?"
Большинство материалов так или иначе связанных с дизайн паттернами, это описание воздушных проблем, созданных не для решения зачад программирования, а для описание процессов которые могут происходить внутри приложения. И самое важное, что необхдимо помнить - писать так ненадо!
Не буду танцевать дальше на абсурде тех утверждений и предлагать в таком случае яву машину, или реализацию виртуальной машины на С++, или использование RTTI или перевод проекта на python. Речь об эффективном программирование а не об мистических возможностях той или иной среды (да в указанных мной средах возможно изменять наследование при приложении определенной доли усилий).
Я задам вопрос по другому, вы вообще зачем пишите такой код, который должен на лету быть пересобран? Задача программирования создать простой эффективный код, который бы удовлетворял принципам повторного использования. Код должен быть читаем без документации, без коментариев и быть понятен с первых минут его использования. А в парадигмах С++, код должен быть типизирован. То есть вообще отсутствовать какой либо намек на виртуализацию среды.
Если же придерживаться тех идей, на которых построена эта книга - пиши код, и думай об объектах, то код такой и выйдет - черти прочтешь его без многолетней тренировки в абстракциях из этой книги. Это что то вроде розовых очков, один раз написав такой код в очках, другой разработчик тоже должен их надеть (купить предварительно) что бы разобраться в нем.
Следующий аргумент-паттерн, активно рекламируемый на страницах книжки есть Абстрактная фабрика. Это шаблон вообще унижение для С++. Язык в котором есть идеальное понятие класса, оптимизируемого для конкретного процессора и создающего оптимизрованный код путем инстанциирования шаблона не может идти в сравнение с ущербной абстрактной фабрикой родившейся в виртуальной машине. Постораюсь объяснить простым языком.
Любой инстациированный класс из шаблона, образует набор самостоятельных классов с независимой реализаций. В результате чего, компилятор образует из них независимый объектный код, который в свою очередь оптимизируется процессором. Следовательно, любой параметр шаблона, будет индивидуально оптимизирован для процессора. А если этот параметр, является объектом (в этом случае java или C# generics отдыхают, так как поддерживают только примитивы) то это понятие объекта оптимизируется для процессора. Что является вообще уникальным явлением на сегодняшний день.
В определении даваемым в книге понятию дизайн паттерн, очень близко и родственно стоит понятие интерфейса. К сожалению, авторы книги делают лже-утверждение, на котором сыпятся множество разработчиков начиная писать абстрактный код перегруженный определением абстрактных конструкций. Нельзя говорить об отделении реализации не дав четких условий ее появлению. То есть нельзя говорить используйте интерфейсы у классов потому что вы получите масштабируемый проект. Это ерунда.
СОВЕТ 1
Такими простыми определениями вы только убьете проект. К сожалению другого определения авторы не дали. А я дам! Создавайте интерфейс, когда вы хотите скрыть реализацию в библиотеках (продаваемых, отдаваемых на сторону), когда вы хотите делать две реализации одного и того же алгоритма, и когда у вас появляется класс со схожей природой (два одинаковых класса).
Еще раз хочу обратить внимание, что наследование реализаций это хороший код, в противовес тому утверждению, которое дается в книги. Плохо не наследовать реализацию класса, а не понимать что вы делаете.
СОВЕТ2
На что я хотел бы обратить внимание. Старайтесь записывать свои мысли (кодом), их проще оценить, исправить и отладить. Я вооще сторонник другого стиля разработки, его смысл в создании групп разработки базирующейся на потребоностях бизнеса, но не эксплуатирующий яркие конструкции. Я уверен, и знаю такую модель разработки , при которой программисты создают код, читаемый без специальных знаний, качественный, интересный и не пергруженный конструкциями которые требуют не только специальных сред разработки но и горы бесполезных знаний затмевающих основную цель - создание эффективного кода.
К сожалению, это тоже довольно большой кусок размышений и я его не буду рассматривать в этой стате. Однако это не просто размышлизм, такие примеры есть - это открыте разработки. Это открыте конструкции, посмотрите как они это делают и вы поймете о чем я говорю.
Так вот если вы начнете писать то что думате в коде, а не создавать воздушные замки. То код у вас будет выглдить по тем дизайн паттернам, рассмотреным в книге. Но написан он будет не на памяти а в коде ввиде конструкций наследования, шаблонов, интерфейсов.
СОВЕТ3
Несмотря на общую критику и безалаберный подход заложенный в концепции. Я нахожу очень интересным пример использования шаблонов проектирования на примере текстового редактора рассмотренного в книге. Хоть и рассмотренная в начале книги шаблонная техника не выдерживает ни какой критики, сами по себе они пишут не так плохой код.
Если конечно не замечать таких ляпов как образование новых типов-строк. Это продолжение начатой авторами темы об всеобщей виртуализации, к которой так неудержно смотремится банда четырех.
Писать в коде конструкции strcmp(nameName, "Value") все равно что образовывать новый тип данных. Язык С++, это прежде всего язык типов, и компилятор делает работу за вас только в том случае, если вы этой парадигмы придерживаетесь. И если вы не ходите дубировать код (как раз в этом месте можно использовать термин повторное использование кода) то вам необходимо отказываться от строчек на этапе обработки данных от пользователя.
Так создавая новый тип const char* value = "Motif"; не забудьте создать одноименный класс и switch функцию, обеспечивающую создание одноименного объекта-свойсва на памяти. Хотя бы уж enum.
Необходимо заметить одну особенность изложения материала авторами. Банда четырех большие сторонники виртуализации и работы на памяти (с37). Парадигма, когда код становится несущественнным и менее приоритетным чем объект на памяти. Этим самым при чтении книги вас всегда подталкивают использовать паттеры как часть их концепции использующих память как ресурс. Тем самым как я уже говорил они создают воздушный замок, не читаемый сторонним наблюдателем. Отладка такой среды в разы трудней, так как вам необходима среда отладки с мощной системой визуализации.
Другими словами, эти ребята писали код только под Microsot Visual Stidio.
Хоть это и отдельная тема, которую я бы с удовольствием рассмотрел в отдельной статье. Я скажу пару слов и тут. Почему это интересно и большой объем для исследования? Приведу пример, вы никогда не задумывалиь почему большинство проектов под Линукс написано на простом плоском и могучем GObject (Objective-C)? Ответ простой: невозможно отлаживать виртуальный бред с кучей наследований на памяти. Но это нужно рассматривать подробней, в следующий раз...
Основной мыслью, которую продвигают авторы книги сводится исключительно к работе с объектом на памяти. И все разговоры о том, что проект с испльзованием паттернов предполагает повторное использование, гибкость в модификации это всего лишь заблуждение авторов. Нельзя решить все проблемы в проекте, введя полную свободу в работу с объектом (с38). Утверждая что код не значит ничего, а виртуальная среда - все, меняя объект на памяти, а не в коде они получают виртуальную машину, а не язык паттернов. Это очень серезное заблуждение и ошибка приводящая к развалу проекта. Этот принцип, закрытости логических конструкций и перевод их в виртуальную среду (память) усложняет процесс отладки и в корне лишает возможности проводить аналитический анализ исходного кода.
Этот вывод подтерждает тот факт, что код это лишь отображение объектов и он имеет маленькую значимость (с37), то что с наследование на памяти нельзя переопределить (с38).
Из чего я делаю вывод, что все паттерны представленные в этой книге работающие с памятью это всего лишь плод воображения авторов считающих что язык их ограничивает. Таким путем были созданы не одни среды и новые языки, которые в полсдествии вернулись или постепенно начали возвращатся (к типизации, интерфейсам, шаблонам) к паратигмам С++. И эти структуры имеющют отношения к серезной разработке, и созданию качественного продукта. Абстрактные фабрики и другие паттерны, нуждающиеся в создании неконтролируемых структур, нужны в исключительных случаях, и за частую вносят большие затрудения в анализ исходного кода и повторное его использование.
Я ожидают, что в скором времени эти ребята создадут новый язык, без типов, интерфейсов, без наследования и с возможностью переопределять любой метод любого класса. Конечно, такие среды уже есть, но как я уже сказал, все новое это хорошо забытое старое и авторы движутся именно по этому пути. Не делайте их ошибок!
Однако, сегодня я сделаю исключение. И напишу об одной такой книге, которую считаю полностью недостойной внимания. Во всяком случае считаю не допустимым базированию обучения по шаблонному (паттерному) программированию на этой книжке. Хоть на мой взгляд эта книжка просто напичкана такими липовыми определениями, и ее содержимое (шаблонное программирование) лучше изучать по другим источникам. Но в силу ее популярности, считаю нужным поместить информацию на нее в своем журнале. Дело в том, что эта книга является чуть ли не библией некоторых горе разработчиков, которые стараются скакать по звонким, лишенным сути технологиям тем самым приукрашивая свои липовые наработки.
Я говорю об достаточно известном труде, который мне достался в переводе А. Слинкина. Книга называется "Приемы объектно-ориентированного проектирования Паттерны проектирования". Иначе известная как GoF (Gang of Four) (Design Patterns Elements of Reusable Object-Oriented Software).
Конечно, я сделаю небольшую оговорку, я читал именно перевод на русский. Оригинал возможно не содержал таких серьезных ошибок. И возможно я буду напрасно строчить тексты указывающие на недочеты. Но не смотря на возможные опусы перевода, в книге встречаются целые абзацы, содержимое которых у меня взывает откровенное возмущение. Поэтому нахожу важным поделится своим мнением, возможно эти выводы помогут кому-то не сделать ошибок в самом начале в выборе заведомо ложных утверждений. Что в последствии может привести к ловинному образованию ложного комка понятий, которые ни как не смогут выстроится в правильном направлении.
Итак разберемся с понятиями, которые являются фундаментом для понимания книги.
Ворох терминов используемых не согласованно и часто не правильно, будут только усугублять содержимое, которое выстраивается поверх обозначенных примитивов. Объект, класс, экземпляр класса, совсем забытое и почти не встречающееся, но не менее важное: среда исполнения - все это вместо четко обозначенных значений слов, превращается прямо на глазах у читателя в кашу взаимозаменяемых терминов.
В книге нету четкого определения основных терминов, которые они используют. Давайте их перечислим, с правильным вложенным в них смысла:
- класс - код описывающий поведение объекта с данными
- объект - экземпляр класса на памяти в среде исполнения
- реализация объекта - код отвечающий определению объекта
- среда исполнения - среда подключенная к среде исполнения, библиотекам и операционной системе.
Что, кстати, относится к определению объекта, которое не правильно дается в книги, объекта как совокупность данных и функций. Это определение было прочитано авторами из какого-то космического триллера, современной попсовой литературы. Понятие объекта никогда не включало алгоритмы их обрабатывающие. Особенно это имеет отношение к С++, о котором они пишут. Почему? Если сказать просто, то вы одним определением переменной можете обратиться к любым данным и любой области памяти просто определив A* a; на желаемую область памяти и работать с ней. Что подтверждает что данные на которые указывает класс, есть нечто абстрактное то, что посчитал разработчик данными.
Далее необходимо вспомнить, что процесс заполнения С++ шаблонов типами называется не созданием объекта, а инстанциацией класса. А результирующая сущность - классом или инстанциированным классом. Понятие же объекта может использоваться только к куску памяти, инициализированному в среде исполнения.
На мой взгляд "дизайн паттерн", это еще одна революционная идея, которая была искусственна привита и раздута в первую очередь для бизнеса, помогающая делать из процесса разработки показуху. В редких случая помогает разработчикам лучше представлять о том, как необходимо работать с данными.
Я находил подобную концепцию в среде КОБРА (CORBA). Когда цель разработки сделать не код эффективным, а управление процессом разработки. Сделав предсказуемый результат по времени и по приемлимому качеству в разработке вы напроч убиваете эффективное решение. Видимо этот заразный подход проник и в С++. Автор языка которого, был на как раз на стороне тврческих людей, изобретая творческий красивый язык в котором было бы приятно работать.
И еще раз я хочу уточнить, что не плохо когда каждый человек это маленький винтик в процессе. Плохо когда этот винтик ничего не значит и ничего не понимает. В этом случае его легко обмануть и сделать из него дойную корову, забыв напрочь про идею и вообще живых людей.
Я вообще много раз говорил о том, что новое в программирование это забытое старое (и один раз сказал в совсем журнале, в черновике "Это не история повторяется..."). Так те люди, которые придумали новую концепцию в программирование и стали супер-звездами рассказав миру про MVC (дизайн паттерн работы с данными, где данные отделяются от метода их отображения и алгоритмами обрабатывающими их), совсем не такие современные. На самом деле, эти ребята были двоечниками-маркетологами, которые вообще не знали, что такое машина Тьюринга и то, что она на этих принципах и работает.
То есть то, что было прародителем всех современных компьютеров, уже давно в себе содержало основное определине разделения данных (ленты) и их механизма работы с ним (то что читает и мотает ленту). За то теперь, мы можем легко показать заказчикам концепцию на которой строется наша система, показать решения которые используются для ее построения, показать группу разработчиков включая архитектора, программиста, администратора, менежера и еще пачку людей из общего процесса. То в таком случае гораздо проще получить бюджет, чем показать одного программиста строчащего прозрачный код на лету.
Не надо смотреть на меня косо, я не говорю что у такого подхода есть одни минусы. Я говорю о том, что страшно, когда мы сидящие напротив мониторов и вбивающие *((void*)0)=0 не хотим понимать, как создается модель разработки и, что за профессия такая, давать безполезные советы с названием "Системного архитектора". И я хочу показать эту профессию в ее естественном, не извращенном бизнесом, понятии.
Бизнес говорит, ваш Хумен ресурс говорит, ваш менеджер говорит, что надо работать как надо, и никто не понимает, что нужно делать на самом деле. А я хочу пролить свет на эту пролему, убрать это однобокое всоприятие обязанностей и задач и начать наконце концов работать вместе. Работать командой которая понимает свои функции, природу решения задачи свойственной не только бизнес решениям, но и адаптированию их на уровне среды исполнения (эффективных дизайн паттернов, в отношении этой самой среды), а не тупо дает возможность зарабатываеть денег владельцу компании. Ведь когда каждый участник процесса понимает свои и обязанности своего товарища, команда легко видит халтуру и халтурщиков, прикрывающихся звонкими формулами.
Сейчас я хочу разрушить миф об "Дизайн паттернах".
Начнем с плюсов. Вернее с тех определений которые, выдвигаются в пользу мнимых преимуществ, от использования дизайн паттернов.
Я ни коим образом не могу согласится с определением "повторного использования кода" данного авторами в книге. Авторы утверждают, что повторным использованием является наследование классов и при том же не является использование библиотечных функций. То есть, если вы унаследовались от класса, то вы повторно используете функции это класса. Вопрос: зачем тогда наследовать если вам просто нужна таже самая логика? Если вы используете функции класса работы с данными, то вы должны создать экземпляр этого класса и работать с данными методами этого класса. То есть просто создать его экземпляр на памяти (объект). И в том что вы создали объект, никакого повторного использования кода нет и быть не может. Ведь когда вы вызываете системную функцию для выделения памяти вы не повторно используете системную функцию вызова памяти. Другими словами ведь из за того что вам на ум не пришло писать свои функции работы с памятью, вы не можете утверждать, что экономите уже написанный код.
Видимо авторы хотят указать на другой аспект наследования - оно нужно, что бы переопределить логику объекта. То есть изменить концепцию работы класса с данными. Или иначе: сделать подстановку новой реализации.
Если же говорить об повтором использовании, то это целая вереница условий: атомарность функций, классов, отсутствие глоабльных объектов и фиговин так любимых горе-дизайн-паттер разработчиками называемыми Сингелтон (еще один гвоздь, почему дизайн паттерн плох).
Соответственно, речь о том что с помощью паттернов повторное использование кода увеличивается это утверждение не имеет силы. Паттерны придуманы для того что бы облегчить коллективное производство, соогласование действий в случае одновременного создания большого объема кода уменьшает это самое повторное использование. Во вторых, уже упомянутый Сингельтон, ставит вообще крест на наследовании и повтороном использовании кода, так как переопределение таких конструкций вообще не возможно.
Авторы демонстрируют пример наследования, у которого в недостатоках указывается наследование и отсутсвие возможнсти для переопределния иерархии наследования вовремя выполнения. Такую конструкцию лучше себе вообще не представлять перед сном. А как аргумент в пользу шаблонов проектирования, такой апофеоз вообще стыдно предъявлять.
Видимо этот вывод не спешно делается из авторских утверждений о том, что код должен быть сам по себе, а объекты на памяти сами по себе. В результате получить не читаемый код, с множество виртуальных конструкций-объектов на памяти. Автор хочет показать что его орлиный взор, способен заниматься отладкой таких воздушных замков?
Лишний раз идет подтверждение о том что создается не продукт, готовый к использованию. А создается бизнес решение для высасывания денег на поддержку виртуальной среды построенной на блестящих дизайн паттерн идеях. Конечно бизнес не виноват, он живет по правилам которые придумал не он, а государство - ему надо зарабатывать рубль. И программист не виноват он написал по заданию. И архитектор не виноват, который нарисовал пару десятков дизайн-паттернов на доске делал это по этой вот книжке. Просто в этой истории все вместе, тихо погружаются в абсурд ни кто не задаваясь вопросом: "а хорошо ли это?"
Большинство материалов так или иначе связанных с дизайн паттернами, это описание воздушных проблем, созданных не для решения зачад программирования, а для описание процессов которые могут происходить внутри приложения. И самое важное, что необхдимо помнить - писать так ненадо!
Не буду танцевать дальше на абсурде тех утверждений и предлагать в таком случае яву машину, или реализацию виртуальной машины на С++, или использование RTTI или перевод проекта на python. Речь об эффективном программирование а не об мистических возможностях той или иной среды (да в указанных мной средах возможно изменять наследование при приложении определенной доли усилий).
Я задам вопрос по другому, вы вообще зачем пишите такой код, который должен на лету быть пересобран? Задача программирования создать простой эффективный код, который бы удовлетворял принципам повторного использования. Код должен быть читаем без документации, без коментариев и быть понятен с первых минут его использования. А в парадигмах С++, код должен быть типизирован. То есть вообще отсутствовать какой либо намек на виртуализацию среды.
Если же придерживаться тех идей, на которых построена эта книга - пиши код, и думай об объектах, то код такой и выйдет - черти прочтешь его без многолетней тренировки в абстракциях из этой книги. Это что то вроде розовых очков, один раз написав такой код в очках, другой разработчик тоже должен их надеть (купить предварительно) что бы разобраться в нем.
Следующий аргумент-паттерн, активно рекламируемый на страницах книжки есть Абстрактная фабрика. Это шаблон вообще унижение для С++. Язык в котором есть идеальное понятие класса, оптимизируемого для конкретного процессора и создающего оптимизрованный код путем инстанциирования шаблона не может идти в сравнение с ущербной абстрактной фабрикой родившейся в виртуальной машине. Постораюсь объяснить простым языком.
Любой инстациированный класс из шаблона, образует набор самостоятельных классов с независимой реализаций. В результате чего, компилятор образует из них независимый объектный код, который в свою очередь оптимизируется процессором. Следовательно, любой параметр шаблона, будет индивидуально оптимизирован для процессора. А если этот параметр, является объектом (в этом случае java или C# generics отдыхают, так как поддерживают только примитивы) то это понятие объекта оптимизируется для процессора. Что является вообще уникальным явлением на сегодняшний день.
В определении даваемым в книге понятию дизайн паттерн, очень близко и родственно стоит понятие интерфейса. К сожалению, авторы книги делают лже-утверждение, на котором сыпятся множество разработчиков начиная писать абстрактный код перегруженный определением абстрактных конструкций. Нельзя говорить об отделении реализации не дав четких условий ее появлению. То есть нельзя говорить используйте интерфейсы у классов потому что вы получите масштабируемый проект. Это ерунда.
СОВЕТ 1
Такими простыми определениями вы только убьете проект. К сожалению другого определения авторы не дали. А я дам! Создавайте интерфейс, когда вы хотите скрыть реализацию в библиотеках (продаваемых, отдаваемых на сторону), когда вы хотите делать две реализации одного и того же алгоритма, и когда у вас появляется класс со схожей природой (два одинаковых класса).
Еще раз хочу обратить внимание, что наследование реализаций это хороший код, в противовес тому утверждению, которое дается в книги. Плохо не наследовать реализацию класса, а не понимать что вы делаете.
СОВЕТ2
На что я хотел бы обратить внимание. Старайтесь записывать свои мысли (кодом), их проще оценить, исправить и отладить. Я вооще сторонник другого стиля разработки, его смысл в создании групп разработки базирующейся на потребоностях бизнеса, но не эксплуатирующий яркие конструкции. Я уверен, и знаю такую модель разработки , при которой программисты создают код, читаемый без специальных знаний, качественный, интересный и не пергруженный конструкциями которые требуют не только специальных сред разработки но и горы бесполезных знаний затмевающих основную цель - создание эффективного кода.
К сожалению, это тоже довольно большой кусок размышений и я его не буду рассматривать в этой стате. Однако это не просто размышлизм, такие примеры есть - это открыте разработки. Это открыте конструкции, посмотрите как они это делают и вы поймете о чем я говорю.
Так вот если вы начнете писать то что думате в коде, а не создавать воздушные замки. То код у вас будет выглдить по тем дизайн паттернам, рассмотреным в книге. Но написан он будет не на памяти а в коде ввиде конструкций наследования, шаблонов, интерфейсов.
СОВЕТ3
Несмотря на общую критику и безалаберный подход заложенный в концепции. Я нахожу очень интересным пример использования шаблонов проектирования на примере текстового редактора рассмотренного в книге. Хоть и рассмотренная в начале книги шаблонная техника не выдерживает ни какой критики, сами по себе они пишут не так плохой код.
Если конечно не замечать таких ляпов как образование новых типов-строк. Это продолжение начатой авторами темы об всеобщей виртуализации, к которой так неудержно смотремится банда четырех.
Писать в коде конструкции strcmp(nameName, "Value") все равно что образовывать новый тип данных. Язык С++, это прежде всего язык типов, и компилятор делает работу за вас только в том случае, если вы этой парадигмы придерживаетесь. И если вы не ходите дубировать код (как раз в этом месте можно использовать термин повторное использование кода) то вам необходимо отказываться от строчек на этапе обработки данных от пользователя.
Так создавая новый тип const char* value = "Motif"; не забудьте создать одноименный класс и switch функцию, обеспечивающую создание одноименного объекта-свойсва на памяти. Хотя бы уж enum.
Необходимо заметить одну особенность изложения материала авторами. Банда четырех большие сторонники виртуализации и работы на памяти (с37). Парадигма, когда код становится несущественнным и менее приоритетным чем объект на памяти. Этим самым при чтении книги вас всегда подталкивают использовать паттеры как часть их концепции использующих память как ресурс. Тем самым как я уже говорил они создают воздушный замок, не читаемый сторонним наблюдателем. Отладка такой среды в разы трудней, так как вам необходима среда отладки с мощной системой визуализации.
Другими словами, эти ребята писали код только под Microsot Visual Stidio.
Хоть это и отдельная тема, которую я бы с удовольствием рассмотрел в отдельной статье. Я скажу пару слов и тут. Почему это интересно и большой объем для исследования? Приведу пример, вы никогда не задумывалиь почему большинство проектов под Линукс написано на простом плоском и могучем GObject (Objective-C)? Ответ простой: невозможно отлаживать виртуальный бред с кучей наследований на памяти. Но это нужно рассматривать подробней, в следующий раз...
Основной мыслью, которую продвигают авторы книги сводится исключительно к работе с объектом на памяти. И все разговоры о том, что проект с испльзованием паттернов предполагает повторное использование, гибкость в модификации это всего лишь заблуждение авторов. Нельзя решить все проблемы в проекте, введя полную свободу в работу с объектом (с38). Утверждая что код не значит ничего, а виртуальная среда - все, меняя объект на памяти, а не в коде они получают виртуальную машину, а не язык паттернов. Это очень серезное заблуждение и ошибка приводящая к развалу проекта. Этот принцип, закрытости логических конструкций и перевод их в виртуальную среду (память) усложняет процесс отладки и в корне лишает возможности проводить аналитический анализ исходного кода.
Этот вывод подтерждает тот факт, что код это лишь отображение объектов и он имеет маленькую значимость (с37), то что с наследование на памяти нельзя переопределить (с38).
Из чего я делаю вывод, что все паттерны представленные в этой книге работающие с памятью это всего лишь плод воображения авторов считающих что язык их ограничивает. Таким путем были созданы не одни среды и новые языки, которые в полсдествии вернулись или постепенно начали возвращатся (к типизации, интерфейсам, шаблонам) к паратигмам С++. И эти структуры имеющют отношения к серезной разработке, и созданию качественного продукта. Абстрактные фабрики и другие паттерны, нуждающиеся в создании неконтролируемых структур, нужны в исключительных случаях, и за частую вносят большие затрудения в анализ исходного кода и повторное его использование.
Я ожидают, что в скором времени эти ребята создадут новый язык, без типов, интерфейсов, без наследования и с возможностью переопределять любой метод любого класса. Конечно, такие среды уже есть, но как я уже сказал, все новое это хорошо забытое старое и авторы движутся именно по этому пути. Не делайте их ошибок!
суббота, 5 декабря 2009 г.
Больше вопросов...
Что бы вопросов становилось меньше, после публикации достаточно пространных текстов я хочу уточнить свою позицию.
Почему я это пишу и вообще какое оно есть отношение к программированию и С++?
Создается впечатление что вроде бы журнал не распологает к тем мыслям, которые я себе позволяю сюда писать. И вообще он о том как писать программы и развивать в себе системный подход к процессу программирования. А тексты, которые я иногда размещаю, похожы на филосовские размыление двоченика-шизофреника. Но!
Материал излагается что в такой форме, что бы пролить свет на причины приводящие к образованию бизнеса и использованию той работы которую все программисты дружно не задумываясь делают. Создавая программу мы частенько не хотим знать, как наша программа попадет на рынок и будет помогать добрым людям решать их повседенвные проблеммы.
Процесс разработки так же тесно связан с технологиями и методами работы на поле технических револци, с теми языками, средами, операцинными системами которые мы выбираем для решения наших задач. И вот эти все незаметные и проктически автоматически процессы выбора создают рынок, не заметный нашему потребителю - программисту. Такой рынок это ни что иное как еще один вид бизнеса, сосуществующего с остальной культурой программирования.
Этот вид бизнеса мне особенно интересен и симпатичен в силу того, что он является образцом любой предпринимательской деятельности в отличии от типичного искуственного вставления нормативов и правил.
Именно в такой незатейливой форме от простого к сложному, от незнания к совершенству создается и шлифуется любой процесс в том числе и разработки программ. И если вы сможете уловить эту суть, суть процесса, а не потоки денег, вы сможете зарабоать и добится большего успеха чем те, кто забыв обо всем стремится поднятся любыми честными и безчестными методами по карьерной лестнице.
В этой нелепости, противной здравому смыслу, было что-то символическое. И уступая ее многозначительности, доктору тоже хотелось выбежать на площадку и остановить гимназиста готовым, рвавшимся наружу изречением. Ему хотелось крикнуть и мальчику, и людям в вагоне что спасение не в верности формам, а в освобождении от них.
Почему я это пишу и вообще какое оно есть отношение к программированию и С++?
Создается впечатление что вроде бы журнал не распологает к тем мыслям, которые я себе позволяю сюда писать. И вообще он о том как писать программы и развивать в себе системный подход к процессу программирования. А тексты, которые я иногда размещаю, похожы на филосовские размыление двоченика-шизофреника. Но!
Материал излагается что в такой форме, что бы пролить свет на причины приводящие к образованию бизнеса и использованию той работы которую все программисты дружно не задумываясь делают. Создавая программу мы частенько не хотим знать, как наша программа попадет на рынок и будет помогать добрым людям решать их повседенвные проблеммы.
Процесс разработки так же тесно связан с технологиями и методами работы на поле технических револци, с теми языками, средами, операцинными системами которые мы выбираем для решения наших задач. И вот эти все незаметные и проктически автоматически процессы выбора создают рынок, не заметный нашему потребителю - программисту. Такой рынок это ни что иное как еще один вид бизнеса, сосуществующего с остальной культурой программирования.
Этот вид бизнеса мне особенно интересен и симпатичен в силу того, что он является образцом любой предпринимательской деятельности в отличии от типичного искуственного вставления нормативов и правил.
Именно в такой незатейливой форме от простого к сложному, от незнания к совершенству создается и шлифуется любой процесс в том числе и разработки программ. И если вы сможете уловить эту суть, суть процесса, а не потоки денег, вы сможете зарабоать и добится большего успеха чем те, кто забыв обо всем стремится поднятся любыми честными и безчестными методами по карьерной лестнице.
В этой нелепости, противной здравому смыслу, было что-то символическое. И уступая ее многозначительности, доктору тоже хотелось выбежать на площадку и остановить гимназиста готовым, рвавшимся наружу изречением. Ему хотелось крикнуть и мальчику, и людям в вагоне что спасение не в верности формам, а в освобождении от них.
Б. Пастернак
Это не история повторяется...
Это не история повторяется, это мы рождаемся и умераем и делаем ошибки тех, кто набив бобышки теперь мешает нам идти и поступать так же.
Я уже писал о том, что программные среды появляющиеся как грибы на почве современных технологий под давлением глобализации являются следствием нескольких факторов. Во-первых: мы не хотим учится, нам проще делать ошибки и делать выводы о том, как не хорошо поступать. Во-вторых: нам навязывают идеи в интересах некоторых бизнес аудиторий, которая соориентирована на захват сфер влияния, пропаганды своих интересов и продвижении продуктов. В последствии для получения контроля над аудиторией (продвижение продуктов, и информационная пропоганда).
Эти оба фактора способствуют созданию и росту среды вместе с ее адуиторией, несмотря на то что они все приходят всегда к одному и тому же и все что сейчас кажется новым уже было когда-то изобретено.
Начинать с начала свойствоенно людям. Они не хотят учится, хотят одним взмахом рукова создавать озера, бросив сотней баксов почувствовать себя сверх человеком, и за пять минут просмотра презентации понять и принять решение о "перспективности" идеи - разжеванная, кастированная информация лучше входит.
Это касается не только развития большинства технологий и языковых средств, но так же свойственно в таких областях как хужожественная литература.
Все любят фантастику, читать шизофрению о Сталине сражающемся с рептилиями, и борбе синих человечков с зелеными. Интересней (понятней так как у этих историй есть начало и конец) чем взять книгу Хокинга, и узнать как устроена вселенная (сложней, так как необходимо базироваться на опыте других людей).
Иоганн Гете (в переводе Б. Пастернак)
Я уже писал о том, что программные среды появляющиеся как грибы на почве современных технологий под давлением глобализации являются следствием нескольких факторов. Во-первых: мы не хотим учится, нам проще делать ошибки и делать выводы о том, как не хорошо поступать. Во-вторых: нам навязывают идеи в интересах некоторых бизнес аудиторий, которая соориентирована на захват сфер влияния, пропаганды своих интересов и продвижении продуктов. В последствии для получения контроля над аудиторией (продвижение продуктов, и информационная пропоганда).
Эти оба фактора способствуют созданию и росту среды вместе с ее адуиторией, несмотря на то что они все приходят всегда к одному и тому же и все что сейчас кажется новым уже было когда-то изобретено.
Начинать с начала свойствоенно людям. Они не хотят учится, хотят одним взмахом рукова создавать озера, бросив сотней баксов почувствовать себя сверх человеком, и за пять минут просмотра презентации понять и принять решение о "перспективности" идеи - разжеванная, кастированная информация лучше входит.
Это касается не только развития большинства технологий и языковых средств, но так же свойственно в таких областях как хужожественная литература.
Все любят фантастику, читать шизофрению о Сталине сражающемся с рептилиями, и борбе синих человечков с зелеными. Интересней (понятней так как у этих историй есть начало и конец) чем взять книгу Хокинга, и узнать как устроена вселенная (сложней, так как необходимо базироваться на опыте других людей).
Пергаменты не утоляют жажды.
Ключ мудрости не на страницах книг.
Кто к тайнам жизни рвется мыслью каждой,
В своей душе находит их родник.
Ключ мудрости не на страницах книг.
Кто к тайнам жизни рвется мыслью каждой,
В своей душе находит их родник.
Иоганн Гете (в переводе Б. Пастернак)
Подписаться на:
Сообщения (Atom)
