Как быстро выучить иерархию классов?

Question

Что мне не нравится в программировании, так это изучение нового API. Например, сейчас я пытаюсь изучить Windows Identity Foundation. Это расстраивает, потому что я собираюсь потратить большую часть времени на изучение работы нескольких классов и на самом деле написать только несколько строк кода.

В .NET существует так много типов, что я, кажется, трачу больше времени на поиск класса в msdn, чем на написание кода. Это также прерывает мой рабочий процесс, когда я работаю, потому что мне нужно немного напечатать, чем что-то искать.

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

Мне интересно, нашел ли кто-нибудь способ запоминания (или более эффективного поиска) этих иерархий объектной модели?

Answer 1

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

Конечно, вам нужно знать, как организован API (или библиотека классов) и каковы его возможности, но нет смысла изучать, что является третьим параметром вызова функции X.

Answer 2

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

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

Answer 3

Я был на вашем месте также давным-давно, когда я изучал Java и ее классы Collection (или SWING, или AWT в этом отношении).

Вот несколько шагов, которые я сделал, и результат этих шагов:

• Не удосужился делать заметки, продолжайте использовать его => помните только самый используемый класс
• Возьмите неорганизованные заметки => тот же результат, запомните наиболее используемый класс
• Простые диаграммы классов => улучшение, но неполное
• Простые диаграммы классов, но с подклассами, организованными для каждого компонента (пакета в Java) => Джекпот!

Еще несколько советов:

• Устранить устаревшие классы
• Найти символ для обозначения класса является поточно-ориентированным (поставить TS или что-то еще)
• Вы можете опускать наименее используемые подклассы (возможно), когда будете продолжать приключение

Пример простой диаграммы классов:

• http://www.ged.fi/DesignPatterns/AWT.gif
• http://www3.ntu.edu.sg/home/ehchua/programming/java/images/IO-input-output-streams.png

Сравните с этим (не так просто):

• http://www.owlnet.rice.edu/~comp212/08-spring/lectures/30/reader.png

Надеюсь, это поможет.

Эд

Answer 4

Да, вспоминать обо всех этих API-интерфейсах - тоже проблема для меня ...

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

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

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

Answer 5

Ничего конкретного, чтобы предложить здесь в качестве ответа.

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

Хороший каркас

• легко подобрать и использовать без документации.Он просто работает так, как вы ожидаете, что он будет работать
• по-прежнему имеет отличную документацию, несмотря на пункт № 1.
• минималистичен.Наименьшее количество кода / классов / методов для выполнения работы.

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

Answer 6

Блин, я просто подумал, что я становлюсь старше !!!

Я пишу код Java, используя JMS, EJB, JNDI, JDBC, JSP, Сервлет, Struts, Struts, JTA, Swing, POI, GWT, GAE, JDO, IBM MQ MQ, JNI, XML, SAX, DOM, C ++, WIN32, а также наши собственные библиотеки классов и, вероятно, некоторые больше, чем я не могу вспомнить.

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

• Eclipse и Visual Studio имеют автозаполнения.
• Google - большая помощь. Используйте ее ежедневно.
• электронная документация.

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

Answer 7

Обычно я не столько изучаю API, сколько пытаюсь понять общие понятия о том, что делает API и как это происходит.

Итак, обычно начинайте с высокоуровневых блоков того, что делает API (обычно в документации), а затем нацеливайтесь на то, что вы хотите получить от API, и заставьте его работать с этими аспектами.

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

НТН.