Философия Java


Резюме - часть 2


[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).

[ Предыдущая глава ] [ Краткое содержание ] [ Содержание ] [ Индекс ] [ Следующая глава ]




Начало  Назад  Вперед



Книжный магазин