Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Общие вопросы по .NET и C# > Объектно-ориентированный анализ и проектирование


Автор: Medved 22.3.2007, 04:11
Знакомы ли в с объектно-ориентированным проектированием и UML? 
Используете ли вы паттерны в своих проектах?
Помогают ли они вам в ваших программах?

Спасибо.


Автор: Idsa 22.3.2007, 07:22
К сожалению, пока: 1. нет 2. нет.

Автор: ivashkanet 22.3.2007, 11:39
Знаком. 
Если нахожу место применения -- очен радуюсь и применяю smile
По большому счету да.

А вообще, ИМХО, у меня очень мало опыта и я не особо видел хорошо спроектированных проектов. Мой текущий вообще "обошелся" без стадии проектирования, вот теперь я и страдаю.
Единственный паттерн с которым я на ты --- это одиночка, singleton

Автор: HalkaR 22.3.2007, 12:00
Цитата(ivashkanet @  22.3.2007,  11:39 Найти цитируемый пост)
Единственный паттерн с которым я на ты --- это одиночка, singleton
Аналогично. Иногда использую фабрики. Щас как раз читаю про то как находить места применения паттернов.

Автор: Medved 22.3.2007, 13:27
Спасибо за ответы!

Автор: nikitao 22.3.2007, 15:47
Я вот прямо сейчас изучаю их smile  Так что пока затрудняюсь на вышепоставленный вопрос ответить smile 

Автор: FreeWanderer 22.3.2007, 20:19
Паттерны вещь бесспорно полезная, я бы сказал незаменимая, особенно в это ощущается в крупных проектах с огромным количеством исходного кода и постоянно меняющимися (дорабатывающимися) требованиями заказчика.
Пользуюсь постоянно, чего и Вам желаю.

Автор: Exception 29.3.2007, 19:35
Использую, так сказать, по мере умения.

Автор: mr.DUDA 30.3.2007, 09:06
Безграмотно спроектированный проект - это ужос для заказчика (потом его развивать, дополнять и поддерживать). Способ проектирования от mr.DUDA -- тщательно продумать каждую мелочь, а потом забить на это и сделать всё как можно проще.  smile 

Автор: Medved 5.4.2007, 02:52
Цитата(mr.DUDA @  30.3.2007,  12:06 Найти цитируемый пост)
Способ проектирования от mr.DUDA -- тщательно продумать каждую мелочь, а потом забить на это и сделать всё как можно проще.

О, даже мистер Дуда не обходиться без предварительного проектирования smile

Автор: mr.DUDA 5.4.2007, 09:54


Приходится.

Хотя никакими визуальными тулзами не пользуюсь принципиально, всё - в голове.  smile 


Автор: Medved 5.4.2007, 18:44
Цитата(mr.DUDA @  5.4.2007,  12:54 Найти цитируемый пост)
Хотя никакими визуальными тулзами не пользуюсь принципиально

Видимо еще не случалось таких обстоятельств, где они были бы востребованы.

Автор: mr.DUDA 6.4.2007, 09:18
Цитата(Medved @ 5.4.2007,  17:44)
Цитата(mr.DUDA @  5.4.2007,  12:54 Найти цитируемый пост)
Хотя никакими визуальными тулзами не пользуюсь принципиально

Видимо еще не случалось таких обстоятельств, где они были бы востребованы.

Для себя представляю только такую ситуацию: когда проектированием занимается один человек, а разработкой - другие, тогда  востребованы визуальные средства -- Visio, Rose, и т.п.

Автор: iddqd 18.4.2007, 15:41
Слышал, но толком не знаю. Очень хотелось бы про паттерны почитать, если кто-нибудь знает ссылку с кратко изложенной и при этом легко понятной информацией, то буду очень признателен. А про UML книгу на озоне на работе заказали, скоро будет.

Автор: Medved 18.4.2007, 19:23
Цитата(mr.DUDA @  6.4.2007,  12:18 Найти цитируемый пост)
Для себя представляю только такую ситуацию: когда проектированием занимается один человек, а разработкой - другие, тогда  востребованы визуальные средства -- Visio, Rose, и т.п. 


Крупный и серьезный проект ты не напишешь, если не будешь следовать методике. 

Потому в них и появилась потребность, что сложность разработки постоянно росла.

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

Автор: 0000 20.4.2007, 14:09
изучаю и не перестаю удивляться эффективности использования шаблонов.стараюсь использовать как можно больше, вот только найти в каждой ситуации правильный шаблон и грамотно его реализовать получается пока не всегда - учусь =)

Автор: Mag 2.7.2007, 23:12
ООП пользуюсь постоянно. На паттерны постепенно перехожу, так как это полезная штука в больших проектах.

Автор: Azzdorf 7.7.2007, 21:29
UML - рулит. UML может и забирать дополнительно времени на этапах формирования требований и проектирования, но существенно экономит Ваше время на доработку на этапах реализации, тестирования и внедрения.

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

Потома я себе купил книженцию по UML, на рынке их немеряно - изданий и переизданий от создателей UML (БУЧа, РАМБО и ЯКОБСОНа). Сначала каша - так как днем решаеш одну проблему, а вечерами - почитуеш книгу,  не просто книгу...
... как на как отдельный язык, правда моделирования, но как говорили создатели "С" - Б.Керниган и Д.Ричи - "единственный способ изучить язык программирования - это писать на нем програми"....

Реализовал еще два проекта, для начала помучился пока семантику и синтаксис выучил, но главное научиться использовать два больших приемущества UML - создавать пользовательские части конструкций через использование стереотипов и возможность посметреть на каждый процес с разных точок зрения (особенно кагда нужно доказать юзеру что сюда неичего недобавиш, потому как с самого  начало задумывалось по другому smile ).

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

Дерзайте UML  - это вещь smile 

Автор: LostAlly 11.7.2007, 19:49
Я сам не использую UML. Было бы интересно начать.
Может кто подскажет есть ли бесплатное программное обеспечение для UML проектирования?

Автор: Medved 11.7.2007, 23:31
Цитата(LostAlly @  11.7.2007,  22:49 Найти цитируемый пост)
Может кто подскажет есть ли бесплатное программное обеспечение для UML проектирования? 


Можешь осуществить поиск по разделу http://forum.vingrad.ru/forum/tech-system-analyse-analysis-designing-projection-uml-unified-modeling.html или задать этот же вопрос в разделе http://forum.vingrad.ru/forum/software.html.

Автор: ivashkanet 12.7.2007, 09:14
LostAlly, лови неплохой бесплатный, на .Net писанный UML редактор: http://staruml.sourceforge.net/en/

Автор: Dimass 12.7.2007, 10:57
Кстати хотелось бы проголосовать за паттерны. Недавно стал знакомиться с этим методом ООП, достаточно неплохо развивает...  smile 

По этому поводу добавлю хороший источник  ->  Э.Гамма, Э.Хелм и др.  Приемы объектно-ориентированного проектирования паттерны проектирования.

Автор: deviLoper 31.8.2007, 15:10
Недавно прочитал книгу "Экстремальное программирование" Кент Бек, которая очень понравилась. Помаленку пытаюсь использовать описанные там приципы. Интересно было бы услышать мнение тех, кто использовал UML, паттерны и XP. Что-то вроде сравнительного анализа.
Заранее спасибо.

Автор: 0000 31.8.2007, 15:39
deviLoper, а дай ссылочку на книжку

Автор: deviLoper 31.8.2007, 18:38
http://dl.kruzzz.com/files/1225/programm/etc/extr_prog.pdf

Автор: 15892 31.10.2007, 19:40
Сложный проект без объектного подхода написать сложно....  smile  и с объектным тоже  smile 
Хотя если ума очень много, то можно... Главное потом туда не заглядывать и не модифицировать... а если потребуется, то беда... 

А вот на проектах небольших едва ли стоит сильно заморачиваться на проектировании... Бери и пиши... 

Автор: 0000 2.11.2007, 11:07
15892, не модифицировать?? я таких проектов не встречал ни разу!

Автор: Azzdorf 11.12.2007, 13:23
Цитата(0000 @ 2.11.2007,  11:07)
15892, не модифицировать?? я таких проектов не встречал ни разу!

аналогично - даже самый мегаконечный продукт через определенное время - выпадает из времени (блин кругом тафталогия) - любой проект дорабатываеться, перерабатывается или просто уходит в никуда, но что чаще бывает кода продукт реально качественный то модифичировать приходиться через достаточно долгий промежуток времени кога уже всё забыл ВОТ ТОГДА и думаеш про проектирование, тем более, как часто бывает, набрался опыта: хочеш, видеш и приступаеш к оптимизации smile 

Автор: CYBERDREAM 11.12.2007, 13:46
скоро благодаря мелкомягким будем делать мега проекты нескольками кликами с объемом по несколько гигов smile 

Автор: Medved 12.12.2007, 16:11
Цитата(CYBERDREAM @  11.12.2007,  16:46 Найти цитируемый пост)
скоро благодаря мелкомягким будем делать мега проекты нескольками кликами с объемом по несколько гигов smile 

Содержание поста не соответствует смыслу топика.

Автор: izekia 12.12.2007, 16:18
мне понравилось одно высказывание, точно не помню чье:
что-то вроде того что сначала когда вы начинаете знакомится с паттернами вам все это нравится,
потом начинаете пытаться применять, потом понимаете, что они полностью бесполезны и бросаете эту затею, и в конце концов ловите себя на том, что все-таки используете их

Автор: Exception 14.2.2008, 22:53
izekia, если точнее, это сказал Грег Ирвин, и звучало оно так:

Цитата

"For me, many concepts, like patterns, are learned in stages:

   1. You use it without being aware that you're using it
   2. You hear about it, read up on it, and tinker a bit
   3. You learn more and start using it explicitly, if naïvely
   4. You get the fire and evangelize (optional)
   5. Something "clicks"
   6. You learn more and apply it "less naïvely" and more implicitly
   7. Time passes and you see flaws
   8. You question the concept (often because you misapplied it)
   9. You either forget about it or add knowledge and experience

      (Repeat steps 5–9 as necessary)

  10. You use it without being aware that you're using it" 


smile

А вообще, я сейчас стараюсь совмещать небольшое проектирование на основе модели предметной области, TDD и рефакторинг -- очень нравится, гораздо эффективнее всё получается.

Автор: Medved 15.2.2008, 12:36
Цитата(Dimass @  12.7.2007,  13:57 Найти цитируемый пост)
По этому поводу добавлю хороший источник  ->  Э.Гамма, Э.Хелм и др.  Приемы объектно-ориентированного проектирования паттерны проектирования. 


Это классика. К прочтению обязательна.

Автор: Gelis 5.4.2008, 17:33
Цитата(Exception @  14.2.2008,  22:53 Найти цитируемый пост)
TDD и рефакторинг -- очень нравится

А еще, если к этому прикрутить Design Patterns вообще вещь получается.
Рекомендую по этому поводу книженцию Джошуа Кириевски "Рефакторинг с использованием шаблонов".

Автор: firstone 10.4.2008, 16:11
UML Применяю всегда. Design Patterns всегда. А если мой работодатель хочет Fast & Dirty то пусть ищет другого программиста.

Автор: Real 10.4.2008, 19:45
ООП из книге "Для профессионалов .NET 3.0" - http://depositfiles.com/files/4594993

Автор: ivashkanet 11.4.2008, 08:43
Цитата(Exception @  14.2.2008,  22:53 Найти цитируемый пост)
   7. Time passes and you see flaws
   8. You question the concept (often because you misapplied it)
   9. You either forget about it or add knowledge and experience

Я сейчас нахожусь в этой стадии smile Оставил только самые простые паттерны.
И больше обращаю внимание на бестпрактики, чем на паттерны.
Цитата(Exception @  14.2.2008,  22:53 Найти цитируемый пост)
небольшое проектирование на основе модели предметной области

Для нашего уровня проектоектов это наиболее полезный "паттерн". 
От знание же многих других бывает только хуже (знаю парня, который паттерн команда применял чуть ли ни в любом вызове мотода. Например вместо того чтобы добавить новый метод к DAO он реализовал паттерн команда и использовал ее для достижения этой цели).


Автор: ivashkanet 11.4.2008, 09:15
Цитата(Medved @  15.2.2008,  12:36 Найти цитируемый пост)
Цитата(Dimass @  12.7.2007,  13:57 Найти цитируемый пост)
По этому поводу добавлю хороший источник  ->  Э.Гамма, Э.Хелм и др.  Приемы объектно-ориентированного проектирования паттерны проектирования. 


Это классика. К прочтению обязательна.

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

К таким могу отнести:
Мост (Bridge) про этот паттерн до сих пор спорят архитекторы и не могут приди к единому мнению -- в сад!
Строитель (Builder) сам не использовал -- не сталкивался с объектами требующими сложного конструирования.
]Комманда -- в большинстве случаев приводит к усложнению кода
Но в случаях когда она действительна нужна она незаменима, только вот трудновато новичку их определить. Я благодарин моему другу, что он отговорил меня его использовать в моем проекте (а было ох какое желание и тогда я думал, что он очень грамотно ложиться на задачу).
Цепочка обязанностей (Chain of Responsibility) -- см. команда, только попроще распознать нужен ли он тебе.
... 
Дописал до сих пор и понял, что все эти паттерны (кроме Моста, этот вообще жесть -- запутаться в нем раз плюнуть) при использовании не к месту всегда приводят к усложнению кода. Т.о. самая главная задача определить -- а оно тебе надо? Поэтому начинающему архитектору лучше о них не знать smile

Продолжу перечисление:
Компоновщик (Composite), Интерпретатор (пример сложного паттерна, но его врятли начинающий рискнет использовать), Медиатор (лучше сразу MVC, MVP...), Посетитель (Visitor).

В противовес, паттерны которые должен знать каждый! разработчик:
Адаптер, Фасад, Итератор (хотя и встроен в современные языки, многи не понимают что это и зачем), Хранитель (Memento), Наблюдатель (Observer) (грамотно реализован в .Net с поможью событий), Синглтон, Состояние (State), 

Более сложные (знать не обязательно, но желательно): 
Фабричный метод, Декоратор, Прокси (Proxy)


Вот такое мое ИХМО.

Автор: ivashkanet 11.4.2008, 09:56
Еще раз подчеркну:
Цитата(ivashkanet @  11.4.2008,  08:43 Найти цитируемый пост)
Цитата(Exception @  14.2.2008,  22:53 Найти цитируемый пост)
небольшое проектирование на основе модели предметной области

Для нашего уровня проектоектов это наиболее полезный "паттерн".  


Автор: firstone 13.4.2008, 12:18
Билдер можно использовать тогда, когда нужно построить объекты одного класса, но с разными значениями свойств. Например, если есть класс пакетов протокола, в которых все поля одинаковы, но имеют разные значения в зависимости от задач пакета, то наследование здесь будет лишне. С другой стороны, если полей такиx много, то стоит взвесить целесообразность билдера. Т.е. вместо:

Код

public class APDU // Application Protocol Data Unit
{
private byte field1Value;
private byte field2Value;
private byte field3Value;
private byte field4Value;
private byte field5Value;
...

public byte field1{get { return this.field1Value; } set { this.field1Value = value; }}
public byte field1{get { return this.field2Value; } set { this.field2Value = value; }}
public byte field1{get { return this.field3Value; } set { this.field3Value = value; }}
public byte field1{get { return this.field4Value; } set { this.field4Value = value; }}
public byte field1{get { return this.field5Value; } set { this.field5Value = value; }}
...

}

public class APDUDirector
{
public static manage()
{

APDU getInfoAPDU = new APDU();
getInfoAPDU.field1 = 0x01;
getInfoAPDU.field2 = 0x02;
getInfoAPDU.field3 = 0x03;
getInfoAPDU.field4 = 0x04;
getInfoAPDU.field5 = 0x05;
...

SerialPort port = new SerialPort("COM1");
port.write(getInfoAPDU);

APDU installAppAPDU = new APDU();
installAppAPDU.field1 = 0x0A;
installAppAPDU.field2 = 0x0B;
installAppAPDU.field3 = 0x0C;
installAppAPDU.field4 = 0x0D;
installAppAPDU.field5 = 0x0E;
...

port.write(installAppAPDU);
}
}


Код

public abstract class APDUBuilder
{
protected APDU builtAPDU = null;

public abstract void build();

public APDU getConstructedAPDU()
{
return builtAPDU;
}

// Some common routines
...
}

public class GetInfoAPDUBuilder : APDUBuilder
{
public override void build()
{
this.builtAPDU = new APDU();

this.builtAPDU.field1 = 0x01;
this.builtAPDU.field2 = 0x02;
this.builtAPDU.field3 = 0x03;
this.builtAPDU.field4 = 0x04;
this.builtAPDU.field5 = 0x05;
}
}

public class InstallAppAPDUBuilder : APDUBuilder
{
public override void build()
{
this.builtAPDU = new APDU();

this.builtAPDU.field1 = 0x0A;
this.builtAPDU.field2 = 0x0B;
this.builtAPDU.field3 = 0x0C;
this.builtAPDU.field4 = 0x0D;
this.builtAPDU.field5 = 0x0E;
}
}

public class APDUDirector
{
public static manage()
{

SerialPort port = new SerialPort("COM1");

APDUBuilder builder = new GetInfoAPDUBuilder();
builder.build();
APDU getInfoAPDU = builder.getConstructedAPDU();

port.write(getInfoAPDU);

builder = new InstallAppAPDUBuilder();
builder.build();
APDU installAppAPDU = builder.getConstructedAPDU();

port.write(installAppAPDU);
}
}

Автор: firstone 13.4.2008, 12:54
Цитата(ivashkanet @  11.4.2008,  09:15 Найти цитируемый пост)
Комманда -- в большинстве случаев приводит к усложнению кода

У меня как раз Command всегда все упрощал. Это хороший способ инкапсулировать все, что относится к одному действию. Кроме того, этот паттерн позволяет строить иерархию комманд (Composite) или под-команды (когда одно действие состоит из нескольких более простых действий).

Добавлено через 2 минуты и 34 секунды
Цитата(ivashkanet @  11.4.2008,  09:15 Найти цитируемый пост)
(Composite)

По-сути любая иерархичная структура реализует этот паттерн.
Цитата(ivashkanet @  11.4.2008,  09:15 Найти цитируемый пост)
Посетитель (Visitor).

Хороший пример использования - обход дерева файлов проекта при компиляции.

Добавлено через 6 минут и 37 секунд
Цитата(firstone @  13.4.2008,  12:54 Найти цитируемый пост)
По-сути любая иерархичная структура реализует этот паттерн.

Извините, этo я погорячился.

Автор: ivashkanet 13.4.2008, 15:01
Цитата(firstone @  13.4.2008,  12:54 Найти цитируемый пост)
У меня как раз Command всегда все упрощал.

firstone, Перечитай мой пост. Все паттерны упрощают разработку, если используются к месту. А использование их не к месту все только усложныет. 
И очень часто тяжело понять нужен он или нет, вот про это я и говорл.
Цитата(firstone @  13.4.2008,  12:54 Найти цитируемый пост)
Хороший пример использования - обход дерева файлов проекта при компиляции.

И ты считаешь это не сложный пример?

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

Автор: firstone 13.4.2008, 15:28
ivashkanet, Во всем согласен. Простo я не в том ключе прочитал Ваш пост.

Добавлю  свое ИМХО по аналогии Вашего.

Должны знать: Factory, Factory method, Decorator, Adapter, Facade, Iterator, Proxy, Command, Memento, Observer, Composite, Mediator(?)

Необязательно: Chain of responsibility, Bridge, Builder, Visitor, (Mediator)


Собственно, Mediator - слишком пространственный паттерн. Наверняка его применяли все, простo не давали себе в этом отчет.

Автор: ivashkanet 14.4.2008, 09:20
Цитата(firstone @  13.4.2008,  12:18 Найти цитируемый пост)
Билдер можно использовать тогда, когда нужно построить объекты одного класса, но с разными значениями свойств

А вот и не правда smile Для этого случая больше подходит прототип (один из обязательных паттернов).

А билдер нужен тогда, когда нужно создать один объект, но создавать его можно из разных источников.

В ГоФ-е дают пример про RTF документ, который билдиться из разных источников: обычного текста, TeX-файла, ...

Добавлено через 13 минут и 32 секунды
И еще, немного пересмотрел свой список ( smile ) исключив из него сложные паттерны, но которые тяжело использовать не там где надо smile
Это например Компоновщик (Composite). О нем хорошо бы просто знать.
Потому что для работы с графикой (нарисовать три линии, квадратик, а внурти треугольник smile ) он нужен просто как воздух.

Автор: firstone 14.4.2008, 10:05
Цитата(ivashkanet @  14.4.2008,  09:20 Найти цитируемый пост)
А вот и не правда smile Для этого случая больше подходит прототип (один из обязательных паттернов).

А билдер нужен тогда, когда нужно создать один объект, но создавать его можно из разных источников.

Все же позвольте мне с Вами не согласиться.

В моем примере prototype и builder одинаково применимы. Я считаю, что билдер подходит больше из-за полного отсутствия разницы между классами. Потом некоторый customizing объектов все же необходим, так что после Clone()-а все равно надо будет менять какие-то свойстава. Хотя в обшем и прототип тут тоже сойдет и фактори. 

Автор: ivashkanet 14.4.2008, 10:25
firstone, пусть будет так ;-) 
Вся прелесть в том, что в архитектуре нет жестких рашений, каждое можно и нужно адаптировать, менять, использовать там где ты считаешь удобнее.

Автор: firstone 14.4.2008, 11:25
Цитата(ivashkanet @  14.4.2008,  10:25 Найти цитируемый пост)
Вся прелесть в том, что в архитектуре нет жестких рашений, каждое можно и нужно адаптировать, менять, использовать там где ты считаешь удобнее. 

Согласен. Правда бывает, увлечешься этими паттернами, что и забудешь что вообще ты пытаешься ими решить smile

Автор: ivashkanet 14.4.2008, 15:45
Читаю http://forum.vingrad.ru/forum/topic-206294/kw-software-architect.html  и нарвался на такую фразу:
Цитата
Суть в том, что часто паттерны используются чересчур активно. Известна история о программисте, который, прочитав в первый раз книгу Банды Четырех (издана на русском языке в издательстве "Питер" под названием "Паттерны проектирования" - прим. переводчиков), ухитрился использовать 16 паттернов в 32 строчках кода. Помню замечательный вечер, подогретый всего-навсего одним стаканчиком солода, когда мы с Кентом набрасывали статью под названием "Не паттерны проектирования: 23 дешевых трюка", где рассказали о таких вещах, как использование оператора "if" вместо паттерна "стратегия". В каждой шутке есть доля правды. Паттерны нередко используются там, где без них вполне можно было бы обойтись, однако это не делает хуже саму идею. Весь вопрос в том, как вы их используете.

Автор: Medved 14.4.2008, 16:13
http://ru.wikipedia.org/wiki/%D0%90%D0%BD%D1%82%D0%B8-%D0%BF%D0%B0%D1%82%D1%82%D0%B5%D1%80%D0%BD

Автор: ivashkanet 15.4.2008, 09:30
Хорошая статья: http://www.rsdn.ru/article/patterns/gotopatterns.xml

Автор: AdrenalinHunter 6.8.2008, 11:12
Есть ли у кого рабочий пример паттерена МVC под WinForms?

При реализации MVC в WinForms есть определённые сложности. В .NET отсутствует чёткое разделение между Представлением и Контроллером. По сему приходиться реализовывать дополнительные паттерны - Mediator или Observer. (поправте меня если я ошибаюсь). По-этому хотелось бы узнать мнение о реализации данного паттерна smile 

Для общего ознакомления:
http://www.rsdn.ru/article/patterns/ModelViewPresenter.xml
http://www.rsdn.ru/article/patterns/generic-mvc.xml 

Автор: Neox_GeForce 5.7.2009, 12:03
http://www.rsdn.ru/article/patterns/ModelViewPresenter.xml
В етой статье код не рабочий. В интерфесе обьявлены методы а в класе автор реализует свойства.

Автор: ivashkanet 6.7.2009, 11:57
AdrenalinHunter, 
1) MVC -- это не один какой-то паттерн, а целое семейство паттернов. Какой из них тебя интеерсует?
2) Четкое разделение между представлением и контроллером либо присутствует, либо нет. И это совершенно безотносительно к .Net 
3) Код формы в WinForms -- чистый паттерн Mediator.
4) Обсервер -- встроен в C# (механизм событий)
5) Форма (контролы + медиатор) -- это V (View) из MVC 

Автор: Medved 6.7.2009, 21:19
Если интересует, как правильно применять паттерны в своих проектах, то есть замечательная библиотека от МS - http://msdn.microsoft.com/en-us/library/aa480482.aspx

Вот описание на русском http://www.compress.ru/article.aspx?id=17281&iid=799

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

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

Автор: Gluttton 6.10.2009, 11:50
Medved, а есть аналоги или бесплатные варианты для Express версий? Может приходилось сталкиваться?

Автор: mozgabyte 10.10.2009, 21:28
Доброго времени суток! Уважаемые, нужен совет бывалого программиста smile

Наверное вопрос не в тему,- сорри((

В общем, я хочу попытаться освоить C#, но есть некоторые нюансы и вопросы. Итак..
 1) С чего лучше всего начать? (Легко усваиваемая литература (для новичка), каким образом организовывать практикум (построение алгоритмов-> консольные приложения->..)) В общем все для полного нуба
 2) Сложно ли освоить С# без знания C/C++, и имея знания и практику по программированию и алгоритмизации на 3 с минусом Может рано я берусь за это..
 3) Какую среду разработки использовать для начала (сейчас осваиваю MSVC# 2008 EE)? Возможно для начала нужно что-то попроще?
 4) Какое Ваше мнение об C# и .NET платформе в общем? Перспективность, сложность изучения и т.д.?
 5) Кроссплатформенность, универсальность и т.п.
 6) Достоинства и недостатки данного языка и платформы в целом?
 7) Можно ли создавать на C# приложения работающие без .Net Framework'а?


Спасибо за внимания и ответы smile Буду рад любым комментариям 

P.S. Извиняюсь, если вопросы задаю непонятно/некорректно..

Автор: Medved 10.10.2009, 22:09
Цитата(Gluttton @  6.10.2009,  14:50 Найти цитируемый пост)
Medved, а есть аналоги или бесплатные варианты для Express версий?

?

Цитата(mozgabyte @  11.10.2009,  00:28 Найти цитируемый пост)
 1) С чего лучше всего начать? (Легко усваиваемая литература (для новичка), каким образом организовывать практикум (построение алгоритмов-> консольные приложения->..)) В общем все для полного нуба
 2) Сложно ли освоить С# без знания C/C++, и имея знания и практику по программированию и алгоритмизации на 3 с минусом Может рано я берусь за это..
 3) Какую среду разработки использовать для начала (сейчас осваиваю MSVC# 2008 EE)? Возможно для начала нужно что-то попроще?
 4) Какое Ваше мнение об C# и .NET платформе в общем? Перспективность, сложность изучения и т.д.?
 5) Кроссплатформенность, универсальность и т.п.
 6) Достоинства и недостатки данного языка и платформы в целом?
 7) Можно ли создавать на C# приложения работающие без .Net Framework'а?

1. Поставь перед собой задачу, конкретную задачу - написать например какое-нибдуь полноценное приложение. Не важно какое, плеер, текстовый редактор, личная БД, все что угодно, и уделяй этому время. Вот и все. Никаих секретов тут нет. Можно взять какое-нибудь учебное пособие, где идет обучение языку на примере построенния какого-нибудь учебного приложения. Это будет лучше всего.
Что-то конкретное из литературы посоветывать не могу, так как не слежу за книгами по этой тематике. Мне достаточно MSDN.
2. Для изучения С# знать С/С++ не обязательно. Это совершенно разные языки программирования. Хотя в чем-то синтаксис и похож. 
3. Ну раз уж ты пишешь в этом форуме, то рекомендую http://www.microsoft.com/downloads/details.aspx?displaylang=ru&FamilyID=83c3a1ec-ed72-4a79-8961-25635db0192b http://www.microsoft.com/downloads/details.aspx?familyid=27673C47-B3B5-4C67-BD99-84E525B5CE61&displaylang=ru.
4. Переспективная технология. Сложность - понятие относительне. Решил изучать эту платформу - изучай, не проградаешь. ИМХО.
5. Кросплатформенность официально отсутствует. Есть возможность запускать на Linux через неофициальный проект http://ru.wikipedia.org/wiki/Mono. В данном случае прямой конкурент .NET - Java более предпочтительнее.
6. http://blog.nguen.net/post33-good_bad_plus_minus_dot_net.html
7. Нет, без  Framework'а приложение работать не будет. Но это и не столь важно, практически у каждого пользователя уже присутствует этот пакет.

Автор: mozgabyte 11.10.2009, 01:05
Medved, спасибо за ответы smile 

Автор: Nikituki 16.10.2009, 14:41
Изучению UML у меня в инсте целый семестр отводится. Очень интересная штука, если разобраться=)

Автор: PashaPash 30.10.2009, 14:46
Хвост топика выделен в http://forum.vingrad.ru/forum/topic-278393.html

Автор: Stolzen 26.5.2010, 23:41
Иногда использую. 

Вообще, нас в вузе не так давно научили Rational Rose, но я сразу же ощутил всю прелесть - когда зараннее разрабатываешь класс на бумажке (ну там - в проекте), а потом генерируешь код. Так намного удобнее, можно сразу продумать логику взаимосвязи классов, как они между собой взаимодействуют. Особенно полезно, когда классов очень много - просто куче кода, без визуализации, очень легко запутаться. 

Поэтому еще иногда полезно использовать обрантый инженеринг - когда из кучи классов программка рисует красивую схемку. Кто программирует на Java в среде NetBeans, могут знать, что к среде есть достаточно неплохой модуль поддержки UML. Я им пользуюсь, полезная штука. http://netbeans.org/features/uml/

Автор: Wilko 27.5.2011, 01:09
Использование методологий объектного моделирования и графического описания != использование паттернов.
Знаю основы, использовал пару раз за 5 лет самообучения, т.к. считаю что паттерны должны использоваться только если программист на 100% понимает что он делает, а для этого, по большому счету, до всех паттернов нужно дойти самому.
То что паттерн можно применить не значит, что он должен быть применен.

"Есть мнение, что слепое применение шаблонов из справочника, без осмысления причин и предпосылок выделения каждого отдельного шаблона, замедляет профессиональный рост программиста, так как подменяет творческую работу механической подстановкой шаблонов. Люди, придерживающиеся данного мнения, считают, что знакомиться со списками шаблонов необходимо тогда, когда программист «дорос» до них в профессиональном плане — и не раньше. Хороший критерий нужной степени профессионализма — выделение шаблонов самостоятельно, на основании собственного опыта. При этом, разумеется, знакомство с теорией, связанной с шаблонами, полезно на любом уровне профессионализма и направляет развитие программиста в правильную сторону. Сомнению подвергается только использование шаблонов «по справочнику»." ©Wikipedia.org

Автор: YankovskyAndrey 27.8.2011, 03:49
Что там учить в Uml? Достаточно беглого прочтения информации с википедии по любому типу диаграмм.
Считаю реально полезной и ходовой диаграмму классов, остальные только по праздникам(хотя Use-case человечки и доставляют)
Все тулзы по рисованию Uml, с которыми я работал, откровенно кривые(и я в поиске до сих пор). По времени на рисование соизмеримо с работой в пейнте.
Старая добрая бумага куда лучше.

Автор: jsharp36 8.10.2011, 23:39
Я диаграммы использую, но наоборот. Т.е. стараюсь динамично с использованием TDD разрабатывать. Скорость разработки в разы выше, чем у колег, которые вроде и опытные, а не пользуются такими вещами. Я противник предварительного создания архитектуры. Приходят требования, архитектура сама рождается. Когда набъете руку, то всего лишь пара интуитивных правил помогает создавать архитектуру на ходу. Я бы назвал эти правила:
1. Нахождение общего. Вынос в базовый класс. Или вынос в отдельный метод
2. Нахождение различий. Вынос в потомков.
3. Избегать любым способом дублирование данных. Для этого минимизировать как только возможно состояние объектов. Желательно, чтобы они вообще почти не имели состояния, а всё перевычислялось. Избегаем сайд-эффектов. Приближаемся к функциональному программированию. Если же потом не устраивает производительность, то просто в такую архитектуру добавляется кеширование.

Почти как в базе данных, сущности лежат в таблицах строго по правилам нормализованными. Так и классы в шарпе. Нечего там мудрить. Паттерны использую. Но активно использую - синглтон и фабрика, фабричный метод. Иногда стратегия выручает. Остальные паттерны довольно частные. И подойдут только для некоторых задач. Нужно смотреть на балланс - не слишком ли вычурным получается решение, четко ли паттерн передает смысл задачи? Иногда и ифы полезнее писать, чем пользоваться виртуальными методами.

На счет сложности проектов и предварительной архитектуры. Что-то не было на моей памяти мегасложных проектов на шарпе. Все архитектурные решения для бизнес-проектов - уже настолько давно всем известны, что набили оскомину. Поэтому каркас просто берется готовый, а далее TDD. Юнит-тестирование и рефакторинг - рулят. При этом UML и диаграммы не рисую, потому как считаю потерянным временем. Нарисовать диаграмму - это почти уже задать логику. Тогда зачем два раза это делать? Потом, если диаграммы рисуются до начала кодирования, сто процентов, будут еще куча изменений в требованиях и куча всего, что "не учли". Опять перерисовывать. А не дай бог еще кто-то увидит эту диаграмму. Тогда перерисовка ее сразу же обязывает согласовывать с другими, кто уже видел и запомнил, как оно собиралось быть внедрено.
Короче - куча лишних бессмысленных телодвижений. Когда как с опытом понимаешь, что для любой задачи уже есть архитектура и нормальная архитектура только одна. Нечего здесь креативить. Креативят новички.

Но диаграммы все таки рисую, но в конце. Т.е. когда уже сформировался проект и уже есть решение, нужно в конце документировать. Чтобы была документация и можно было передавать другим людям код.

Автор: qpile 13.7.2012, 07:11
Подскажите, пожалуйста, хорошую книгу по Паттернам проектирования. В программировании уже 3 года. Хотелось бы развиться дальше

Автор: k0rvin 13.7.2012, 11:10
http://www.ozon.ru/context/detail/id/2457392/ может.

Автор: qpile 13.7.2012, 18:24
Книгу  94 года? Нет, спасибо

Автор: Stolzen 13.7.2012, 18:52
Цитата(qpile @  13.7.2012,  19:24 Найти цитируемый пост)
Книгу  94 года? Нет, спасибо 

А что не так? Принципы, лежащие в основе паттернов, с тех пор не изменились.
 Вообще, для изучения я бы рекомендовал эту http://www.ozon.ru/context/detail/id/6108824/ Но в ней точно такие же паттерны, как и в GOF. 

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)