|
Читайте также: |
Когда начинаете с вашей командой работать в ООП и Java, программисты обычно проходят через ряд общих ошибок дизайна. Это часто случается из-за недостаточной обратной связи с экспертом во время дизайна и реализации ранних проектов, потому что в компании нет экспертов разработки и, поэтому, может быть сопротивление в получении консультации. Легко слишком рано почувствовать, что вы понимаете ООП и уйти по касательной. Что-то являющееся очевидным для кого-то опытного в языке, может быть предметом больших внутренних обсуждений для новичка. Многие из этих травм можно пропустить, используя опят внешнего эксперта для тренировки и руководства.
Java против C++?
Java во многом выглядит как C++ и так естественно кажется, что C++ будет заменен Java. Но я начал с вопроса о такой логике. Для одних вещей C++ все еще имеет некоторые особенности, которых нет в Java, и, хотя, имеется много обещаний относительно того, что однажды Java станет быстрее чем C++, мы видели равномерные усовершенствования, но никаких разительных достижений. Так же продолжается определенный интерес к C++, так что я не думаю, что этот язык скоро отомрет. (Языки, кажется, висят вокруг. Разговаривая на одном из моих “промежуточный/продвинутый семинар по Java”, Allen Holub заявил, что два наиболее часто используемых языка - это Rexx и COBOL, в таком порядке.)
Я начинаю думать, что сила Java лежит в небольшом отличие области действия, по сравнению с C++. C++ - это язык, который делает попытку заполнить шаблон. Несомненно, он был адаптирован определенными способами для решения определенных проблем. Некоторые инструменты C++ комбинируют библиотеки, модели компонентов и инструменты генерации кода для решения проблемы разработки оконных приложений для конечного пользователя (для Microsoft Windows). И теперь, И все таки, что используют большинством разработчиков для Windows? Microsoft Visual Basic (VB). Несмотря на факт, что VB производит код, который становится неуправляемым, когда программа становится несколько страниц длины (и синтаксис, который положительно может мистифицировать) Так как есть успех и популярность VB, но это не очень хороший пример языкового дизайна. Было бы хорошо иметь легкость и мощность VB без неуправляемого результирующего кода. И в этом, я думаю, Java будет блистать: как “следующий VB”. Вы можете содрогнуться или нет, услышав это, но думать о том, как много в Java предназначено для упрощения программисту решений проблем уровня приложения, таких как работа в сети и кросс-платформенность, и теперь есть дизайн языка, который позволяет создание очень больших и гибких тел кода. В добавок к этому Java фактически имеет наиболее крепкий тип проверки и обработки ошибок системы, из того что я видел в языках, так что вы можете сделать существенный прыжок вперед в производительности программирования.
Должны ли вы использовать в ваших проектах Java вместо C++? Не в Web апплетах есть две проблемы для исследования. Первая, если вы хотите использовать много существующих библиотек C++ (и вы, конечно, получите большую прибавку производительности), или вы имеете существующий базовый код на C или C++, то Java может замедлить вашу разработку, а не ускорить ее.
Если вы разрабатываете весь ваш код, начиная с шишек, то простота Java по сравнению с C++ значительно сократит время разработки — рассказы очевидцев (истории команд C++, с которыми я говорил и кто перешел на Java) сообщают об удвоении скорости против C++. Если производительность Java не имеет значения или вы можете чем-нибудь компенсировать это, явные проблемы времени-до-продажи делают затруднительным выбор C++ против Java.
Наибольшая проблема - производительность. Интерпретатор Java - медленный, даже в 20-50 раз медленнее, чем C по сравнению с обычным интерпретатором Java. Это улучшится через какое-то время, но все еще будет оставаться значительным числом. Компьютеры о скорости; если бы что-то значительно быстрее было сделать на компьютере, то вы бы делали это руками. (Я даже слышал советы, что вы занимаетесь Java чтобы сократить время разработки, чтобы затем, используя инструменты и библиотеки поддержки, переводите ваш код на C++, если вам необходимо высокая скорость выполнения.)
Ключевым моментом, делающим Java подходящим для большинства проектов - это появление ускорителей, называемый “just-in time” (JIT) компилятор, собственная “hotspot” технология Sun, и компиляторов платформозависимого кода. Конечно, компиляторы платформозависимого кода устранят рекламируемое кросс-платформенное выполнение скомпилированной программы, но они так же повысят скорость выполнения, приблизив ее к C и C++. А кросс-платформенная программа на Java будет много легче, чем если это делать на C или C++. (Теоретически, вы должны просто перекомпилировать, но это обещание было сделано и для других языков.)
Вы можете найти сравнения Java и C++ и обзор использования Java в первой редакции этой книги (Эта книга доступна на сопровождающем CD ROM, так же как и на www.BruceEckel.com).
Резюме
В этой главе осуществлена попытка дать вам почувствовать большинство проблем объектно-ориентированного программирования и Java, включая ту, чем отличается ООП и чем обычно отличается Java, концепцию ООП методологий и, наконец, виды проблем, обнаруживаемые при переходе вашей компании к ООП и Java.
ООП и Java не могут быть для всех. Важно оценить свои собственные требования и решить будет ли Java оптимально удовлетворять вашим требованиям или, если это лучше, использовать другую систему программирования (включая те, которые вы используете сейчас). Если вы знаете, что то что вам нужно будет очень специфичным в обозримом будущем, и если вы имеете специфические ограничения, которые Java не сможет удовлетворить, то вам необходимо исследовать альтернативы [19]. Даже если вы, в конечном счете, выберете Java как свой язык, вы, по крайней мере, поймете, что выбор имел и имеет ясное видение, почему вы выбрали это направление.
Вы знаете как выглядят процедурные программы: определение данных и вызов функций. Чтобы найти значение этой программы, вам нужно немного поработать, просмотреть вызовы функций и низкоуровневую концепцию для создания модели в вашем уме. По этой причине мы нуждаемся в промежуточном представлении при разработке процедурной программы — сами по себе эти программы имеют тенденцию быть запущенными, потому что термины выражений больше ориентируются на компьютер, чем на решаемую проблему.
Поскольку Java добавляет много новых концепций поверх того, что вы находите в процедурных языках, ваше естественным предположением может быть то, что main() в программе Java будет более сложным, чем для эквивалентной программы C. Но здесь вы будите удивлены: хорошо написанная Java программа обычно более проста и легка в понимании, чем эквивалентная C программа. Как вы увидите - определение объектов, представляющих концепцию в вашей проблемной области (скорее, чем проблему компьютерного представления), и сообщений, посылаемых этим объектам, представляют активность в этой области. Одно из поразительных свойств объектно-ориентированного программирование в том, что хорошо разработанную программу легче понять при чтении кода. Обычно это много меньше кода, поскольку многие ваши проблемы будут решены с помощью кода библиотек многократного использования.
[2] Смотрите Multiparadigm Programming in Leda Timothy Budd (Addison-Wesley 1995).
[3] Некоторые люди делают различия, заявляя, что тип определяет интерфейс, в то время как класс - обычная реализация этого интерфейса.
[4] Я в долгу перед моим другом Scott Meyers за этот термин.
[5] Это обычно достаточно детализировано для большинства диаграмм, и вам нет необходимости указывать будете ли вы использовать агрегирование или композицию.
[6] Мой термин.
[7] Примитивные типы, которые вы выучите позже - специальный случай.
[8] Великолепный пример такой UML Выборки, 2е издание Martin Fowler (Addison-Wesley 2000), который снижает иногда перегруженный UML процесс до управляемого набора.
[9] Мое правило большого пальца для оценки таких проектов: Если есть больше одной пустой карточки, даже не пробуйте планировать сколько времени это займет или сколько это будет стоить, пока не создадите рабочий прототип. Есть слишком много степеней свободы.
[10] Спасибо за помощь James H Jarrett.
[11] Подробнее об использовании причин можно найти в Applying Use Cases Schneider & Winters (Addison-Wesley 1998) и Use Case Driven Object Modeling with UML Rosenberg (Addison-Wesley 1999).
[12] Мой персональный взгляд на это изменился за последнее время. Удвоение и добавление 10 процентов даст вам разумный точный расчет (принимая во внимание не слишком много факторов пустых карточек), но вы все еще должны тщательно работать, чтобы успеть точно в это время. Если вы хотите работать действительно элегантно и наслаждаться в процессе - правильный множитель, я верю, три или четыре.
[13] Для начала я рекомендую вышеупомянутую UML Distilled, 2е издание.
[14] Python (www.Python.org) часто используется как “исполняемый псевдокод”.
[15] Не менее одного аспекта эволюции описано в книге Martin Fowler Refactoring: improving the design of existing code (Addison-Wesley 1999), который использует исключительно примеры на Java.
[16] Иногда это как “быстрое создание прототипов”, где вы, как предполагалось, строите быструю-и-грязную версию, которая помогает вам изучить систему, а затем выбрасываете прототип и строите правильный. Проблема быстрого создания прототипов в том, что люди не выбрасывают прототип, а вместо этого строят на нем. Вместе со слабой структурой процедурного программирования, это часто ведет к грязным системам, очень дорогими в поддержке.
[17] Хотя это может быть более американской перспективой, Голливудсткие истории достигают каждого.
[18] Включая (особенно) PA системы. Однажды я работал в компании, которая настаивала на радиовещании каждого телефонного звонка, приходящего каждому индивидуально, и это прерывало нашу продуктивность (но менеджеры не могли представить себе отмирание такой важной услуги, как PA). Наконец, когда никто не видел, я начал отрезать провода динамика.
[19] Обычно я рекомендую взглянуть на Python (http://www.Python.org).
Дата добавления: 2015-09-11; просмотров: 37 | Поможем написать вашу работу | Нарушение авторских прав |