Разочарования шаблона разработки
Я - разработчик, имеющий 4 года .NET, кодирующего опыта, И никогда не заботился очень о шаблонах разработки в моей карьере. Недавно меня позвонили для интервью с одной из важных персон в IT, сделал 5 раундов (решение задач, программирование пары, логическое обоснование, 2 раунда технического интервью) интервью и не предложил задания.
Обратная связь, которую я получил от них, не хорошо в принципах разработки, хотя они удовлетворены моими техническими и логическими навыками обоснования. Этот заставил меня думать, что шаблоны разработки знания являются единственным способом решить проблемы?
Хотя я никогда не использовал большую часть из шаблоны разработки в моем кодировании, я всегда пробовал к implelement основные принципы OOPS
- Откройтесь/закройте принцип (OCP)
- Инверсия зависимости (DI)
- Интерфейсная сегрегация
- Liskov substituion принцип (LSP)
Я мог использовать эти принципы для разработки системы, это слабо связывается и открыто для улучшений и легкое поддержать. Eventtually это базовые конструкции всех шаблонов разработки.
Но моя проблема состоит в том, чтобы найти правильный шаблон для правильной проблемы. Я знаю, что это знание не прибудет, просто читая все книги, опубликованные в шаблонах разработки и практике. это знание идет с опытом создания различных систем.
Есть ли любые варианты использования, доступные для соответствия проблемы шаблона.. И Ваше предложение при изучении принципов разработки?
Удачи
6 ответов
Хотя я думаю, что не помешает поближе познакомиться с паттернами проектирования, я хочу убедиться, что в вашем вопросе нет смешения двух вещей. Вы сказали, что по отзывам, которые вы получили, ваша способность применять принципы дизайна была слабой, и вы сделали вывод из этого отзыва, что вам нужно изучать паттерны дизайна. Но это совсем другое.
Паттерн проектирования - это повторяющийся шаблон, который вы видите во многих различных областях. Например, в архитектуре вы видите паттерн "внутренний двор" во многих различных типах зданий. В программировании вы видите шаблоны типа "класс, который может иметь только один экземпляр" или "маленький кусочек кода, который склеивает это с тем" во многих различных видах программ.
Но принципы - это не шаблоны. Шаблон - это конкретный повторяющийся вид дизайна; принцип - это идея, лежащая в основе того, что делает дизайн хорошим для пользователей проектируемого артефакта.
Например, принцип проектирования языка JScript гласит: "Будьте снисходительны к небольшим ошибкам". Если вы создадите объект даты для 31 ноября, он молча исправит ее на 1 декабря вместо того, чтобы выдать ошибку. Нет никакого "шаблона прощения мелких ошибок". Сделать дизайн устойчивым к ошибкам - это принцип проектирования - когда у нас есть выбор, как спроектировать конкретную функцию, мы рассматриваем, насколько хорошо она соответствует всем принципам - некоторые из которых противоречат друг другу - и используем их для проектирования функции.
Это не принцип проектирования C#; на самом деле, наоборот, это принцип проектирования C#. Принципы проектирования сами по себе не являются хорошими или плохими; они представляют собой руководство по тому, что делает проект хорошим для целевого набора пользователей .
Писать код без понимания паттернов - значит не иметь в своем арсенале инструментов, которые облегчают выполнение обычных задач. Написание кода без понимания принципов проектирования означает написание непоследовательного, сложного для понимания и противоречащего потребностям пользователей кода. И то, и другое важно, но это совершенно разные вещи.
Даже если вы используете C#, я бы посоветовал просмотреть некоторые книги по паттернам. Первой будет книга GoF - Design Pattens. Затем попробуйте прочитать какую-нибудь книгу по Enterprise Design Patterns. По мере чтения вы узнаете (или увидите) паттерн. Обычно это момент "Ага".
Вы также узнаете то же самое в своем собственном коде. Знание паттернов поможет вам в хорошем проектировании. Знание паттернов помогает в том, что вы сразу вспомните паттерн, когда возникнет проблема, связанная с ним.
Указанные вами принципы программирования хороши, и я следую им. Однако они относятся скорее к уровню класса. При переходе на более высокий уровень проектирования системы паттерны будут более полезны.
Самое главное - паттерны дают вам словарный запас для обсуждения идей проектирования со всей командой.
Я уверен, что вы использовали некоторые паттерны проектирования, если вы программируете уже 4 года, хотя вы можете и не знать, что вы это делали.
Паттерн проектирования научит вас решать проблему, которую кто-то уже решил и нашел для нее решение, и, наконец, задокументировал его для нас.
Если вы хотите изучить паттерны проектирования, вы можете начать с "Head First Design Patterns" - это отличная книга.
Я не уверен, что вам действительно нужны паттерны проектирования. Возможно, вам нужно более общее понимание дизайна. Дать более подробный совет по этому поводу будет сложно без дополнительной информации.
Паттерны проектирования (в стиле GoF) лучше всего работают с определенным стилем написания кода. Представьте ваши классы не как вещи, а как людей. Представьте, что эти люди общаются друг с другом, например, передавая записки, или через межотдельскую почту, или что-то в этом роде.
В целом, способы, которыми эти люди общаются, и паттерны потока сообщений довольно близки к паттернам проектирования GoF. Шаблоны, которые не соответствуют этому, обычно являются "помощниками", которые необходимы для написания приложений, соответствующих этой модели.
Попробуйте эту книгу, она забавная и дает вам не только, как реализовать шаблон, но и когда это делать.
http://www.amazon.com/First-Design-Patterns-Elisabeth-Freeman/dp/0596007124
Шаблоны проектирования называются шаблонами, потому что они снова и снова появляются во многих независимых программах, а не потому, что они используются для составления программ так же, как квадраты сшиваются вместе для создания одеяла. Они могут помочь прийти к решению программной проблемы, но сами по себе они не являются решением".