Шаблоны разработки, которые должен знать каждый разработчик?

Инверсия управления

Если вы когда-нибудь собираетесь разрабатывать разделенные системы, вам необходимо знать, как правильно связывать зависимости между классами.

Шаблон команды и варианты

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

Factory Pattern

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

Синглтон (шаблон и анти-шаблон)

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

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

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

Самым большим преимуществом, которое я обнаружил для шаблонов проектирования, является использование общего набора имен. Если кто-то говорит «Обратный вызов», это может означать довольно много вещей, но если кто-то говорит «Шаблон слушателя», это означает более конкретный набор вызовов и подразумевает более высокий уровень отношений между объектами.

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

Я бы не стал полностью игнорировать ни один из них - они все приятно видеть.

Модель – представление – контроллер просто должны быть в списке, Spring имеет структуру MVC:

http://en.wikipedia.org/wiki/Model–view–controller

Я рекомендую вам прочитать Шаблоны проектирования Head First кн. Это хорошо написанная книга обо всех общих и полезных шаблонах.

Я бы порекомендовал вам достать и прочитать книгу Design Patterns, поскольку она дает вам словарный запас.

Но не забывайте основы :)

Интервью Java-разработчиков со слезами на глазах http://java.sys-con.com/node/1040135

Hibernate? Тогда Unit Of Work является обязательным http://martinfowler.com/eaaCatalog/unitOfWork.html

Composite, он присутствует в структуре JUnit. (Test-TestCase-TestSuite)

Шаблоны Adapter, Builder, Command, Template Method и Strategy просты и часто используются на практике.

Шаблон State также помог мне навести порядок в унаследованных исходных кодах.

Это было бы комментарием к ссылке Грега Хьюджилла на «Одиночки - патологические лжецы», но я пока не могу комментировать.

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

Перечитайте статью. Его не беспокоит то, что OfflineQueue нуждается в инициализированном экземпляре базы данных или что CreditCardProcessor нуждается в инициализированной OfflineQueue. Его беспокоит то, что эти зависимости не видны, что вызывает проблемы с ремонтопригодностью и тестируемостью.

Его проблема связана с секретным глобальным состоянием ( это звучит как сторонник теории заговора? ).

Однако, он (imo) неверно интерпретирует это секретное глобальное состояние как вину синглтонов.

Это не значит, что я сторонник синглтонов, где они не нужны - конечно, у них есть недостатки (включая очевидное узкое место конфликта потоков возможность). Но я предпочитаю четко указывать, каких практик я избегаю.

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

    card.charge(cardProcessor, 100);      

я бы имел вместо этого:

    cardProcessor.chargeCard (card, 100);

(и да, я заменил его имена переменных c и ccp на имена, которые я считал более читаемыми)

m в пользу синглтонов, где они не нужны - конечно, у них есть недостатки (включая очевидную возможность узкого места из-за конфликта потоков). Но я предпочитаю четко указывать, каких практик я избегаю.

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

    card.charge(cardProcessor, 100);      

я бы вместо этого:

    cardProcessor.chargeCard (card, 100);

(и да, я заменил его имена переменных c и ccp именами, которые я считал более читаемыми)

m в пользу синглтонов, где они не нужны - конечно, у них есть недостатки (включая очевидную возможность узкого места из-за конфликта потоков). Но я предпочитаю четко указывать, каких практик я избегаю.

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

    card.charge(cardProcessor, 100);      

я бы имел вместо этого:

    cardProcessor.chargeCard (card, 100);

(и да, я заменил его имена переменных c и ccp на имена, которые я считал более читаемыми)

Синглтоны - Синглтоны, очевидно, можно и нужно использовать для всего

Каждый должен знать о синглтоне, но также когда не его использовать! В настоящее время для меня это источник большой боли при работе над проектом.

Синглтоны затрудняют понимание кода и усложняют его выполнение, а также значительно затрудняют написание модульных тестов. Мне нравится сообщение в блоге Синглтоны - патологические лжецы .