Как перестать программировать на С++ в Паскаль стиле?

← →
Mystic © (2009-05-19 16:28) [160]

> А как быть если продукт может являться надможеством другого
> продукта?

Это как-то опровергает то, что я написал?

← →
Alkid © (2009-05-19 16:37) [161]

> oxffff © (19.05.09 15:41) [159]
> А шаблон Мост? :)

Шаблон Мост, по сути, является своеобразной формой делегации, для сокрытия конкретного типа реализации. В CLOS это реализуется "по умолчанию", поскольку там используется динамическая типизация + объекты могут менять свой класс в течении времени жизни.

← →
@!!ex © (2009-05-19 16:41) [162]

Типичный же сценарий непродуманной обобщённой разработки сводится к тому, что программисты без предварительного анализа долго делают "платформы" и "инфраструктуры", которые потом смогут "значительно упростить" разработку "будущих версий" (особо мечтательные программисты даже заявляют, что эту разработку "можно будет продавать как отдельный продукт"). В конечном итоге на получившемся монстрике пытаются сделать решение конкретной задачи и выясняется, что эту-то конкретную задачу на нём решать крайне неудобно, глючно и противно.
Я через такое проходил. Правда у меня это было только один раз.
Система получилось довольно клевая, и даже рабочая. Но для того чтобы она начала выигрывать перед специализированными системами на нее нужно потратить минимум год работы одного программиста. И она даже может продаваться как отдельный продукт... Вот только год на нее тратить у нас возможности нет, поэтому вполне рабочая и классная система лежит отдельно и вероятно в проекте мы от нее откажемся. А жаль.. получилось клево.

← →
Игорь Шевченко © (2009-05-19 16:54) [163]

@!!ex © (19.05.09 16:41) [162]

Во-во

← →
Alkid © (2009-05-19 17:04) [164]

> Игорь Шевченко © (19.05.09 16:54) [163]
> Во-во

А всё потому, что люди недооценивают трудность построения обобщённых решений.

← →
clickmaker © (2009-05-19 17:20) [165]

на одной из прошлых работ была задумка написать свою суперуниверсальную ERP. Классы, объекты, свойства, список доступа пользователей - все универсально и единообразно. Вплоть до того, что можно расширять список свойств объекта на лету, причем, без добавления полей в таблицы БД. Был даже встроенный недоязык: как бы конструктор операций из методов объектов с возможностью условных переходов и паскаль-подобный парсер выражений.
Задумка даже осуществилась.
Но работала очччень тормозно. Переборщили с сущностями и отношениями, и слишком запутали бизнес-логику.
Короче, система ушла в промышленную эксплуатацию частично. Причем, теми частями, которые менее ООП, а более приближены к эксель-подобным табличным системам.
Остальные части остались в основном как памятник универсальности, помноженной на нашу недальновидность -)

← →
oxffff © (2009-05-19 17:22) [166]

> Alkid © (19.05.09 16:37) [161]

У моста другое назначение. Трансформация одних вызовов в другие.
У объекта А есть метод B c сигнатурой S1.
Вызов B транслируется в вызов С с методом D c сигнатурой S2.

← →
Юрий Зотов © (2009-05-19 17:24) [167]

> @!!ex © (19.05.09 16:41) [162]

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

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

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

← →
Alkid © (2009-05-19 17:25) [168]

> oxffff © (19.05.09 17:22) [166]
> У моста другое назначение. Трансформация одних вызовов в
> другие.
> У объекта А есть метод B c сигнатурой S1.
> Вызов B транслируется в вызов С с методом D c сигнатурой
> S2.

А мы точно не об Адаптере говорим?

← →
Alkid © (2009-05-19 17:25) [169]

Дополню - о Stateless адаптере :)

> Alkid © (19.05.09 17:25) [168]
>
> > oxffff © (19.05.09 17:22) [166]
> > У моста другое назначение. Трансформация одних вызовов
> в
> > другие.
> > У объекта А есть метод B c сигнатурой S1.
> > Вызов B транслируется в вызов С с методом D c сигнатурой
>
> > S2.
>
> А мы точно не об Адаптере говорим?

У моста трансляция вызова агрегату может также транслироваться в вызов с другой сигнатурой.Например

OuterObject.DrawRect ->
{aggregate.DrawLine();
aggregate.DrawLine();
aggregate.DrawLine();
aggregate.DrawLine()
}

Пример взят из книги Design Patterns.

P.S. Я надеюсь, что теперь я заставлю изменить твое мнение на менее категоричное. :)
Хотя не могу не согласиться с тобой, что часть из них действительно направлена на языковые пробелы(хотя имеем ли мы право так их называть.)
Уже подмеченный тобой visitor(аля double dispatch multi method), ну и знаменитая фабрика классов.
Но не все.

> oxffff © (19.05.09 18:49) [171]
> P.S. Я надеюсь, что теперь я заставлю изменить твое мнение
> на менее категоричное. :)
> Хотя не могу не согласиться с тобой, что часть из них действительно
> направлена на языковые пробелы(хотя имеем ли мы право так
> их называть.)
> Уже подмеченный тобой visitor(аля double dispatch multi
> method), ну и знаменитая фабрика классов.
> Но не все.

На самом деле я действительно слишком резко выразился. То, о чем говорил я, относится к тем паттернам, в которых программисту приходится писать много однотипного инфраструктурного кода. Хороший пример - Visitor. Другой хороши пример - Command или Strategy. Вообще, основная критика паттернов сводится к двум вещам:
1. Они восполняют пробелы в языке.
2. Они ничего не привносят существенного к простому принципу абстрагирования, издревле широко применявшемуся в программировании. Наиболее конкретные паттерны (Visitor) подпадают под первый пункт, более абстрактные (Bridge, Letter-in-envelope) под вторую (спорность этих утверждений осознаю в полной мере :) ).

> Они ничего не привносят существенного к простому принципу
> абстрагирования

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

Как перестать программировать на С++ в Паскаль стиле? Найти похожие ветки