Что должно быть на первом месте — шаблон разработки или код?
Вы можете использовать префикс Exec
using( SqlConnection con = new SqlConnection( "Server=.;database=employee;user=sa;password=12345" ) )
{
SqlCommand cmd = new SqlCommand( " exec ('drop table '+@tab)" , con );
cmd.Parameters.AddWithValue( "@tab" ,"Employee" );
con.Open( );
cmd.ExecuteNonQuery( );
}
8 ответов
Вы должны развивать свой код органично, применяя шаблоны по мере их соответствия. Слишком раннее сопоставление с шаблонами может привести к появлению большого количества несоответствующего кода и такого количества уровней абстракции, что дизайн станет запутанным. Посмотрите любой код, который вы видели, который был написан сразу после того, как кто-то впервые обнаружил закономерности; -)
- Определите варианты использования.
- Подумайте о дизайне, глядя на существующий шаблон проектирования.
- Начать реализацию.
Я считаю, что главная цель здесь - избежать изобретения колеса .
PS. После того, как вы пройдете шаг 2 несколько раз и привыкнете к нему, вы сможете интегрировать этот шаг в шаг 3.
Если шаблон явно не выходит за рамки спецификации, я бы не стал обязательно пытаться выбрать что-то из GoF и решать проблему, пока она не соответствует шаблону.
Лучше концептуально понять различные уровни абстракции в своей голове и придумать план (не обязательно популярный шаблон проектирования) того, как вы его реализуете. Это то, в чем вы научитесь лучше с опытом. Хотя знание шаблонов GoF поможет вам улучшить вашу способность думать о проблемах с точки зрения дизайна кода, они не предназначены для решения всех проблем, и искусственное принуждение вашей проблемы к тому, чтобы вписаться в шаблон проектирования, может означать излишнее усложнение и запутывание.
Если я когда-нибудь неуверен, я просто начну писать код. Вскоре структура начнет требовать некоторого рефакторинга, и выбор почти всегда очевиден.
Хотя меня иногда вдохновляет определенный шаблон, почти всегда именно код указывает мне правильный путь.
I Я также не боюсь сжечь и перестроить части программы. Мне очень нравится цитата Скотта Адамса: «Творчество - это позволять себе делать ошибки; искусство - это знать, какие из них оставить». Иногда правильный ответ не очевиден, пока вы не попробуете неправильно.
I'd stay away of patterning your coding too much by upfront design pattern usage. It is better to just make simple code and when needed refactor towards a design pattern that then captures your requirements best.
Перед тем, как приступить к кодированию, вы должны понимать, какие шаблоны подходят для данной проблемы. Если нет, сделайте прототип, чтобы понять, чего вы хотите достичь. Затем поищите шаблоны и выбросьте (структуру) прототипа (и повторно используйте хорошие части).
Хороший совет уже здесь. Чтобы ответить на вопрос о полезных шаблонах, помимо книги GoF. Есть, вы должны проверить применение UML и шаблонов Лармана, где он описывает шаблоны GRASP.
Вы должны развивать свой код органично, применяя шаблоны по мере их соответствия.
Seconded! Одни из худших спагетти, которые я видел, - это объектно-ориентированный C ++ с множеством шаблонов. Fluxbox еле терпимо; Synergy (v2) варить, жарить и запекать мою лапшу: (
И один из самых красивых кодов, которые я видел, - это OO C, где OO - это два интерфейса плюс 4 и 20 реализаций соответственно.