Да вся теория такая - понимаешь только после того, как попробовал. Поэтому теорию нужно читать несколько раз (как минимум - два раза).
Можно, однако велосипеды обходятся дороже по времени их изготовления.Ну эт не факт, не факт.Эти принципы - это те же шаблоны, просто их знание ничего не дает без опыта. Возьмем все те же OOD Principles, на которых строятся шаблоны, - ну их много кто знает, но кто умеет правильно пользоваться? Единицы. Потому что прочитать-то прочитали, но понастоящему не поняли. Для этого и нужен опыт.Ну никто и не говорил, что знание шаблона - это знание названия. Может ты их все знаешь, просто в названиях не силен.Так делают все начинающие, просто прочитав о шаблоне ты его не освоишь, нужен опыт (как и в OOD принципах).
Итого, что я пытаюсь донести - работать можно и без теории, однако обучаешься/развиваешься тогда намного медленней, чем если знать теорию. Это раз. А два - это то, что ты качество своей работы не гарантируешь, пока не знаешь теорию, используешь себе какую-то технологию, используешь, думаешь правильно, а потом через месяц узнаешь то, о чем не предполагал, и что, как оказалось, какашко-код писал. Так вот, шаблоны - эта та теория, которая должна ити перед практикой для того, чтоб ускорить обучение.

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

Это сообщение отредактировал(а) sergioK - 21.12.2010, 08:53

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

Принципы объектно ориентированного проектирования (в видео докладе более подробно рассказывается, нежели в самом туториале).
Также откройте для себя крайне полезный ресурс: oodesign.com
И еще следует прочитать Head First OO Analysis and Design, ну а потом и Head First Design Patterns.

низкое связывание и высокое сцепление 

что это такое? Я не силен в терминах тем более на русском 

Попробую объяснить в двух словах.  Связывание (Coupling) есть мера взаимозависимости нескольких абстрактных программных компонент. Это могут быть отдельные классы, слои (tiers) или огромные enterprise-системы если мы строим интеграционное решение для их взаимодействия. В идеале нужно стремится к низкому связыванию (low coupling) для того, чтобы можно было менять компоненты независимо друг от друга. Причем я имею ввиду не только код, но и протоколы взаимодействия равно как и прочие допущения и соглашения, сопровождающие процесс разработки. Противоположенным полюсом является высокая связность компонент (High/Tight Coupling), когда один полагается на реализацию (не интерфейс!) другого.

Классификаций степени связности существует довольно много, например Sun Oracle при сдаче SCJP требует уметь различать три градации:

•  Loose coupling - работаем с реализацией только по интерфейсу
•  Abstract coupling - работаем с реализацией как с реализацией абстрактного суперкласса
•  Tight coupling - работаем с реализацией как с конкретной реализацией

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

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

Вот это почитайте: http://www.skipy.ru/architecture/module_design.html

Поскольку термин "связывание" там не употребляется - поясню. Чем ниже связывание - тем проще переиспользовать. Собственно, вся статья про методы уменьшения связывания.

Это сообщение отредактировал(а) Skipy - 21.12.2010, 13:37

1)Не хорошо, то что конструктор  должен выбрасывать исключение, вы не знаете создался объест или нет.
2) Очень странно что все эти приемы не преподают на 3-4курсах, когда люди уже более или менее умеют писать/кодить.




Это сообщение отредактировал(а) sergioK - 21.12.2010, 16:56

Интересная получилась тема. Может ее перенести в ветку Java: Design, Quality, Testing?