[ANN] Руководство MICROSOFT® по проектированию архитектуры - Архитектура программного обеспечения

Здравствуйте, Aikin, Вы писали:

A>Ага, а потом ни один нормальный разработчик не может вспомнить как же, блин, работать с этим самым Stream

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

A>За что я люблю .net и не люблю Java, что в .Нет все задумываются об удобстве, а не только о кошерности (правильности) архитектуры.
A>В .net есть конструктор StreamReader(string path), что "архитектурно криво", но сцуко, как же удобно. А за new XMLDocument().LoadXML(string xml) я готов расцеловать архитекторов и убить архитекторв java за код ниже. Да он архитектурно чище, но я, блин, прикладной программист, я решаю ЗАДАЧИ, у меня на первом месте стоит УДОБСТВО (удобство использования или удобство модификации зависит от задачи). И в жаве так везде (насколько я могу судить с моим небольшим опытом работы).
Ну, лично я бы предпочёл такие вещи видеть реализованными через Extension Methods. Там и овцы сыты, и волки целы — нет лишних зависимостей, но при этом всё достаточно удобно.

A>СУВ, Aikin

A>P.S. Java код который меня бесит.
A>

A>        DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
A>        DocumentBuilder builder = factory.newDocumentBuilder();
A>        return builder.parse(new InputSource(new StringReader(xmlSource)));
A>

А зачем в три строки-то?

return DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(new InputSource(new StringReader(xmlSource)));

Хотя да, меня, помнится, в джаве раздражало это же самое. Ну и, конечно, то, что джавадок весь из себя Капитан Очевидность. "int parseAdjusting(String s, bool advanced) — этот метод принимает string и bool, возвращает int".
Иногда казалось, что архитекторам джавы очень хотелось, чтобы было так:

ArithmeticFactory af = ArithmeticFactory.GetDefaultFactory();
Arithmetic a = af.newArithmetic(Locale.US, Platform.x32, OverflowAction.Raise);
ArithmeticOperator adder = a.getOperator(Operation.OpAddition, ArithmeticOptions.None);
adder.push(new Integer(2));
adder.push(new Integer(2));
adder.execute();
return ((Integer)adder.pop()).intValue();

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

A>P.P.S. По поводу изначального "флейма": Синклер, уверен ЗевС тебя понимает и согласен с тобой. Вот только вы говорите о разных вещах. Он о неудачно построенной (возможно переведенной) фразе, ты же скипаешь саму фразу и обсуждаешь ее смысл.
Да, может быть.

Здравствуйте, ankorol, Вы писали:

A>Теперь на русском здесь

На русском, прямо на сайте MS, в формате pdf и даже не требует регистрации:
здесь

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>> SQL Express 2005

Здравствуйте, gandjustas, Вы писали:

ZS>>

..наследование увеличивает зависимость между родительским и дочерними классами..

G>Что именно? Чистейшая правда написана.
То что это — цитата капитана очевидность в квадрате. Наследование увеличивает зависимость между родительским и дочерними классами, котороые стали родительским и дочерними в результате наследования...

Здравствуйте, AndrewJD, Вы писали:

AJD>ИМХО, тут речь идет про то, что если есть сущность А и необходимо добавить сущность В, то добавление связи В is A увеличит связность.
Связанность, имхо. И не увеличит, а создаст. Не получается у меня думать о создании чего-то, как о его увеличинии.
ps: бредовая ветка однако... могу гордиться.

Здравствуйте, LGB, Вы писали:

LGB>На русском, прямо на сайте MS, в формате pdf и даже не требует регистрации:

Забавно они генерируют имена файлов.

Здравствуйте, ankorol, Вы писали:

A>Теперь на русском здесь

Это уже третья ссылка за последние 15 минут, которую я вижу и которая указывает на http://здесь.

... << RSDN@Home 1.2.0 alpha 4 rev. 1088>>

Здравствуйте, ankorol, Вы писали:

Цитата из книги, улыбнуло:

..наследование увеличивает зависимость между родительским и дочерними классами..

Здравствуйте, AndrewJD, Вы писали:

AJD>Здравствуйте, Ikemefula, Вы писали:

I>>связанность и связность это разные понятия

AJD>Мы здесь про сoupling

тогда это связанность

>то добавление связи В is A увеличит связанность

Здравствуйте, ZevS, Вы писали:

ZS>А я говорю только про случай, когда у нас уже есть и классы с объекты. Когда они уже как-то там связаны. Они уже в какой-то степени спроектированы и закончены, обадают понятной целостной функциональностью. Уже. Мы не начинаем думать об объекте — потенциальном потомке другого, мы уже подумали и решили что его наследовать не надо. А потом мы вдруг решаем что, почему-то, надо...
Такого случая в природе не бывает. Совершенно непонятно, зачем его обсуждать. Когда и классы и объекты уже есть, ничего делать не надо. Надо идти и делать следующий проект.

ZS>И твоего примера, нам не "нужно обрабатывать HTTP-запросы", мы уже обрабатываем их. И уже понаследовали от System.Object. И наш обработчик уже обрабатывает. А потом, мы берем и наследуем его от Web.UI.Page, что бы использовать часть функциональности Web.UI.Page. При этом не сильно меняем предыдущее поведение. Так вот, именно такое решение вызывает у меня подозрение, хотя и может быть обосновано в редких случаях.
Такое решение ни в каких случаях обосновано быть не может: если проект прошёл QA ("уже обрабатывает"), то дальнейшие изменения, тем более в архитектуре — это чистый убыток.
Речь идёт именно о проектировании, когда все классы и объекты существуют только в голове архитектора (в крайнем случае на бумаге). И вот при этом проектировании вопрос "куда свернуть" нужно принимать с учётом различных эвристик.
В том числе и учитывая то, что выбор наследования в качестве решения задачи увеличивает связность.

Можно, к примеру, отнаследовать TextFile от File, и оборудовать его методами работы с кодировками — чтобы вместо бинарных данных читать текстовые. А можно сделать StreamReader, который не является потомком Stream, зато работает с любыми потоками, в том числе и нефайловыми.

И именно для архитекторов, принимающих эти решения, и пишутся рекомендации, которые вы так критикуете. Связь между StreamReader и Stream существует сама по себе, даже если нет наследования. Так и связь между TextFile и File возникает не в момент наследования, а в тот момент, когда мы формулируем задачу "читать текстовые данные из файла".

Здравствуйте, minorlogic, Вы писали:

M>Может появиться мысль унаследовать квадрат от треугольника.
А что в итоге-то хотим получить?

Механизм для перемещения фигуры (треугольника, квадрата)? В графических редакторах он нередко называется инструментом Move или Arrow.
Механизм для трансформации формы фигуры (треугольника, квадрата)? В графических редакторах он часто называется инструментом Shape.
Иное. Что?

И если этот механизм нам нужно будет поддержать для всех типов фигур, то почему бы соответствующую функцию не добавить в базовый класс — Shape? Или вообще не создавать для каждой фигуры свой класс, а использовать для описания фигуры макро-язык, как это сделано в Microsoft Word? В последнем случае у нас будет только один класс Shape, который будет отвечать за интерпретацию макро-языка, и не будет никаких наследников. И, следовательно, отпадет необходимость в размышлениях на тему "Куда поместить функцию трансформации вершины — в треугольник, квадрат или Shape?".

Здравствуйте, minorlogic, Вы писали:

M>Спасибор кеп, это вы к чему все написали ? Как это относится к примеру который попросили выше по ветке ?
Просто непонятен контекст, в котором возникает приведенная Вами задача. ИМХО, больше походит на пример из учебника по ООП, чем на реальную практическую ситуацию. А коллега, если не ошибаюсь, просил привести реальный, а не учебный пример. Как-то вот так...

Спасибо Кэп 2.

Здравствуйте, minorlogic, Вы писали:

M>Спасибо Кэп 2.
Ну если тебе очевидно, что мысль унаследовать квадрат от треугольника не появится, то к чему был пример?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, _FRED_, Вы писали:

_FR>>Оно не столько увеличивает, сколько цементирует зависимость. Зачастую намертво, ибо что бы разорвать, часто лучше переделать сызново.

VD>Наследование для того и существует чтобы создать зависимость. Просто думать надо над тем что делаешь. Тогда потом не будет хотеться переделать все что написал.

VD>Но вот это конечно совершенно не очевидно для большинства людей. Людям характерно сначала делать, а потом думать как избавиться от печальных последствий непродуманных действий.
мне кажется, что, возможно, самая важная ф-ия наследования это уменьшение кол-ва дублирующегося кода. чтобы не было в коде комментов в стиле "Это не менять! если это поменять сломается то-то" и чтобы не возникало ощущение дежавю при написании кода.
когда у нас есть повторяющееся действие незачем его переписывать копипастом, выдели ф-ию. когда есть общее поведение сущностей — выдели общий ф-ал в базовый класс, когда есть обобщенный прием работы — выдели в шаблон.
а что до делегирования — оно конечно добавляет тупых методов переадресации вызова одного обьекта к другому, что дает доп. строчки кода, которые оплачиваются в некоторых конторах, но все-таки это не совсем проектирование

Здравствуйте, __kot2, Вы писали:

__>когда у нас есть повторяющееся действие незачем его переписывать копипастом, выдели ф-ию. когда есть общее поведение сущностей — выдели общий ф-ал в базовый класс, когда есть обобщенный прием работы — выдели в шаблон.

Вот так и рождается код, который невозможно понять без поллитры, когда есть MyClass, MySpecialClass, MySpecialClassForSpecialUser... и узнать какой метод выполняется можно только под дебарегом.

__>а что до делегирования — оно конечно добавляет тупых методов переадресации вызова одного обьекта к другому, что дает доп. строчки кода, которые оплачиваются в некоторых конторах, но все-таки это не совсем проектирование

Отчего же? Вполне себе проектрирование. Открою секрет, проектирование возможно и вовсе без ООП.

Здравствуйте, ZevS, Вы писали:

ZS>Здравствуйте, __kot2, Вы писали:

__>>когда у нас есть повторяющееся действие незачем его переписывать копипастом, выдели ф-ию. когда есть общее поведение сущностей — выдели общий ф-ал в базовый класс, когда есть обобщенный прием работы — выдели в шаблон.

ZS>Вот так и рождается код, который невозможно понять без поллитры, когда есть MyClass, MySpecialClass, MySpecialClassForSpecialUser... и узнать какой метод выполняется можно только под дебарегом.
это неправильное использование наследования.
тут нужно уметь разделять класс на ортогональные, то есть по сути независимые сущности и параметризовать реализацию этой сущностью. в С++ это реализуется шаблонами.

denisio_mcp пишет:
> Это уже третья ссылка за последние 15 минут, которую я вижу и которая
> указывает на http://здесь.

А я читаю через news.rsdn.ru и у меня все ссылки ведут на http://здесь

Posted via RSDN NNTP Server 2.1 beta

Здравствуйте, ZevS, Вы писали:

ZS>Здравствуйте, ankorol, Вы писали:

ZS>Цитата из книги, улыбнуло:

ZS>

..наследование увеличивает зависимость между родительским и дочерними классами..

Что именно? Чистейшая правда написана.

Здравствуйте, ZevS, Вы писали:

ZS>>>

..наследование увеличивает зависимость между родительским и дочерними классами..

G>>Что именно? Чистейшая правда написана.
ZS>То что это — цитата капитана очевидность в квадрате. Наследование увеличивает зависимость между родительским и дочерними классами, котороые стали родительским и дочерними в результате наследования...

К сожалению, это для очень многих не очевидно.

Здравствуйте, AndrewJD, Вы писали:

AJD>К сожалению, это для очень многих не очевидно.

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

Здравствуйте, ZevS, Вы писали:

AJD>>К сожалению, это для очень многих не очевидно.

ZS>Похоже я не очень ясно выразился. Попробую так — говорить что наследование увеличивает зависимость между родительским и дочерним классом все равно что говорить, что рождение сына улучшает с ним отношения.

Оно не столько увеличивает, сколько цементирует зависимость. Зачастую намертво, ибо что бы разорвать, часто лучше переделать сызново.

Здравствуйте, ZevS, Вы писали:

_FR>>Оно не столько увеличивает, сколько цементирует зависимость. Зачастую намертво, ибо что бы разорвать, часто лучше переделать сызново.
ZS>Оно ее не увеличивает, а рождает. ) Как можно увеличить то, чего нет?
А рождение разве не есть увеличение какой-то величины?

Здравствуйте, AndrewJD, Вы писали:

AJD>А рождение разве не есть увеличение какой-то величины?
Не в этом случае. Здесь величина характеризует связь между сущностями. Нет сущностей — нет связи — нет ее характеристик. Увеличить то, чего нет нельзя. Будет нал референс эксепшн.

Здравствуйте, ZevS, Вы писали:

AJD>>А рождение разве не есть увеличение какой-то величины?
ZS>Не в этом случае. Здесь величина характеризует связь между сущностями. Нет сущностей — нет связи — нет ее характеристик. Увеличить то, чего нет нельзя. Будет нал референс эксепшн.

ИМХО, тут речь идет про то, что если есть сущность А и необходимо добавить сущность В, то добавление связи В is A увеличит связность.

Здравствуйте, AndrewJD, Вы писали:

AJD>>>А рождение разве не есть увеличение какой-то величины?
ZS>>Не в этом случае. Здесь величина характеризует связь между сущностями. Нет сущностей — нет связи — нет ее характеристик. Увеличить то, чего нет нельзя. Будет нал референс эксепшн.

AJD>ИМХО, тут речь идет про то, что если есть сущность А и необходимо добавить сущность В, то добавление связи В is A увеличит связность.

связанность и связность это разные понятия

связность — сцепление.
связанность — соединение, стыковка, а одно из значений — коитус

Здравствуйте, Ikemefula, Вы писали:

I>связанность и связность это разные понятия

Мы здесь про сoupling

Здравствуйте, wildwind, Вы писали:

W>Здравствуйте, LGB, Вы писали:

LGB>>На русском, прямо на сайте MS, в формате pdf и даже не требует регистрации:

W>Забавно они генерируют имена файлов.

HttpContext.Server.UrlDecode("%D1%80%D1%8B_%D0%BF%D1%80%D0%B8%D0%BB%D0%BE%D0%B6%D0%B5%D0%BD%D0%B8%D0%B9_%D0%BF%D0%BE%D0%BB%D0%BD%D0%B0%D1%8F_%D0%BA%D0%BD%D0%B8%D0%B3%D0%B0")

Результат: "ры_приложений_полная_книга"
+1 к забавно

Здравствуйте, ZevS, Вы писали:
ZS>Оно ее не увеличивает, а рождает. ) Как можно увеличить то, чего нет?
Смотря по сравнению с чем.
Имеется в виду следующее: вот у нас два класса, ClassA и ClassB. Мы хотим решить определённую задачу — например, делегировать часть функциональности из ClassB в ClassA.
Решить эту задачу можно не единственным способом. Например, можно спрятать внутрь ClassB ссылку на экземпляр ClassA, и делегировать часть вызовов этому экземпляру.
А можно — унаследовав ClassB от ClassA.

Вот во втором решении ClassB существенно сильнее зависит от ClassA (это, я надеюсь, очевидно?)

Здравствуйте, Sinclair, Вы писали:

S>Смотря по сравнению с чем.
S>Имеется в виду следующее: вот у нас два класса, ClassA и ClassB. Мы хотим решить определённую задачу — например, делегировать часть функциональности из ClassB в ClassA.
Делегирование части функциональности из ClassB в ClassA можеть быть решением какой-то зададачи, но не как не самой задачей. Посему, пример задачи в студию. Не абстрактной, а вполне жизненной, решить которую можно одним из двух описаных методов.

S>Вот во втором решении ClassB существенно сильнее зависит от ClassA (это, я надеюсь, очевидно?)
В случае с насильственным усыновлением — безусловно. Но, опять же, приведенный пример слишком абстрактный. Введение наследования между уже существующими классами — это такое зло, что пофиг на увеличение зависимости... ))

Здравствуйте, ZevS, Вы писали:
ZS>Делегирование части функциональности из ClassB в ClassA можеть быть решением какой-то зададачи, но не как не самой задачей. Посему, пример задачи в студию. Не абстрактной, а вполне жизненной, решить которую можно одним из двух описаных методов.
Ну вот не надо этого начинать. А то так получится, что быстрое перемножение двух разрежённых матриц тоже не может быть самой задачей, а только решением какой-то задачи.
Я привёл жизненную задачу: у вас есть два типа объектов, a и b. При этом у объектов b есть некоторое общее с объектами a поведение, но кое-какое поведение должно быть различным.
Если у вас не встречается такая ситуация, то ООП вам вообще не нужно.

ZS>В случае с насильственным усыновлением — безусловно. Но, опять же, приведенный пример слишком абстрактный. Введение наследования между уже существующими классами — это такое зло, что пофиг на увеличение зависимости... ))
При чём тут насильственное усыновление? Вы так рассуждаете, как будто классы размножаются как кролики, а вы только вносите небольшие коррективы в этот стихийный процесс.
На самом деле всё строго наоборот: "в природе" никаких классов нету. Это вы решаете, сколько будет классов, и в каких отношениях они будут состоять.
Вот, к примеру, Дельфи. Там принято настраивать поведение компонентов безо всякого наследования — исключительно навешиванием обработчиков событий. А вот формы там же принято наследовать.
Внимание, вопрос: является ли наследование TMainForm от TForm "насильственным"?
Ведь ровно тот же эффект в 99% случаев можно получить, просто породив экземпляр TForm и привязав к нему обработчики OnXXX, расположенные где угодно (хоть вообще на уровне модуля, безо всяких классов).

Здравствуйте, Sinclair, Вы писали:

S>Ну вот не надо этого начинать. А то так получится, что быстрое перемножение двух разрежённых матриц тоже не может быть самой задачей, а только решением какой-то задачи.
Ну, может погорячился..

S>При чём тут насильственное усыновление? Вы так рассуждаете, как будто классы размножаются как кролики, а вы только вносите небольшие коррективы в этот стихийный процесс.
Наоборот, это в Вашем примере сначала каким-то образом рождаются классы, а уже потом мы вдруг хотим их породнить. В 99% случаев класс создается как потомок. 1% оставляю на стихийное бесконтрольное размножение и случай когда наш класс нужно интегрировать в сторонний продукт.

S>На самом деле всё строго наоборот: "в природе" никаких классов нету. Это вы решаете, сколько будет классов, и в каких отношениях они будут состоять.
Вот я о том же. И ситуация, когда можно отнаследовать один уже существующий класс со своей функциональностью от друго со своей — крайне подозрительна, и наводит на мысли об отсуствии это самого нашего решения об их отношениях.

S>Внимание, вопрос: является ли наследование TMainForm от TForm "насильственным"?
Нет. TMainForm задуман и рожден как наследник TForm. А вот если у нас есть класс TRabbitForm умеющий есть морковку и прыгать, и вдруг мы решаем, для чего-то, отнаследовать его но TMeat — тогда да.

Здравствуйте, ZevS, Вы писали:

ZS>Наоборот, это в Вашем примере сначала каким-то образом рождаются классы, а уже потом мы вдруг хотим их породнить. В 99% случаев класс создается как потомок. 1% оставляю на стихийное бесконтрольное размножение и случай когда наш класс нужно интегрировать в сторонний продукт.

ZS>Вот я о том же. И ситуация, когда можно отнаследовать один уже существующий класс со своей функциональностью от друго со своей — крайне подозрительна, и наводит на мысли об отсуствии это самого нашего решения об их отношениях.
Нет. Классы — не кролики, никакого "естественного" пути порождения потомков у них нету.
ООП — оно на самом деле про объекты. Класс создаётся не как потомок, а как выражение поведения объекта.
Ну вот из более жизненных примеров: вам нужно обрабатывать HTTP-запросы. Понятно, что в идеологии ASP.NET вам нужно реализовать IHttpHandler. От кого будете наследоваться? От System.Web.UI.Page? Или от System.Object? А может, ещё от какого-то Решение совершенно неочевидно. И принимается именно так: смотрим на нужное нам поведение и выбираем, что будет лучше.

S>>Внимание, вопрос: является ли наследование TMainForm от TForm "насильственным"?
ZS>Нет. TMainForm задуман и рожден как наследник TForm.
С чего бы это? TMainForm задуман и рождён как форма с определённой функциональностью. Её запросто можно ни от каких TForm не наследовать. Если вы сразу "задумываете" классы в терминах "о, здесь нужен наследник TForm", то вы рискуете огрести избыточную связность.

Здравствуйте, Sinclair, Вы писали:

То о чем говоришь ты — очевидные вещи, с которыми я не спорю. Просто они не являются ответом (коментарием) на то что говорю я.

А я говорю только про случай, когда у нас уже есть и классы с объекты. Когда они уже как-то там связаны. Они уже в какой-то степени спроектированы и закончены, обадают понятной целостной функциональностью. Уже. Мы не начинаем думать об объекте — потенциальном потомке другого, мы уже подумали и решили что его наследовать не надо. А потом мы вдруг решаем что, почему-то, надо...
И твоего примера, нам не "нужно обрабатывать HTTP-запросы", мы уже обрабатываем их. И уже понаследовали от System.Object. И наш обработчик уже обрабатывает. А потом, мы берем и наследуем его от Web.UI.Page, что бы использовать часть функциональности Web.UI.Page. При этом не сильно меняем предыдущее поведение. Так вот, именно такое решение вызывает у меня подозрение, хотя и может быть обосновано в редких случаях.

Здравствуйте, Sinclair, Вы писали:

S>Такого случая в природе не бывает. Совершенно непонятно, зачем его обсуждать. Когда и классы и объекты уже есть, ничего делать не надо. Надо идти и делать следующий проект.
S>Такое решение ни в каких случаях обосновано быть не может: если проект прошёл QA ("уже обрабатывает"), то дальнейшие изменения, тем более в архитектуре — это чистый убыток.
В идеальном мире — безусловно. Но в мире где мы живем, изменения в работающем код нередки. Причиной могут быть требования заказчика, переход на новую платформу, отказ от использования устаревшей библиотеки...

S>И именно для архитекторов, принимающих эти решения, и пишутся рекомендации, которые вы так критикуете.
Да ничего я не критикую, просто показалась забавной фраза, в которой говорится об увеличении зависимости в следствие наследования, которой вообще не существовало до использования наследования. Считайте что я просто придрался к построению предложения. И то, не сильно. Бурные дебаты по этому поводу меня удивляют.

Здравствуйте, Sinclair, Вы писали:

Блин, не хочу флеймить и отдалятся от темы. Но не могу удержаться.

S>Можно, к примеру, отнаследовать TextFile от File, и оборудовать его методами работы с кодировками — чтобы вместо бинарных данных читать текстовые. А можно сделать StreamReader, который не является потомком Stream, зато работает с любыми потоками, в том числе и нефайловыми.
Ага, а потом ни один нормальный разработчик не может вспомнить как же, блин, работать с этим самым Stream

Я вот до сих пор лезу в гугл чтобы узнать как же это делается.
За что я люблю .net и не люблю Java, что в .Нет все задумываются об удобстве, а не только о кошерности (правильности) архитектуры.
В .net есть конструктор StreamReader(string path), что "архитектурно криво", но сцуко, как же удобно. А за new XMLDocument().LoadXML(string xml) я готов расцеловать архитекторов и убить архитекторв java за код ниже. Да он архитектурно чище, но я, блин, прикладной программист, я решаю ЗАДАЧИ, у меня на первом месте стоит УДОБСТВО (удобство использования или удобство модификации зависит от задачи). И в жаве так везде (насколько я могу судить с моим небольшим опытом работы).

СУВ, Aikin

P.S. Java код который меня бесит.

        DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
        DocumentBuilder builder = factory.newDocumentBuilder();
        return builder.parse(new InputSource(new StringReader(xmlSource)));

P.P.S. По поводу изначального "флейма": Синклер, уверен ЗевС тебя понимает и согласен с тобой. Вот только вы говорите о разных вещах. Он о неудачно построенной (возможно переведенной) фразе, ты же скипаешь саму фразу и обсуждаешь ее смысл.

... << RSDN@Home 1.2.0 alpha 4 rev. 1466>>

Здравствуйте, Sinclair, Вы писали:

S>Ну, лично я бы предпочёл такие вещи видеть реализованными через Extension Methods. Там и овцы сыты, и волки целы — нет лишних зависимостей, но при этом всё достаточно удобно.
Отличный инструмент, согласен. Но это сейчас, когда он есть. А когда его нет, то я предпочитаю удобство, а не чистоту и правильность архитектуры

S>

S>return DocumentBuilderFactory.newInstance().newDocumentBuilder().parse(new InputSource(new StringReader(xmlSource)));
S>

Дело не в количестве строк, а концентрации информации в них: фактори, билдер, парсинг, импут сорс, стринг билдер. Запомнить это нереально.

S>

S>ArithmeticFactory af = ArithmeticFactory.GetDefaultFactory();
S>Arithmetic a = af.newArithmetic(Locale.US, Platform.x32, OverflowAction.Raise);
S>ArithmeticOperator adder = a.getOperator(Operation.OpAddition, ArithmeticOptions.None);
S>adder.push(new Integer(2));
S>adder.push(new Integer(2));
S>adder.execute();
S>return ((Integer)adder.pop()).intValue();
S>

S>И чтоб этот код можно было соорудить, только по два раза прочитав док по каждому из задействованных классов

+100

СУВ, Aikin

... << RSDN@Home 1.2.0 alpha 4 rev. 1466>>

Здравствуйте, ZevS, Вы писали:

ZS>Не получается у меня думать о создании чего-то, как о его увеличинии.

Учи кванты

Операторы рождения-уничтожения

Две геометрические фигуры, треугольник и квадрат наследники от shape.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

Здравствуйте, Кирилл Лебедев, Вы писали:

КЛ>Здравствуйте, minorlogic, Вы писали:

M>>Может появиться мысль унаследовать квадрат от треугольника.
КЛ>А что в итоге-то хотим получить?

КЛ>

КЛ>

Механизм для перемещения фигуры (треугольника, квадрата)? В графических редакторах он нередко называется инструментом Move или Arrow.
КЛ>

Механизм для трансформации формы фигуры (треугольника, квадрата)? В графических редакторах он часто называется инструментом Shape.
КЛ>

Иное. Что?
КЛ>

КЛ>И если этот механизм нам нужно будет поддержать для всех типов фигур, то почему бы соответствующую функцию не добавить в базовый класс — Shape? Или вообще не создавать для каждой фигуры свой класс, а использовать для описания фигуры макро-язык, как это сделано в Microsoft Word? В последнем случае у нас будет только один класс Shape, который будет отвечать за интерпретацию макро-языка, и не будет никаких наследников. И, следовательно, отпадет необходимость в размышлениях на тему "Куда поместить функцию трансформации вершины — в треугольник, квадрат или Shape?".

Спасибор кеп, это вы к чему все написали ? Как это относится к примеру который попросили выше по ветке ?

... << RSDN@Home 1.2.0 alpha 4 rev. 1237>>

Здравствуйте, minorlogic, Вы писали:

M>Две геометрические фигуры, треугольник и квадрат наследники от shape.
M>Мы реализуем в треугольнике ф-ю трансформации вершины.
M>Такая ж пондобилась позже у квадрата.
M>Может появиться мысль унаследовать квадрат от треугольника.

А попробуй написать код. Скорее всего появится одна из следующих мыслей:
— наследовать квадрат от треугольника слишком — слишком трудоемкое решение (подогнать реализацию трансформации вершины для треугольника под квадрат может оказаться сложной бесполезной задачей).
— нужно создать класс многоугольник наследник shape, реализовать в нем трансформацию вершины, и уже от него понаследовать и треугольник и квадрат.

Здравствуйте, jazzer, Вы писали:

J>Учи кванты

В детстве выписывал такой журнал

J>Операторы рождения

Это акушеры что ль?

Здравствуйте, _FRED_, Вы писали:

_FR>Оно не столько увеличивает, сколько цементирует зависимость. Зачастую намертво, ибо что бы разорвать, часто лучше переделать сызново.

Наследование для того и существует чтобы создать зависимость. Просто думать надо над тем что делаешь. Тогда потом не будет хотеться переделать все что написал.

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

Здравствуйте, Aikin, Вы писали:

A>В .net есть конструктор StreamReader(string path), что "архитектурно криво", но сцуко, как же удобно. А за new XMLDocument().LoadXML(string xml) я готов расцеловать архитекторов и убить архитекторв java за код ниже. Да он архитектурно чище, но я, блин, прикладной программист, я решаю ЗАДАЧИ, у меня на первом месте стоит УДОБСТВО (удобство использования или удобство модификации зависит от задачи).

С каких это пор умножение сущностей без необходимости стало архитектурно более чистым кодом?

A>

A>        DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
A>        DocumentBuilder builder = factory.newDocumentBuilder();
A>        return builder.parse(new InputSource(new StringReader(xmlSource)));
A>

Здравствуйте, ankorol, Вы писали:

A>Теперь на русском здесь
Вот проектировщики пошли, переведённую литературу читают

Здравствуйте, ZevS, Вы писали:
ZS>Вот так и рождается код, который невозможно понять без поллитры, когда есть MyClass, MySpecialClass, MySpecialClassForSpecialUser... и узнать какой метод выполняется можно только под дебарегом.
кстати, вы раз делаете такие выводы, то явно не читали Александреску — "современное проектирование". Как не плодить ненужные сущности — это как раз можно сказать и есть главная тема его книги. два самых мощных инструмента для компактной, гибкой и расширяемой архитектуры — множественное наследование и развитые шаблоны. раз уж люди выпускают целые языки программирования, которые называют современными, в которых нет ни первого ни второго, то понятно, что книжка Александреску понятна будет не каждому и многие сочли ее просто сбором извращений, хотя мысли ее очень простые, глубокие и компактные.

Здравствуйте, __kot2, Вы писали:

__>>>когда у нас есть повторяющееся действие незачем его переписывать копипастом, выдели ф-ию. когда есть общее поведение сущностей — выдели общий ф-ал в базовый класс, когда есть обобщенный прием работы — выдели в шаблон.

ZS>>Вот так и рождается код, который невозможно понять без поллитры, когда есть MyClass, MySpecialClass, MySpecialClassForSpecialUser... и узнать какой метод выполняется можно только под дебарегом.
__>это неправильное использование наследования.
__>тут нужно уметь разделять класс на ортогональные, то есть по сути независимые сущности и параметризовать реализацию этой сущностью. в С++ это реализуется шаблонами.

Ну значит я неправильно вас понял, возможно, потому что вы нечетко сформулировали.

Здравствуйте, __kot2, Вы писали:

__>кстати, вы раз делаете такие выводы, то явно не читали Александреску — "современное проектирование". Как не плодить ненужные сущности — это как раз можно сказать и есть главная тема его книги. два самых мощных инструмента для компактной, гибкой и расширяемой архитектуры — множественное наследование и развитые шаблоны. раз уж люди выпускают целые языки программирования, которые называют современными, в которых нет ни первого ни второго, то понятно, что книжка Александреску понятна будет не каждому и многие сочли ее просто сбором извращений, хотя мысли ее очень простые, глубокие и компактные.

"Не плодить ненужные сущности" и уменьшение сложности — не одно и то же.

Здравствуйте, ZevS, Вы писали:

ZS>Здравствуйте, __kot2, Вы писали:

__>>кстати, вы раз делаете такие выводы, то явно не читали Александреску — "современное проектирование". Как не плодить ненужные сущности — это как раз можно сказать и есть главная тема его книги. два самых мощных инструмента для компактной, гибкой и расширяемой архитектуры — множественное наследование и развитые шаблоны. раз уж люди выпускают целые языки программирования, которые называют современными, в которых нет ни первого ни второго, то понятно, что книжка Александреску понятна будет не каждому и многие сочли ее просто сбором извращений, хотя мысли ее очень простые, глубокие и компактные.

ZS>"Не плодить ненужные сущности" и уменьшение сложности — не одно и то же.
программа как идея. когда в ней сказано все что нужно и ничего лишнего, она четкая и понятная. когда мысль пытается сформулировать человек который ее неглубоко понимает, мысль запутывается и обрастает ненужными сущностями, взаимосвязями и исключениями из правил. когда человек не понимает того что делает программа он плодит сущности, чтобы реализовать ту часть которую он понимает в данный момент. если есть понимание программы целиком, то создается лишь минимальный набор сущностей и взаимодействий.

Здравствуйте, ZevS, Вы писали:
ZS>"Не плодить ненужные сущности" и уменьшение сложности — не одно и то же.
представим себе, что программист- бог и он проектирует первого человека
берет тз. рисует туловище — контейнер внутренностей. по тз — должен ходить — рисует ноги. должен думать — рисует голову. дальше смотрит по тз — должен есть. рисует рот. так, а как пищу принимать будет? значит, ему нужна ложка. пририсовывает к туловищу манипулятор с ложкой. еще он должен уметь водить машину. пририсовывает руль к груди человека. крутить он его пусть зубами будет.
так, значит, ему нужно ходить в толчок и потомство заводить. значит, у мужчины еще будет член. о! оптимизация! можно руль убрать а сделать чтобы членом можно было как джойстиком зубами крутить и так будет машина управляться.
потом вспоминает про вилку, но решает для оптимизации сделать ее складывающейся в ухо. еще он должен охотиться уметь — пририсовывает манипулятор с ножом к туловищу.

а всего-то нужно было понять задачу целиком и осознать, что схеме не хватает рук с кучей степеней свобод и 5ю пальцами!

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

	От:	ankorol
	Дата:	17.02.10 10:01
	Оценка:	136 (20)

От:	Sinclair	https://github.com/evilguest/
Дата:	10.06.10 03:45
Оценка:	1 (1) +1

	От:	LGB
	Дата:	01.06.10 14:41
	Оценка:	40 (7)

	От:	akasoft
	Дата:	04.06.10 11:51
	Оценка:

	От:	ZevS
	Дата:	03.06.10 13:52
	Оценка:	1 (1) +2

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	04.06.10 15:18
Оценка:	-1

От:	Кирилл Лебедев	http://askofen.blogspot.com/
Дата:	13.06.10 08:10
Оценка:	+1

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	03.06.10 13:18
Оценка:

От:	_FRED_	@ViIvanov
Дата:	04.06.10 08:45
Оценка:

От:	Aikin	kavaleu.ru
Дата:	09.06.10 09:04
Оценка:

От:	jazzer	Skype: enerjazzer
Дата:	12.06.10 12:33
Оценка:

От:	VladD2	www.nemerle.org
Дата:	18.11.10 16:45
Оценка:

	От:	minorlogic
	Дата:	15.06.10 08:12
	Оценка:	-1

	От:	__kot2
	Дата:	21.11.10 16:27
	Оценка:	-1

	От:	__kot2
	Дата:	22.11.10 15:09
	Оценка:	+1

	От:	ArtDenis
	Дата:	19.02.10 11:27
	Оценка: