Вы используете шаблоны разработки?
Попробуйте изменить update="insTable:display" на update="display". Я считаю, что вы не можете префикс id с идентификатором формы.
14 ответов
Любая большая программа, которая правильно написана, будет использовать шаблоны разработки, даже если их не назовут или распознают как таковые. Это - каковы шаблоны разработки, проекты, которые неоднократно и естественно происходят. Если Вы будете взаимодействовать через интерфейс с ужасным API, Вы, вероятно, реализуете Facade очищать его. Если у Вас есть обмен сообщениями между компонентами, которые необходимо разъединить, можно использовать Observer. Если у Вас есть несколько взаимозаменяемых алгоритмов, Вы могли бы закончить тем, что использовали Strategy.
стоит знать шаблоны разработки, потому что Вы, более вероятно, будете распознавать их и затем сходиться на чистом решении более быстро. Однако, даже если Вы не будете знать их вообще, Вы закончите тем, что создали их в конечном счете (если Вы будете достойным программистом).
И конечно при использовании современного языка Вы будете, вероятно, вынуждены использовать их для некоторых вещей, потому что они испеклись в стандартные библиотеки.
Я пытаюсь использовать шаблоны, если они применимы. Я думаю, что это - вид печальных шаблонов разработки реализации разработчиков наблюдения в коде только ради него. Для правильной задачи, хотя, шаблоны разработки могут быть очень полезными и мощными.
Да, шаблоны разработки в основном используются в реальном мире - и ежедневно многими людьми я работаю с.
, По-моему, самое большое значение, обеспеченное шаблонами разработки, - то, что они предоставляют универсальный, высокоуровневый язык Вам, чтобы передать разработку программного обеспечения другим программистам.
, Например, вместо того, чтобы описать Ваш новый класс как "утилиту, которая создает один из нескольких других классов на основе некоторой комбинации входных критериев", можно просто сказать, что это "абстрактная фабрика" и все немедленно понимают то, о чем Вы говорите.
Я нахожу шаблон MVC действительно полезным для изоляции образцовой логики, которая может, чем быть снова использованной или продолжила работать без слишком большой проблемы. Это также помогает разъединению Ваших классов и делает поблочное тестирование легче. Я записал об этом недавно (да, бесстыдный разъем здесь...)
кроме того, я недавно использовал шаблон "фабрика" от базового класса, чтобы генерировать и возвратить надлежащий класс DataContext, в котором я нуждался на лету, с помощью LINQ.
Bridges используется при попытке при попытке склеить две различных технологии (как Какао и Ruby на Mac, например)
я нахожу, однако, что каждый раз, когда я реализую шаблон, это - потому что я знал об этом перед рукой. Некоторая дополнительная мысль обычно входит в него, поскольку я нахожу, что должен изменить исходный шаблон немного для размещения моих потребностей.
просто необходимо быть осторожными для не становления и астронавт архитектуры !
Да, Фабрика, Цепочка Ответственности, Команды, Прокси, Посетителя, и Наблюдателя, среди других, используются в кодовой базе, я работаю с ежедневной газетой. Насколько MVC идет, этот сайт, кажется, использует его вполне хорошо, и devs не мог сказать достаточно хороших вещей в последний подкаст .
По-моему, вопрос: "Вы использование шаблон разработки?", один немного испорчен, потому что ответ - универсально ДА.
Позволяют мне объяснить, мы, программисты и разработчики, все шаблоны разработки использования..., мы просто не всегда понимаем его. Я знаю, что это звучит как clichГ©, но Вы не переходите к шаблонам, шаблоны прибывают к Вам. Вы разрабатываете материал, он мог бы быть похожим на существующий шаблон, Вы называете его тем путем, таким образом, все понимают то, о чем Вы говорите, и объяснение позади Вашего проектного решения более сильно, зная, что он был обсужден реклама nauseum прежде.
я лично использую шаблоны в качестве коммуникационного инструмента.Вот именно. Они не конструктивные решения, они не лучшие практики, они не инструменты на панели инструментов.
не понимают меня превратно, если Вы будете новичком, книги по шаблонам покажут Вам, как решение лучше всего решено с помощью их шаблонов, а не другого дефектного дизайна. Вы, вероятно, извлечете уроки из осуществления. Однако необходимо понять, что это не означает, что для каждой ситуации нужен соответствующий шаблон для решения его. Каждая ситуация имеет причуду тут и там, которая потребует, чтобы Вы думали об альтернативах и приняли трудное решение без идеального ответа. Это дизайн.
Антишаблон однако находятся на полностью различном классе. Вы на самом деле хотите к [1 112] активно , избегают антишаблонов. Вот почему антишаблон имени так спорен.
Для возвращения к исходному вопросу:
"Я использую шаблоны разработки?", Да!
"Я активно склоняюсь к шаблонам разработки?", №
Существует много шаблонов разработки вне простых, которые используются в "реальном мире". Хороший пример Stackoverflow использует Образцовый Шаблон Контроллера Представления. Я использовал Фабрики классов многократно в проектах для моего работодателя, и я уже видел многих записанные проекты с помощью них также.
я не говорю, что каждый шаблон разработки используется, но многие.
Да мы делаем, это обычно происходит, когда мы начинаем разрабатывать что-то, и затем кто-то замечает, что это напоминает существующий шаблон. Мы тогда смотрим на него и видим, как это помогло бы нам достигнуть нашей цели.
Мы также используем шаблоны, которые не документируются, но которые появляются из разработки много.
Мышление Вы, мы не используем их много.
Я абсолютно использую шаблоны разработки. В этой точке я считаю MVC само собой разумеющимся как шаблон разработки. Моя основная причина использования их - то, что я достаточно скромен, чтобы знать, что я вероятен не первый человек, который встретится с конкретной проблемой. Я редко запускаю часть кода, знающего, какой шаблон я собираюсь использовать; я постоянно наблюдаю код, чтобы видеть, разрабатывает ли он естественно в существующий шаблон.
я также очень люблю Martin Fowler Шаблоны Архитектуры приложений для предприятия . Когда проблема или задача представляют себя, я зеркально отражаю к связанному разделу (это - главным образом справочник), и прочитайте несколько обзоров шаблонов. Как только у меня есть лучшая идея общей проблемы и существующих решений, я начинаю видеть, что длительный срок соединить мой код каналом, вероятно, возьмет через опыт других. Я заканчиваю тем принял намного лучшие решения.
Шаблоны разработки определенно играют большую роль во всем из мой "для будущих" идей.
MVC очень хорошо известен так да, мы используем шаблоны разработки довольно много. Теперь, если Ваше выяснение о Банде Четырех шаблонов, существуют несколько, что я использую, потому что другие специалисты по обслуживанию будут знать дизайн и чего мы работаем для в коде. Существуют несколько, хотя это остается довольно неясным для того, что мы делаем, поэтому если я использую тот, я не извлекаю полную пользу из использования шаблона.
они важный, да, потому что это дает Вам метод разговора о разработке программного обеспечения быстрым эффективным и общепринятым способом. Можно ли сделать лучшие настраиваемые решения, хорошо да (sorta)?
исходные шаблоны GoF вытянули от производственного кода, таким образом, они каталогизировали то, что уже использовалось в дикой природе. Они не просто или даже главным образом академическая вещь.
Да, я использую много известных шаблонов разработки, но я также заканчиваю тем, что создал некоторое программное обеспечение, которое я позже узнаю, использует 'именованный' шаблон разработки. Большинство изящных, допускающих повторное использование проектов можно было назвать 'шаблоном'. Это много похоже на танцевальные движения. Все мы знаем вальс и с 2 шагами, но не все имеет название 'удара и стремительного бега', хотя большинство из нас делает это.
Я пытаюсь, да. Они действительно помогают пригодности для обслуживания и удобочитаемости Вашего кода. Однако существуют люди, которые действительно оскорбляют их, обычно (от того, что я видел) путем принуждения системы в шаблон, который не существует.
На случай, если кому-то это понадобится, я немного усовершенствовал решение Джона, чтобы его можно было использовать непосредственно в качестве файла javascript.
// jquery_trigger_ready.js
// this function is added to jQuery, it allows access to the readylist
// it works for jQuery 1.3.2, it might break on future versions
$.getReadyList = function() {
if(this.readyList != null) { this.myreadylist = [].concat(this.readyList); }
return this.myreadylist;
};
$(document).ready(function() {
readylist = $.getReadyList();
});
$.triggerReady = function() {
$(readylist).each(function(){this();});
}
Включение этого файла после включения jquery позволяет запустить ready путем вызова $ .triggerReady () . Пример:
<html>
<head>
<title>trigger ready event</title>
<script src="test2_files/jquery-1.js" type="text/javascript"></script>
<script src="jquery_trigger_ready.js" type="text/javascript"></script>
</head>
<body>
<input onclick="$.triggerReady();" value="trigger ready" type="button">
<script type="text/javascript">
$(document).ready(function(){
alert("blah");
});
</script>
</body>
</html>
Кстати, я хотел сделать его $ (документ) .triggerReady () . Если кто-то готов поделиться советом по этому поводу, не стоит ценить.
Обычно существует два решения проблемы этого типа. Ни один из них не лучше другого ни при любых обстоятельствах, ни в этом конкретном примере. Оба решения вполне приемлемы.
Решение 1: используйте два контейнера (как правило, фреймы). Один для хранения горизонтальных предметов, другой для хранения вертикальных предметов. В этом случае корневое окно может служить контейнером для вертикально уложенных предметов. Поместите две кнопки в горизонтальную рамку (с помощью пакет (сторона = LEFT)), затем поместите эту рамку над текстовым виджетом (с помощью пакет (сторона = TOP)).
Решение 2: используйте диспетчер геометрии сетки, который размещает пользовательский интерфейс в сетке. Поместите кнопки в ячейки 0,1 и 0,2, а графический элемент текста в 1,1, охватывающий два столбца.
Как правило, для использования сети требуется несколько большее предварительное планирование. Необходимо выяснить, какие предметы должны охватывать столбцы или строки, какие столбцы или строки должны расти и сокращаться при изменении размера виджета и т.д. Решение пакета является «самым простым» (для некоторых определений «easy», в любом случае) для очень простых макетов, таких как этот.
Общая методика использования кадров для размещения групп виджетов является хорошей. Это упрощает управление полными наборами виджетов как группой. и смешивать и сопоставлять группы виджетов слева направо и группы виджетов сверху вниз.
Вот как я бы сделал это с помощью метода нескольких кадров. Обратите внимание, как я создаю виджеты как нижестоящие элементы корня, а не как нижестоящие элементы внутренних рамок. Это немного облегчает изменение макета в будущем, так как все, что вам нужно сделать, это создать или удалить различные кадры без необходимости изменять иерархию виджетов.
# create the main sections of the layout,
# and lay them out
top = Frame(root)
bottom = Frame(root)
top.pack(side=TOP)
bottom.pack(side=BOTTOM, fill=BOTH, expand=True)
# create the widgets for the top part of the GUI,
# and lay them out
b = Button(root, text="Enter", width=10, height=2, command=button1)
c = Button(root, text="Clear", width=10, height=2, command=clear)
b.pack(in_=top, side=LEFT)
c.pack(in_=top, side=LEFT)
# create the widgets for the bottom part of the GUI,
# and lay them out
text = Text(root, width=35, height=15)
scrollbar = Scrollbar(root)
scrollbar.config(command=text.yview)
text.config(yscrollcommand=scrollbar.set)
scrollbar.pack(in_=bottom, side=RIGHT, fill=Y)
text.pack(in_=bottom, side=LEFT, fill=BOTH, expand=True)
Ниже приведена наивная реализация с использованием сетки. Он имеет другое поведение изменения размера, которое может быть или не быть таким, каким вы хотите. Это действительно зависит от желаемого поведения изменения размера. Обычно я управляю рядом элементов управления с рамкой, а затем с помощью сетки раскладываю ее вместе с другими виджетами. В этом примере я просто использую сетку для всего.
Обратите внимание, что в дополнение к управлению строками и столбцами виджета необходимо определить весовой коэффициент для строк и столбцов. Как минимум, нужно выбрать одну строку и один столбец, чтобы «забрать слабину», что обычно означает, в каком столбце находится ваш основной виджет (читай: обычно текст, холст или другой кадр).
b = Button(root, text="Enter", width=10, height=2, command=button1)
c = Button(root, text="Clear", width=10, height=2, command=clear)
b.grid(row=0,column=0, sticky=W)
c.grid(row=0,column=1, sticky=W)
textframe = Frame(root)
textframe.grid(in_=root, row=1, column=0, columnspan=3, sticky=NSEW)
root.columnconfigure(0, weight=1)
root.rowconfigure(1, weight=1)
text = Text(root, width=35, height=15)
scrollbar = Scrollbar(root)
scrollbar.config(command=text.yview)
text.config(yscrollcommand=scrollbar.set)
scrollbar.pack(in_=textframe, side=RIGHT, fill=Y)
text.pack(in_=textframe, side=LEFT, fill=BOTH, expand=True)
В этом конкретном случае я бы выбрал первый метод, тот, который с пакетом. Для более сложных конструкций я почти всегда использую сочетание сетки и пакета. Используйте пакет для предметов, которые естественным образом укладываются горизонтально или вертикально (например, панели инструментов).Используйте сетку для более сложных макетов (например, для всего приложения, виджетов с полосами прокрутки, диалоговых окон и т.д.). Нельзя использовать и сетку, и упаковку для одного контейнера, но можно использовать пакет для одного контейнера, сетку для другого и т.д.
-121--4196069-Да. Узоры могут быть замечательными, когда используется соответствующим образом. Как вы уже упомянули, я сейчас использую Model-View-Controller (MVC) для всех своих веб-проектов. Это очень распространенный образец в Интернете космоса который делает серверный код намного более чистым и хорошо организованным.
Помимо этого, вот некоторые другие узоры, которые могут быть полезны:
MVVM (Model-View-ViewModel): шаблон, аналогичный MVC; используется для приложений WPF и Silverlight.
Композиция: Отлично, когда нужно использовать иерархию объектов.
Singleton: Более элегантный, чем использование глобалов для хранения предметов, которые действительно нуждаются в одном экземпляре. Как вы упомянули, простой образец, но он имеет свое применение.
Следует отметить, что дизайн, образец может также подчеркнуть отсутствие языковых особенностей и/или недостатков в языке. Например, итераторы теперь встроены как часть новых языков.
В общем дизайне узоры весьма полезны, но вы не должны использовать их везде; только там, где они хорошо подходят для ваших потребностей.
Да, паттерны проектирования или абстрактно паттерны являются частью моей жизни, куда бы я ни посмотрел, я начинаю их видеть. Поэтому я окружен ими. Но, как вы знаете, мало знаний - опасная вещь. Поэтому я настоятельно рекомендую вам прочитать книгу GoF.
Одна из главных проблем паттернов проектирования заключается в том, что большинство разработчиков просто не понимают идею или не верят в нее. И чаще всего они спорят о переменных, циклах или переключателях. Но я твердо убежден, что если вы не говорите на языке паттернов, ваше программное обеспечение не продвинется далеко, и вы окажетесь в кошмаре сопровождения".
Как вы знаете, анти-паттерн - тоже опасная вещь, и это происходит, когда у вас мало знаний о паттернах проектирования. А рефакторинг анти-паттернов намного сложнее. В качестве рекомендуемой книги по этой проблеме, пожалуйста, прочитайте "AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis".