Однако таких доводов далеко не хватает, чтобы начать погружаться в ОО. Так почему же нам следует использовать ОО? Попытки решать повседневные реальные проблемы с программным обеспечением часто становятся сложными и ОО лучший помощник. Знаю, многие из вас не согласятся с этим утверждением, но за долгое время работы все гиганты в разработке программного обеспечения согласились, что ОО является самым лучшим решением проблем в наших системах программного обеспечения. Чем больше вы хотите возможностей в ваших приложениях, тем сложнее становится управление ими, а управление объектами на много лучше, чем любая другая методология.
На много легче разрабатывать маленькие, цельные объекты, а также разрабатывать взаимодействия между этими объектами, чем делать что-то одно и делать это хорошо. Я полностью признаю, что обладаю сильными познаниями в Java, поэтому эти понятия во мне на столько устоялись, что по другому уже и думать не могу, но, в то же время, я все еще думаю, что большинство из нас еще не погрузилось в ОО, потому что мы думаем, что это слишком сложно. В действительности же, это упростит вашу разработку. Вы будете создавать вещи легче, ваши приложения станут гораздо более содержательными и гибкими. Однажды, поняв идеи ОО, я гарантирую, что у Вас наступит момент озарения, и Вы уже никогда не захотите делать вещи каким-то другим способом.Почему ColdFusion разработчики должны изучать Java, ведь у нас есть CFC, а это и есть объекты? Да, CFC это объекты, но существуют некоторые фундаментальные идеи истинного ООП, которые не присутствуют в CFC. Но это не повод отказываться от CFC; я использую CFC везде, где могу, и буду продолжать это делать. Когда мы говорим об изучении ООП, Java предоставляет более наглядный способ изучения этих идей, чем CF.
Среди самых известных языков Java является самым наглядным представителем ОО. Java предоставляет превосходные инструменты для легкого написания сложных приложений, но это не означает, что Java сама по себе сложна. Все мы хотим создавать крепкие и содержательные приложения, но не все системы (и CF в их числе) позволяют следовать такому виду разработки. В CF можно создать такие вещи, которые Java даже не позволит скомпилировать. Такой подход позволяет отслеживать потенциальные ошибки в процессе разработки и делает приложения более крепкими и безопасными.Однако, как и во всем, существует компромисс. Java - чрезвычайно обширный язык и требует очень много времени для хорошего изучения. Но это не значит, что начинать изучение тяжело, но когда мы говорим "Я Java разработчик", то это подразумевает, что было потрачено много времени, чтобы подняться на этот уровень. Бен Эдвардс (Ben Edwards), который работает с Хелом Хельмсом (Hal Helms) над Mach-II, преподает Java и имеет хорошие отзывы от Хела. Однажды они разговаривали с некоторыми программистами о Java, и один из них сказал: "Знаете что? Я ПОНАСТОЯЩЕМУ знаю Java.". Бен ответил: "Это все равно, что сказать Я по-настоящему знаю науку".
К счастью, начать изучать Java очень легко. Когда я начинал изучение Java, у меня не было выбора – мой работодатель просто отправил меня на курсы в Sun Microsystems, и создавать что-то на Java требовала моя работа. В то время я работал с CF 4 и идти на эти курсы было устрашающе. Первый пройденный мной курс был "Мигрирование на ОО программирование с помощью Java технологии". Мы не писали код, а только обсуждали идеи и рисовали много диаграмм объектов и простых приложений. На этом курсе ко мне пришел момент озарения и, с тех пор, для меня стало сложным вернуться обратно и думать о программировании как-то по-другому. Возвращение к CF 4, а позже 4.5 и 5, было очень болезненным. До выхода CFMX я уже занимался Java несколько лет и, когда я перешел в моей компании на другую должность и собирался снова заняться CF программированием, я по настоящему был счастлив увидеть, что в CF теперь есть некоторые возможности ОО.Вернемся к Java. Если я CF разработчик, почему я должен учить Java? С тех пор, как CFMX работает на платформе J2EE мы можем делать потрясающие вещи путем совместного использования этих двух технологий. CFML является фантастическим представителем технологии промежуточного (middle-tier) уровня, но когда на стороне сервера вещи становятся по настоящему сложными, то на некотором уровне CFML сдает свои позиции. Java не так уж и хороша на стороне клиента, но чрезвычайно мощна на стороне сервера и может предложить возможности на том уровне, где CFML не подходит.
Кроме того, Java соблюдает широко устоявшиеся правила, а ColdFusion нет. Это не камень в огород CF, т.к. он для этого и не разрабатывался. Java компилятор можно сравнить с учителем пианино, который бьет вам по рукам указкой, когда вы делаете что-то не так. Например, если вы объявили переменную Х как integer и позже пытаетесь присвоить ей строковое значение х=”строка”, то Java даже не даст вам скомпилировать этот код, и вы получите сообщение об ошибке, указывающее на причину. Это может показаться раздражающим, но это необходимо для построения крепкой программы.Итак, что именно делает ОО для управления сложностью? Хел разбил эти действия на три области в порядке их важности:
Полиморфизм также важен, и в большей степени для расширяемости и возможности поддержки. В качестве примера Хел приводит разного вида покупателей, которые оплачивают счет разными способами. С точки зрения возможности поддержки, если у вы должны добавить новый метод для каждого вида платежа каждый раз, когда вы добавляете нового покупателя, то все очень быстро становится безобразно. Но, если у вас есть метод payBill() для всех видов покупателей (кредитная карта, наличные и т.д.) и каждая реализация определяет как счет оплачивается, то системе безразлично – она просто вызывает payBill() и все происходит как надо. На одном из моих занятий по Java я запомнил пример, в котором круг, треугольник и квадрат все нарисованы разным способом, но каждый объект содержит свой метод draw(). Система просто вызывает draw() и не беспокоится о деталях. Мощная штука.
Наследование возможна та вещь, которая используется новичками слишком активно и не всегда к месту. Многие видят наследование повсюду и используют его везде, где только можно. В действительности же наследование должно использоваться только в определенных обстоятельствах. На ум приходи один хороший пример, в котором есть основной класс Person (Человек), а классы Employee (Работник) и Customer (Покупатель) наследуют от Person. Таким образом в классах Employee и Customer содержится все, что есть в классе Person: имя, адрес, телефон и т.д., - но также есть и какие-то свои свойства и методы. Очевидно, что вы не будете платить зарплату Покупателю! При грамотном использовании наследование помогает исключить дублирование. CFC очень хорошо поддерживают наследование.Как уже упоминалось, Java также невероятно прямолинейна, когда дело касается типов данных (об этом также говорят "сильно типизирована"). Если один программист создал объект, в котором определил переменную Х как integer, то другой программист не сможет использовать ее как string. CF позволяет это, а Java нет. При таком подходе Java гарантирует большую безопасность и исключает большинство ошибок при исполнении программы.
Самая важная вещь, которую нужно запомнить: ОО не сложно. Процедурные программисты просто должны избавиться от привычки думать процедурно. Если вы хорошо поймете ОО концептуально, то написание самого кода вас уже не остановит.Кроме того, Хел уделил внимание тому, что на производительность уже не стоит обращать внимание так, как это делалось раньше. В большинстве случаев производительность Java не уступает C++, а иногда и превышает ее. Если вы все еще думаете о Java как о неповоротливом монстре, то пора уже пересмотреть свои взгляды.
Проводя сравнения между процедурным и объектно-ориентированным программированием Хел указывает, что в процедурной программе мы меняем данные напрямую: name = "Matt"; В ОО мы делаем запрос к компоненте с командой установить name. Мы никогда не обращаемся к данным напрямую:mattComponent.setName("Matt");
Это делается для обеспечения безопасности и повышения сложности.В итоге мы пришли к основному вопросу. Почему Java? Такие .NET языки как C# и VB .NET являются объектно-ориентированными, но и CFML в версии MX также содержит элементы OO, так почему же CF программистам нужна Java? Во-первых, говорит Мэт Вудвард (Matt Woodward), Java является одним из самых чистых представителей OO, и, чтобы перейти с процедурного к объектно-ориентированному программированию, глубокие познания ОО являются решающими. Java - это лучший способ получить эти глубокие познания. Во-вторых, как начал Хел Хельмс (Hal Helms): "В 2004 году, отсутствие глубоких познаний OO влечет за собой карьерное самоубийство". Кроме того, Вам просто необходимо ознакомиться с ОО и начать его использовать, т.к. сейчас весь мир ожидает именно такой вид программирования.
Кроме теоретических, существует еще много практических причин для изучения Java. Как упоминалось ранее, Java не выглядит так доступно к CF, но CF не предоставляет тот уровень возможностей на стороне сервера, который предлагает Java. Таким образом, для достижения наилучшего результата следует совместно использовать обе технологии. Хел далее приводит аргументы, что если вы создали все на CFC без учета паттернов MVC, то если/когда вам это понадобиться, вы сможете перевести ваши CFC в Java объекты без влияния на вашу систему.Хел также обращает внимание, что вам не обязательно учить всю Java, но мы должны знать хотя бы основы и по необходимости уметь применять основные элементы Java.
© 2002-2005 г. Вадим Пушкарев