Insight IT

ООП или не ООП

Иван Блинков — Thu, 23 Sep 2010 13:07:00 +0400

Вчера мне на почту пришло письмо от коллеги с просьбой прокомментировать статью, видимо его же перевода или авторства, о судьбе объектно-ориентированного программирования в современном мире: Почему объектно-ориентированное программирование провалилось?. Собственно говоря, пишу ответ в своем блоге скорее чтобы несколько растопить образовавшийся здесь лед, да и возможно снова затянет - продолжу дальше активно писать в Insight IT.

Для начала хочу вкратце пересказать саму статью. Написана она по мотивам мнений различных экспертов в области разработки, в частности Objects Have Failed by Richard P. Gabriel, November 6, 2002 и holywar'а на конференции OOPSLA с участием именитых специалистов. Аргументы у обоих сторон "за и против" были довольно странноватыми и по сути были подтверждениями и опровержениями различных мифов об ООП, например о том, что с использованием парадигмы ООП разработка идет быстрее/проще/понятнее/удобнее, что ОО языки программирования не соответствуют требованиям вычислительных процессов будущего и не адекватно отражают предметную область, что повторное использование кода есть в любом языке программирование - как минимум в виде библиотек. Сторонники ООП же в основном настаивают на справедливости мифов и твердо отстаивают три основных столпа их парадигмы. На вышеупомянутой конференции по мнению аудитории вверх взяла сторона "против ООП" из-за натиска сторонников языка Lisp и растерянности сторонников ООП касательно своей же теории.

Что же касается моего мнения касательно данного вопроса, то я не являюсь ни приверженцем, ни противником объектно-ориентированного подхода к программированию. В целом мой взгляд на ситуацию довольно прост: все языки программирования - лишь инструмент для решения вполне определенного круга задач. Выбор инструмента и способа работы с ним определяется в основном лишь самой конкретной постановкой задачи, требованиям к ней, а также имеющимися в наличии ресурсами - в первую очередь человеческими и финансовыми. Не нужно смотреть на программирование чисто с технической точки зрения - в первую очередь программисты решают бизнес-задачи и проблемы людей, а каким именно образом и с использованием каких инструментов - заказчиков и потребителей программных продуктов волнует меньше всего. Для них намного важнее итоговые показатели получившегося продукта: себестоимость разработки и поддержки, сроки исполнения, соответствие требованиям, а также в зависимости от типа продукта масштабируемость, производительность, стабильность, безопасность.

Да, в десятках и сотнях тысяч готовых классов в .NET или Java легко запутаться, но они позволяют не разрабатывать реализуемые ими вещи самим. Объектно-ориентированные языки программирования дают возможность оперировать более высокоуровневыми понятиями и не тратить время на возню с памятью напрямую (от утечек правда это не избавляет, но все же), указателями, типовыми алгоритмами, реализацией протоколов и прочими нормальными для низкоуровневых языков программирования вещами. Уделяя меньше внимания деталям, можно создавать крупные проекты большими мазками - возможно в ущерб качеству, но для многих ситуаций это приемлемо.

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

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

Плюс не стоит забывать и о том, какие люди участвуют в разработке: бывают разработчики, которые фанатеют от ООП, всю жизнь занимаются "сборкой" проектов из библиотек на Java или C#, являются ярыми поклонниками TDD и Agile-разработки, а бывают разработчики, которые предпочитают Assembler/C/Fortran/Cobol/Lisp/Haskell/Erlang (нужное подчеркнуть), любят реализовывать очень сложные алгоритмы, оптимизировать их, добиваясь выиграша в несколько миллисекунд во времени или пару килобайт в использованной оперативной памяти. Естественно это лишь крайние или почти крайние случаи, большинство разработчиков скорее всего находятся где-то посередине (к сожалению, у меня нет такой статистики), предпочитая универсальные языки программирования, на которых можно писать код как объектно-ориентированно, так и нет (C++/Python/PHP/etc). Хочется порекомендовать руководителям не заставлять имеющихся в наличии людей заниматься тем, что им не по душе, просто так как Вам кто-то вчера рассказал, что "Ruby on Rails - это круто" или так как во-о-он тот известный проект реализован с использованием во-он тех технологий, языков программирования или парадигм разработки. Используемые технологии и подходы к написанию кода, должны соответствовать поставленным задачам, а команда должна быть готова реализовать проект именно так, как это необходимо, при этом очень большое значение имеет распределение ролей между разработчиками - чтобы каждый занимался своим любимым делом.

Коллеги, копайте ямы лопатами и забивайте гвозди молотками, а не наоборот :)

Интерфейс

Иван Блинков — Sun, 04 May 2008 13:41:00 +0400

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

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

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

Уже догадались? Да, это я так неспеша плавно подводил разговор к объектно-ориентированному программированию. Термин интерфейс широко применяется и в нем. Как не трудно предположить, в роли объектов в этом случае выступают как сами классы, так и их экземпляры (которые, впрочем, тоже принято называть словом объект).

В общем случае интерфейсом класса выступает совокупность его public методов и переменных, то есть доступных для обращения из других частей приложения. Этот факт вполне логичен - именно благодаря им и осуществляется взаимодействие класса (или его объекта) с "внешним миром". Но не все так просто, особенно с точки зрения шаблонов проектирования, немаловажную роль в взаимодействии классов и объектов играет абстракция. Хочется обратить внимание, что формально имеется ввиду даже не сами методы, а их заголовки, то есть название, набор получаемых переменных и тип возвращаемого значения (этот набор данных принято также принято называть интерфейсом методов или функций), само тело метода (реализация) в данном случае не важно.

Иными словами, если один класс (будем называть его клиент) взаимодействует с каким-либо другим объектом, то по большому счету он абсолютно не обязан знать какого класса этот объект является экземпляром (может конечно, но это совсем не обязательно). Единственное, что интересует класс-клиент, это интерфейс объекта, с которым он взаимодействует, этой информации вполне достаточно для полноценной совместной работы.

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

Самым наглядным языком программирования для демонстрации описания интерфейсов я считаю Java (хотя можно было бы выбрать и C#, PHP или практически любой другой по вкусу). В теории все просто:

Ключевое слово interface обозначает описание интерфейса;
За ним следует название конкретного интерфейса, которое впоследствии можно будет использовать в коде при его упоминании (некоторые программисты на правах традиции начинают названия интерфейсов с заглавной буквы I, мне в свое время даже пытались объяснить зачем так надо делать, но аргументы не показались мне достаточно весомыми);
Далее идет тело интерфейса, в котором перечисляются все заголовки методов, которые должны быть в классе, реализующем данный интерфейс (никакой реализации!);
Впоследствии приписав к заголовку любого класса ключевое слово implements с последующим указанием названия интерфейса, можно обязать этот класс реализовать указанные в описания интерфейса методы. Существует небольшое исключение для абстрактных классов (то есть классов,для которых не может быть создан объект, обозначаются ключевым словом abstract), они могут и не реализовать все методы интерфейса, но тогда эта обязанность будет переложена на их наследников.

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

Небольшое примечание: сами интерфейсы и методы в их теле по-умолчанию обладают свойствами abstract и public, так что повторно указывать эти ключевые слова не нужно.

На практике же это выглядит это примерно следующим образом:

// описание интерфейса
interface Renderable
{
    // обязуем реализовать метод draw
    public void draw();
}

// конкретная реализация интерфейса
class SomeText implements Renderable
{
   string text;
   public SomeText(string str)
   {
      this.text=str;
   }
   public void draw()
   {
       // вынуждены подчиниться и реализовать
       System.out.println(this.text);
   }
}

// класс-клиент
class Render
{
  public Render(Renderable obj)
  {
     // можно быть уверенным, что
     // метод draw реализован
     obj.draw();
     /*
         в качестве альтернативы можно было бы написать как-то так:
         if(obj instanceof Renderable)obj.draw();
         то есть проверить реализован ли интерфейс
         вместо использования его названия в роли типа данных
     */
  }

В данном примере ситуация тривиальна: класс-клиент Render умеет лишь визуализировать классы, которые он получает в конструктор, вызывая у них метод draw. Для обеспечения такой возможности описан интерфейс Renderable, который реализуется в классе SomeText. Хоть класс Render ничего и не знает о том, какой именно класс ему подсунут, благодаря интерфейсу он сможет вывести на экран любой объект, корректно реализующий наш интерфейс, в том числе и SomeText.

Как я уже упоминал: альтернативой такому подходу является использование полиморфизма и наследования. Такой подход более распространен в других языках программирования, например C++, но пример я приведу все равно на Java, основываясь на предыдущем примере, чтобы читателям было проще сравнивать.

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

// теперь используем абстрактный класс
abstract class Renderable
{
    // реализуем метод draw
    public void draw()
    {
       System.out.println("Вывод на экран недоступен!");
    }
}

// реализация интерфейса (на этот раз неформального)
class SomeText extends Renderable
{
   // на этот раз используем extends (наследование)
   // вместо implements
   string text;
   public SomeText(string str)
   {
      this.text=str;
   }
   public void draw()
   {
       // переопределяем метод draw
       // но могли этого и не делать, тогда
       // использовался бы метод из Renderable
       System.out.println(this.text);
   }
}

// класс-клиент
class Render
{
  public Render(Renderable obj)
  {
     // можно быть уверенным, что
     // метод draw реализован
     obj.draw();
     /*
        на этот раз так как в крайнем случае
        в крайнем случае вызовется хотябы
        метод из класса Renderable
     */
  }

Минимальные изменения - суть та же. Сразу хочу отметить, что этот процесс так прост только в Java, в других языках программирования понадобилось бы использование дополнительных модификаторов для метода draw (например в C#: virtual или abstract в классе-потомке и override в классе-наследнике, это необходимо для обеспечения возможности их переопределения).

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

Design patterns

Иван Блинков — Thu, 24 Apr 2008 13:03:00 +0400

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

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

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

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

Изначально идея построения шаблонов для решения типичных задач появилась в архитектуре (имеется ввиду которая к строительству относится, а не к высоконагруженным системам :) ). Автором ее был Cristopher Alexander, он впервые составил набор шаблонов проектирования для архитекторов во второй половине двадцатого века, но, к сожалению, в этой науке эта идея не прижилась, зато ее успешно переняли и перенесли в область программирования.

Основной вклад в этот процесс сделала знаменитая команда, известная как Gang of Four. Она состоит из четырех авторов не менее известной книги "Design Patterns — Elements of Reusable Object-Oriented Software":

Erich Gamma
Richard Helm
Ralph Jonson
John Vlissides

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

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

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

Шаблонизация

Иван Блинков — Sat, 26 Jan 2008 15:25:00 +0300

Наверняка Вы часто замечали, что в пределах одного сайта все (или покрайней мере большинство) страниц имеют много общего: структуру, расположение элементов, дизайн и так далее. Основным различием обычно является лишь содержание. Естественно, что делается это не спроста: именно общие компоненты сайта создают в голове посетителей тот самый образ, который производит общее подсознательное впечатление о сайте, а также позволяет посетителям отличать сайт А от сайта Б.

Продолжая разговор, начатый еще в одной из предыдущих статей, рассмотрим организацию интерфейса между двумя другими составляющими практически любого интернет-проекта: скриптов (все так же на примере PHP) и страницами, отправляемыми посетителям посредством http-сервера.

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

Наверняка у Вас уже возникло два вполне логичных вопроса:

Как можно разделить таким образом контент?
Как потом восстановить страницу в исходном виде?

Вариантов ответа на каждый из них можно придумать множество: начиная с банальных вариаций на тему применения echo, заканчивая применением достаточно серьезных готовых решений вроде широкораспространенного Smarty или существенно более эффективного Blitz. Каждый из них имеет свои сильные и слабые стороны, но в целом любой из них можно оценить по двум критериям: производительности и удобстве организации кода.

Какие-либо цифры оценки производительности приводить не буду, так как, во-первых, в Сети можно найти много benchmark'ов, посвященных этой теме, а, во-вторых, просто-напросто вовсе не о цифрах я хотел с Вами поговорить. Как известно самым производительным по крайней мере с теоретической точки зрения является метод под названием php mess, заключается он в следующем: вся страница размещается в рамках одного файла, при этом статическая часть документа пишется просто "как есть" в соответствии с необходимым стандартом, а изменяемые части организуются размещенным в необходимых местах PHP-кодом, окруженным стандартной конструкцией <?php ?>. Но огромнейший недостаток очевиден - огромное количество информации расположенной в одном файле, при отсутствии какого-либо более четкого разделения PHP-кода и остального содержимого, чем указанная выше конструкция, приводит к постоянной путанице в коде, а также существенным затратам времени программиста при попытках исправить ту или иную часть документа.

На противоположной стороне нашей шкалы удобство-производительность я бы расположил уже упомянутое выше решение под названием Smarty. Представляет оно собой целую систему, реализованную также на PHP, и предоставляющую огромное количество возможностей по решению нашей задачи. Шаблоны хранятся в отдельных файлах, для определения мест расположения динамического контента используется специальный синтаксис, который прост как три копейки, так как разрабатывался с расчетом не на программистов, а по принципу "чем проще, тем лучше". Именно этот факт сделал Smarty одним из самых (если не самым) распространенных движков шаблонизации (или как их принято правильно называть "Template Engine"). Но, к сожалению, за удобство приходится платить, в этом случае производительностью: вся система сама по себе громоздка и состоит из множества файлов, между которыми все данные так или иначе передаются, а так как написано она на PHP (который является далеко не самым производительным языком программирования, в основном в силу своей интерпритируемости и некоторых других особенностей), конкуренции в плане производительности многим другим вариантам решения нашей задачи Smarty составить не в состоянии.

Одним из лучших "компромиссных" вариантов, которые доступны на данный момент, могу назвать также упомянутый выше Blitz. Реализован он в виде модуля PHP, написанного на языке C, что является залогом его отличной производительности. При этом общая его концепция близка к Smarty: шаблоны также хранятся в отдельных файлах и подчинены незамысловатому синтаксису (который вообще можно понять и запомнить буквально за 15-20 минут, прочитав статью, ссылку на которую я уже приводил выше), а в PHP-скриптах после установки становится доступен специальный класс для управления модулем. Но основное достоинство этого решения является одновременно и его основным недостатком - редкий хостинг имеет этот модуль в списке предустановленных (видимо в силу своей не очень обширной известности, обусловленной ), а доступ к http-серверу и PHP-интерпретатору, который необходим для установки PHP-модулей, предоставляется чаще всего только на дорогих тарифах виртуального хостинга или на различных вариантах VPS или арендуемых серверов.

Помимо этого некоторые энтузиасты берутся на написание "собственных" Template Engine, базирующихся на различных вариантов использования PHP-функций вроде preg_replace. Если честно такие попытки редко заканчиваются успехом: в лучшем случае удается добиться удобства использования самим разработчиком, но чаще всего в ущерб производительности. Заниматься подобными экспериментами я Вам не советую, вместо этого я предлагаю написать "обертку" к приглянувшемуся распространенному Template Engine, что позволит не только сделать его использование более удобным конкретно для Вас, но и позволит заменить его на другой с минимальными затратами сил и времени (например в случае, если модуль Blitz недоступен).

Разрабатываем "обертку"

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

Если Ваш выбор всетаки пал на написание "оболочки", не смотря на принесение в жертву несущественной части производительности, то стоит для начала определиться: а что же мы будем "заворачивать"? В качестве примера я, пожалуй, буду использовать Blitz, как самый оптимальный вариант (по крайней мере с моей точки зрения). Начать стоит как обычно с пустой заготовки для класса.

Далее следует решить какие все же модификации мы будем производить для собственного удобства над стандартным решением. Попробую привести несколько примеров в отношении Blitz, для начала хочу обратить внимание, что при внимательном прочтении все той же статьи от разработчика этого шаблонизатора, можно обнаружить, что модуль показывает более высокие показатели производительности при однократном вызове метода set. Достичь это можно выполнением этого метода с указанием в качестве одного из входных параметров "многоуровнего" массива, составленного специальным образом (надеюсь Вы все же к этому моменту уже успели прочитать неоднократно упоминавшуюся статью, и представляете принцип работы модуля). Написание механизма составления такого массива позволит как сократить время разработки, так и сэкономит драгоценные миллисекунды, вычитаемые из свободного времени посетителей сайта в процессе генерации страницы.

В любом случае понадобится переменная для его хранения:

<?php
class TemplateEngine
{
  {
    array=array();
    //можно сразу указать указать путь к папке с шаблонами
    $this->engine=new Blitz('./template/'.$template.'.tpl');
  }
}
?>

А также метод, переопределяющий стандартный set на метод, добавляющий новые значения к нашему массиву (хотя можно и любое другое понравившееся название использовать):

<?php
function set($caption,$value)
{
  $this->array[$caption]=$value;
}
?>

После чего оригинальный set можно использовать уже непосредственно перед parse, с указанием уже собранного массива в качестве параметра. За компанию позволю произвести себе еще одну модификацию: в подавляющем большинстве случаев parse используется в совокупности с echo, чтобы не указывать каждый раз это слово - можно включить его прямо в наш класс:

<?php
function parse()
{
  if(count($this->array))$this->engine->set($this->array);
  echo $this->engine->parse();
}
?>

Еще одним возможным вариантом модификации может стать обработка всех (или какой-то части, если есть необходимость) динамических данных с помощью какой-либо функции, например это актуально для htmlspecialchars:

<?php
function set($caption,$value)
{
  $this->array[$caption]=$this->html($value);
}
function rawset($caption,$value)
{
  $this->array[$caption]=$value;
}
private function html($array)
{
  if(is_array($array))
  {
    foreach($array as $caption => $value)
    $value=$this->html($value);
    return $array;
  }
  else return htmlspecialchars($array,ENT_QUOTES);
}
?>

Как нетрудно заметить, в методе используется рекурсия, так как структура передаваемых параметром массивов неизвестна.

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

Общаемся с базой данных

Иван Блинков — Wed, 16 Jan 2008 22:04:00 +0300

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

Если подойти к этому вопросу "в лоб", то код станет очень неудобен как для понимания, так и для использования: код станет переполнен различными функциями соединения с БД, отправки запросов, преобразования результатов запросов в массивы PHP, подсчета строк, которые затронул запрос, а также многие и многие другие.

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

Этим способом будет являться написание класса, реализующего интерфейс между СУБД и PHP-скриптами. Для начала стоит определиться с ассортиментом функций, которые будет призван выполнять наш класс:

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

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

<?php
class SQL
{
}
?>

В зависимости от предпочитаемой Вами СУБД набор конкретных функций, используемых в реализации нашего класса, будет вариироваться. В большинстве случаев предпочитаю пользоваться PostgreSQL, на это причин у меня несколько, но это тема для отдельного разговора. Благодаря этому факту приводимый в качестве примера код будет использовать функции для работы именно с этой СУБД. Для поклонников же других этот систем вопрос в подавляющем большинстве случаев заключается лишь в замене этих функций на аналогичные из других модулей PHP, например для популярной и широкораспространенной MySQL достаточно будет всеголишь пройтись автозаменой pg_ => mysql_ и слегка подредактировать параметры некоторых функций.

Перейдем к реализации установления соединения с СУБД, не стоит ожидать увидеть здесь ничего необычного:

<?php
static function connect()  // установка соединения
{
  self::$connection=pg_pconnect("host=localhost dbname=pgsql user=pgsql password=MyPassword");
  // не забываем менять указанные данные для авторизации на правильные
  if(!isset(self::$connection))
  {
    echo "Сайт не работает по техническим причинам.
Просим прощения за доставленные неудобства.";
    exit;   // ни в коем случае не выводим более информативных сообщений об ошибке, чем это
  }
}
?>

А вот с отправкой и обработкой результатов запросов ситуация далеко не так однозначна. Помимо простой передачи самого текста запроса в СУБД, необходимо правильно определить тип запроса и в соответствии с этим обработать результат. Можно конечно попытаться сделать это автоматически на основе вытаскивания первого слова из текста запроса, но мне всетаки кажется более предпочтительным определение "вручную" желаемого вида представление результата. Выполнение произвольных запросов может выглядеть, например, следующим образом:

<?php
static function query($str,$bool=false) // произвольный запрос
{
  //echo $str."
"; // очень удобно на стадии разработки в процессе поиска ошибок
  $result=@pg_query(self::$connection,$str); // @ - для сокрытия теоретически возможных ошибок
  // or die('Query failed: '.pg_last_error());
  // не забываем убирать в комментарий в финальном варианте проекта
  // или совсем удалять
  if($result)  // Если получен результат, отличный от false
  {
    if($bool)  // Если выбран результат в виде boolean
    {
      return true;
    }
    else  // Если выбран результат в виде массива
    {
      $n=pg_num_rows($result);  // для создания универсального формата массива
      if($n==1)return pg_fetch_array($result,0,PGSQL_ASSOC);
      else  // даже когда результат содержит только одну строку
      {
        $j=pg_num_rows($result);
        $list=array();
        for($i=0;$i<$j;$i++)
        $list[]=pg_fetch_array($result,$i,PGSQL_ASSOC);
        return $list;
      }
    }
  }else return false;
}
?>

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

<?php
static function selectAll($table)
{ // пример метода отправки чаcтоиспользуемых запросов
  return self::query("select * from ".$table.";");
}
?>

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

Что ж, осталось лишь собрать весь код в единый листинг:

<?php
class SQL
{
  private static $connection; // соединение с СУБД
  static function connect()  // установка соединения
  {
    self::$connection=pg_pconnect("host=localhost dbname=pgsql user=pgsql password=MyPassword");
    // не забываем менять указанные данные для авторизации на правильные
    if(!isset(self::$connection))
    {
      echo "Сайт не работает по техническим причинам.<br />Просим прощения за доставленные неудобства.";
      exit; // ни в коем случае не выводим более информативных сообщений об ошибке, чем это
    }
  }
  static function query($str,$bool=false) // произвольный запрос
  {
    //echo $str."<br>"; // очень удобно на стадии разработки в процессе поиска ошибок
    $result=@pg_query(self::$connection,$str); // @ - для сокрытия теоретически возможных ошибок
    // or die('Query failed: '.pg_last_error());
    // не забываем убирать в комментарий в финальном варианте проекта
    // или совсем удалять
    if($result)  // Если получен результат, отличный от false
    {
      if($bool)  // Если выбран результат в виде boolean
      {
        return true;
      }
      else  // Если выбран результат в виде массива
      {
        $n=pg_num_rows($result);  // для создания универсального формата массива
        if($n==1)return pg_fetch_array($result,0,PGSQL_ASSOC);
        else  // даже когда результат содержит только одну строку
        {
          $j=pg_num_rows($result);
          $list=array();
          for($i=0;$i<$j;$i++)
          $list[]=pg_fetch_array($result,$i,PGSQL_ASSOC);
          return $list;
        }
      }
    }else return false;

  }
  static function selectAll($table)
  { // пример метода отправки чаcтоиспользуемых запросов
    return self::query("select * from ".$table.";");
  }
}
?>

```

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

Эта статья является частью серии статей "Джентельменский набор PHP программиста", если Вам понравилась эта статья то очень вероятно, что Вам придутся по душе и остальные статьи.

Не забываем подписываться на RSS блога!

Защита интернет-ресурсов в картинках

Иван Блинков — Sun, 13 Jan 2008 22:30:00 +0300

Этой статьей мне хотелось бы открыть мою первую серию статей "Джентельменский набор PHP программиста". Как и во всей остальной серии здесь пойдет речь о программировании на PHP для интернет-проектов, но в каждой статье я буду выбирать один узкий аспект и на протяжении всей статьи буду стараться показать возможные варианты его реализации и применения.

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

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

Подготовка

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

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

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

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

Итак, создание объекта будем производить максимально простым способом, параметрами укажем белый и черный цвета. Заготовка для самого класса будет выглядеть примерно следующим образом (предположим, что он хранится в файле captcha.class.php):

<?php
class Captcha
{
   private $string; // генерируемый текст
   private $bgcol;  // основной цвет фона
   private $fgcol;  // основной цвет текста
   private $height; // высота изображения
   private $width;  // ширина изображения
   function __construct($bgcol,$fgcol)  // конструктор, вызывается при создании экземпляра класса
   {
   }
}
?>

Задаем параметры

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

<?php
private function generateImage()  // генерация изображения
{
  $this->width=250;
  $this->height=80;
  $this->fgcol=$fgcol;
  $this->bgcol=$bgcol;
  $this->generateSymbols();
 }
 private function generateSymbols()   // генерация четырех цифр
 {
    $this->string=$this->leadingZero(rand()%10000,4);
 }
 private function leadingZero($num,$length) // дополнения числа num лидирующими нулями
 {                        // до длины length
  $str=strrev($num);
  for($i=strlen($str);$i<$length;++$i)$str.="0";
  return strrev($str);
 }
}
?>

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

Генерируем изображение

Если забыть, что текст необходимо искажать, то функция, генерирующая изображение выглядела бы просто как:

<?php
private function generateImage()  // генерация изображения
{
   $im=@imagecreatetruecolor($this->width,$this->height);
   $bcol=imagecolorallocate($im,$this->bgcol[0],$this->bgcol[1],$this->bgcol[2]);
   $fcol=imagecolorallocate($im,$this->fgcol[0],$this->fgcol[1],$this->fgcol[2]);
   imagefill($im,0,0,$bcol);
   imagettftext($im,40,10,20,25,$fcol,"./font/font_name.ttf",$this->string));
   header('Content-Type: image/png');
   imagepng($im);
   imagedestroy($im);
}
?>

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

Реально же ей пользоваться не стоит - такое изображение с легкостью поддается OCR. Полученный текст необходимо тем или иным образом исказить. Для вывода изображения используется формат PNG, но никто не мешает воспользоваться JPEG или GIF, для этого достаточно заменить везде png на название соответствующего формата.

Искажаем текст

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

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

Для начала этого вполне хватит, перейдем к реализации, в комментариях постараюсь указывать все особенности:

<?php
private function generateImage() // генерация изображения
{
   $im=@imagecreatetruecolor($this->width,$this->height);  // создаем пустое изображение
   $mcol=imagecolorallocate($im,$this->fgcol[0]+rand()%100+80,$this->fgcol[1]+rand()%30+150,$this->fgcol[2]-rand()%55); // выбираем случайным образом
   $kcol=imagecolorallocate($im,$this->fgcol[0]+rand()%100+80,$this->fgcol[1]+rand()%30+150,$this->fgcol[2]-rand()%20); // несколько цветов
   $lcol=imagecolorallocate($im,$this->bgcol[0]-rand()%20,$this->bgcol[1]-rand()%20,$this->bgcol[2]-rand()%20);
   $bcol=imagecolorallocate($im,$this->bgcol[0],$this->bgcol[1],$this->bgcol[2]);
   $fcol=imagecolorallocate($im,$this->fgcol[0],$this->fgcol[1],$this->fgcol[2]);
   imagefill($im,0,0,$bcol);  // заполняем изображение фоном
   $array=array(6,7,6,6,20,20,25,26,31,32,37,39,41); // список названий подходящих шрифтов
   $n=$array[rand()%count($array)];  // наугад выбираем из них один
   $m=rand()%50+1;
   $k=rand()%50+1;
   for($i=0;$i<$m;++$i)
   imageline($im,0,rand()%$this->height,$this->width,rand()%$this->height,$lcol); // создаем на фоне несколько линий
   for($i=0;$i<$k;++$i)
   imageline($im,rand()%$this->width,0,rand()%$this->width,$this->height,$lcol); // и еще несколько
   /*
   Генерируем текст: две строки на фон, а также интересующие нас символы по одному.
   */
   imagettftext($im,rand()%20+40,rand()%100-50,rand()%$this->height*0.8,rand()%50+25,$kcol,"./font/".$k.".ttf",$this->randomString(rand()%15));
   imagettftext($im,rand()%40+35,rand()%70-35,rand()%$this->height*0.8,rand()%25+25,$mcol,"./font/".$m.".ttf",$this->randomString(5+rand()%4));
   for($i=0;$istring);++$i)
   imagettftext($im,rand()%10+33,rand()%70-35,15+$i*$this->width/5*1.1+rand()%5,rand()%7+$this->height*0.73,$fcol,"./font/".$n.".ttf",$this->string[$i]);
   for($i=0;$i<$m/10;++$i)
   imageline($im,0,rand()%$this->height,$this->width,rand()%$this->height,$mcol); // еще линии
   for($i=0;$i<$k/4;++$i)
   imageline($im,rand()%$this->width,0,rand()%$this->width,$this->height,$mcol);  // и еще немного
   for($i=0;$i<$k/6;++$i)
   imageline($im,rand()%$this->width,0,rand()%$this->width,$this->height,$fcol);  // и еще чуть-чуть
   header('Content-Type: image/png');
   imagepng($im);
   imagedestroy($im);
}
private function randomString($length)  // генерируем случайный набор символов заданной длины
{
  $list="abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVXYZ!@#$%^&**()-=_+.,<>/\|;:";
  for($i=0,$str="";$i<$length;++$i)$str.=substr($list,mt_rand(0,strlen($list)-1),1);
  return $str;
}
?>

Стоит заметить, что конкретные цифры необходимо подбирать индивидуально, в примере они указаны абсолютно произвольно. Использование конкретно этих же цифр приведет к далеко не самым лучшим результатам.

Сборка

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

Собрав все написанное выше, и учтя передачу текста, можно получить следующий класс:

<?php
class Captcha
{
   private $string; // генерируемый текст
   private $bgcol;  // основной цвет фона
   private $fgcol;  // основной цвет текста
   private $height; // высота изображения
   private $width;  // ширина изображения
   function __construct($bgcol,$fgcol)  // конструктор, вызывается при создании экземпляра класса
   {
      $this->width=250;
      $this->height=80;
      $this->fgcol=$fgcol;
      $this->bgcol=$bgcol;
      $this->generateSymbols();
      $this->generateImage();
   }
   private function generateImage() // генерация изображения
   {
      $im=@imagecreatetruecolor($this->width,$this->height);  // создаем пустое изображение
      $mcol=imagecolorallocate($im,$this->fgcol[0]+rand()%100+80,$this->fgcol[1]+rand()%30+150,$this->fgcol[2]-rand()%55); // выбираем случайным образом
      $kcol=imagecolorallocate($im,$this->fgcol[0]+rand()%100+80,$this->fgcol[1]+rand()%30+150,$this->fgcol[2]-rand()%20); // несколько цветов
      $lcol=imagecolorallocate($im,$this->bgcol[0]-rand()%20,$this->bgcol[1]-rand()%20,$this->bgcol[2]-rand()%20);
      $bcol=imagecolorallocate($im,$this->bgcol[0],$this->bgcol[1],$this->bgcol[2]);
      $fcol=imagecolorallocate($im,$this->fgcol[0],$this->fgcol[1],$this->fgcol[2]);
      imagefill($im,0,0,$bcol);  // заполняем изображение фоном
      $array=array(6,7,6,6,20,20,25,26,31,32,37,39,41); // список названий подходящих шрифтов
      $n=$array[rand()%count($array)];  // наугад выбираем из них один
      $m=rand()%50+1;
      $k=rand()%50+1;
      for($i=0;$i<$m;++$i)
      imageline($im,0,rand()%$this->height,$this->width,rand()%$this->height,$lcol); // создаем на фоне несколько линий
      for($i=0;$i<$k;++$i)
      imageline($im,rand()%$this->width,0,rand()%$this->width,$this->height,$lcol); // и еще несколько
      /*
      Генерируем текст: две строки на фон, а также интересующие нас символы по одному.
      */
      imagettftext($im,rand()%20+40,rand()%100-50,rand()%$this->height*0.8,rand()%50+25,$kcol,"./font/".$k.".ttf",$this->randomString(rand()%15));
      imagettftext($im,rand()%40+35,rand()%70-35,rand()%$this->height*0.8,rand()%25+25,$mcol,"./font/".$m.".ttf",$this->randomString(5+rand()%4));
      for($i=0;$istring);++$i)
      imagettftext($im,rand()%10+33,rand()%70-35,15+$i*$this->width/5*1.1+rand()%5,rand()%7+$this->height*0.73,$fcol,"./font/".$n.".ttf",$this->string[$i]);
      for($i=0;$i<$m/10;++$i)
      imageline($im,0,rand()%$this->height,$this->width,rand()%$this->height,$mcol); // еще линии
      for($i=0;$i<$k/4;++$i)
      imageline($im,rand()%$this->width,0,rand()%$this->width,$this->height,$mcol);  // и еще немного
      for($i=0;$i<$k/6;++$i)
      imageline($im,rand()%$this->width,0,rand()%$this->width,$this->height,$fcol);  // и еще чуть-чуть
      header('Content-Type: image/png');
      imagepng($im);
      imagedestroy($im);
   }
   private function generateSymbols()   // генерация четырех цифр
   {
      $this->string=$this->leadingZero(rand()%10000,4);
   }
   private function leadingZero($num,$length) // дополнения числа num лидирующими нулями
   {                        // до длины length
      $str=strrev($num);
      for($i=strlen($str);$i<$length;++$i)$str.="0";
      return strrev($str);
   }
   private function randomString($length)  // генерируем случайный набор символов заданной длины
   {
      $list="abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVXYZ!@#$%^&**()-=_+.,<>/\|;:";
      for($i=0,$str="";$i<$length;++$i)$str.=substr($list,mt_rand(0,strlen($list)-1),1);
      return $str;
   }
}
?>

Слегка доработав его и приведя в более подходящий вид, можно добиться генерации изображений, выглядящих например вот так:

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

Три основных компонента парадигмы объектно-ориентированного программирования

Иван Блинков — Sat, 05 Jan 2008 22:28:00 +0300

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

Вы спросите у меня: как это все может быть связано с темой этой записи? - об этом я и собираюсь Вам поведать.

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

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

наследование
инкапсуляция
полиморфизм

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

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

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

class Human
{
  public int height; // рост
  public int age; // возраст
  public String gender; // пол
  public String eyesColor; // цвет глаз
  public String hairColor; // цвет волос
}

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

class Human
{
  public int height; // рост
  public int age; // возраст
  public String gender; // пол
  public String eyesColor; // цвет глаз
  public String hairColor; // цвет волос
  public void walk()
  {
    System.out.println("Я иду!");
  }
  public void work()
  {
    System.out.println("Я работаю в большом офисном здании");
  }
}

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

Наследование

В отличии от реальной жизни, в рамках данной концепции наследование относится не к материальным вещам, а к переменным и методам класса. Тот класс, который передает "наследство", принято называть базовым, а получателя "наследства", соответственно - наследующим. Наследующий класс в дополнение к собственным методам и переменным получает еще и полный доступ ко всем переменным и методам базового класса (за некоторым исключением, о котором пойдет речь при разговоре об инкапсуляции, но обо всем по порядку).

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

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

class Director
{
  public int height; // рост
  public int age; // возраст
  public String gender; // пол
  public String eyesColor; // цвет глаз
  public String hairColor; // цвет глаз
  public void walk()
  {
    System.out.println("Я иду!");
  }
  public void work()
  {
    System.out.println("Я работаю в большом офисном здании");
  }
  public void idle()
  {
    System.out.println("Я ничего не делаю!");
  }
}

Но такой подход годится только для людей даже краем уха не слышавших об ООП, ведь он далеко не самый эффективный, особенно с точки зрения затрачиваемого на написание кода времени. Воспользовавшись механизмом наследования, можно сократить как объем кода, так и время, затраченное на его написание. В используемом для примеров языке программирования Java, для этого достаточно лишь указать в заголовке наследующего класса ключевое слово extends и название базового класса. Аналогичный предыдущему класс с использованием этого механизма существенно упрощается:

class Director extends Human
{
  public void idle()
  {
    System.out.println("Я ничего не делаю!");
  }
}

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

Полиморфизм

Это слово пришло к нам из греческого языка, понимания этого термина легко достичь, просто переведя его на русский язык: πολύμορφος - многоформенность. То есть в наиболее простом случае подразумевается использование одной и той же переменной (или массива) для хранения информации об объектах, описываемых разными классами. Представим, что нам необходим стандартизованный способ узнать кем же работает тот или иной человек, естественно для этого необходимо описание соответствующего метода для выполнения этой функции в каждом классе, причем он должен одинаково называться в каждом из них. Для реализации этого примера на языке Java нет необходимости использовать дополнительных ключевых слов (в отличие от, например, C#, где необходимо использование слова virtual в заголовке метода в базовом классе и override - в производных). Продолжая приводить примеры на Java имеем три производных класса (для упрощения опустим дополнительные методы, которые могли бы присутствовать):

class Director extends Human
{
  public void work()
  {
    System.out.println("Я работаю директором!");
  }
}

class Programmer extends Human
{
  public void work()
  {
    System.out.println("Я работаю программистом!");
  }
}

class Manager extends Human
{
  public void work()
  {
    System.out.println("Я работаю менеджером!");
  }
}

Для того, чтобы воспользоваться механизмом полиморфизма достаточно лишь написать функцию, которая будет создавать экземпляры наших классов и "спрашивать" к них кем они работают, выглядит это ничуть не сложнее, чем и описания классов, хочу лишь обратить Ваще внимание на то, что полиморфная переменная должна иметь тип базового класса:

class AskHuman
{
  public static void main(String[] args)
  {
    public Human person;
    person = new Director();
    person.work();
    person = new Manager();
    person.work();
    person = new Programmer();
    person.work();
}

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

Я работаю директором! Я работаю менеджером! Я работаю программистом!

Этот механизм расширяет возможности использования классов, позволяя более гибко использовать переменные и методы (да, этот механизм справедлив и для методов), а также позволяет писать более абстрактные программы и существенно упрощает работу программ, имеющих модульную структуру.

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

interface Worker
{
  public void work();
}

class Director extends Human implements Worker
{
  public void work()
  {
    System.out.println("Я работаю директором!");
  }
}

class Programmer extends Human implements Worker
{
  public void work()
  {
    System.out.println("Я работаю программистом!");
  }
}

class Manager extends Human implements Worker
{
  public void work()
  {
    System.out.println("Я работаю менеджером!");
  }
}

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

Инкапсуляция

Наверняка Вы уже задавались вопросом о том, что же значит слово public во всех предыдущих примерах. Это ключевое слово является частью реализации механизма инкапсуляции в языке Java, суть его состоит в том, чтобы дать возможность определить область видимости для составных частей класса, это очень актуально при написании ПО, использующего библиотеки, plug-in'ы или при написании программы группой людей. Ведь если Ваш класс подразумевает какие-либо ограничения для переменных или методов (например - возраст не может быть отрицательным), то их легко обойти воспользовавшись прямым доступом к ним из-за пределов класса или просто выполнив наследование.

Для предотвращения этого используется система параметров, назначаемых переменным и методам внутри класса для присвоения им "уровней доступа" (на примере опять же Java, но в большинстве известных мне высокоуровневых языков используется та же система):

public - назначается по-умолчанию - полностью свободный доступ
private - доступ предоставляется только другим компонентам класса
protected - доступ предоставляется остальным компонентам класса, а также всем наследникам данного класса

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

Вместо заключения

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

Объектно-ориентированное программирование: а что же это?

Иван Блинков — Fri, 04 Jan 2008 21:39:00 +0300

Находишься в поисках способов облегчить свой труд в процессе написания программного обеспечения? - об одном из них мы сегодня и поговорим.

Сама концепция этого подхода к программированию достаточно проста для понимания, и заключается она в...

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

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

Для начала напомню тот факт, что в языках высокого уровня простейшими элементами, доступными программисту, являются:

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

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

Класс

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

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

Объект

Для простоты понимания это слово можно воспринимать буквально - как некую сущность, находящуюся в каком-либо состоянии и имеющую возможность совершать некий набор действий. Также как и реальные объекты, объекты "компьютерные" живут своей жизнью: рождением считается создание объекта (выделение памяти), а смертью - уничтожение (освобождение памяти). Промежуток между этими двумя событиями принято называть временем жизни объекта.

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

Все написанное выше можно считать лишь неким подобием введения в ООП, дающим поверхностное представление о том, что же понимают под этой странновато звучащей фразой, и на какие же ""объекты" нужно "ориентироваться". Сама же теория является намного более обширной, и я собираюсь еще не раз вернуться к ее обсуждению в теории и с более практической точки. Например, возможно для многих остался не ясным вопрос: какие же преимущества предоставляет использование ООП перед более традиционным функциональным программированием? Ответить на него я и собираюсь в одном из следующих постов, не пропустить публикацию которого можно с помощью RSS.