Здравствуйте, _FRED_, Вы писали:
_FR>Оно не столько увеличивает, сколько цементирует зависимость. Зачастую намертво, ибо что бы разорвать, часто лучше переделать сызново.
Наследование для того и существует чтобы создать зависимость. Просто думать надо над тем что делаешь. Тогда потом не будет хотеться переделать все что написал.
Но вот это конечно совершенно не очевидно для большинства людей. Людям характерно сначала делать, а потом думать как избавиться от печальных последствий непродуманных действий.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[8]: [ANN] Руководство MICROSOFT® по проектированию архите
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, _FRED_, Вы писали:
_FR>>Оно не столько увеличивает, сколько цементирует зависимость. Зачастую намертво, ибо что бы разорвать, часто лучше переделать сызново.
VD>Наследование для того и существует чтобы создать зависимость. Просто думать надо над тем что делаешь. Тогда потом не будет хотеться переделать все что написал.
VD>Но вот это конечно совершенно не очевидно для большинства людей. Людям характерно сначала делать, а потом думать как избавиться от печальных последствий непродуманных действий.
мне кажется, что, возможно, самая важная ф-ия наследования это уменьшение кол-ва дублирующегося кода. чтобы не было в коде комментов в стиле "Это не менять! если это поменять сломается то-то" и чтобы не возникало ощущение дежавю при написании кода.
когда у нас есть повторяющееся действие незачем его переписывать копипастом, выдели ф-ию. когда есть общее поведение сущностей — выдели общий ф-ал в базовый класс, когда есть обобщенный прием работы — выдели в шаблон.
а что до делегирования — оно конечно добавляет тупых методов переадресации вызова одного обьекта к другому, что дает доп. строчки кода, которые оплачиваются в некоторых конторах, но все-таки это не совсем проектирование
Re[9]: [ANN] Руководство MICROSOFT® по проектированию архите
Здравствуйте, __kot2, Вы писали:
__>когда у нас есть повторяющееся действие незачем его переписывать копипастом, выдели ф-ию. когда есть общее поведение сущностей — выдели общий ф-ал в базовый класс, когда есть обобщенный прием работы — выдели в шаблон.
Вот так и рождается код, который невозможно понять без поллитры, когда есть MyClass, MySpecialClass, MySpecialClassForSpecialUser... и узнать какой метод выполняется можно только под дебарегом.
__>а что до делегирования — оно конечно добавляет тупых методов переадресации вызова одного обьекта к другому, что дает доп. строчки кода, которые оплачиваются в некоторых конторах, но все-таки это не совсем проектирование
Отчего же? Вполне себе проектрирование. Открою секрет, проектирование возможно и вовсе без ООП.
Re[16]: [ANN] Руководство MICROSOFT® по проектированию архит
Здравствуйте, 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>
Re: [ANN] Руководство MICROSOFT® по проектированию архитекту
Здравствуйте, ZevS, Вы писали:
ZS>Здравствуйте, __kot2, Вы писали:
__>>когда у нас есть повторяющееся действие незачем его переписывать копипастом, выдели ф-ию. когда есть общее поведение сущностей — выдели общий ф-ал в базовый класс, когда есть обобщенный прием работы — выдели в шаблон.
ZS>Вот так и рождается код, который невозможно понять без поллитры, когда есть MyClass, MySpecialClass, MySpecialClassForSpecialUser... и узнать какой метод выполняется можно только под дебарегом.
это неправильное использование наследования.
тут нужно уметь разделять класс на ортогональные, то есть по сути независимые сущности и параметризовать реализацию этой сущностью. в С++ это реализуется шаблонами.
Re[10]: [ANN] Руководство MICROSOFT® по проектированию архит
Здравствуйте, ZevS, Вы писали: ZS>Вот так и рождается код, который невозможно понять без поллитры, когда есть MyClass, MySpecialClass, MySpecialClassForSpecialUser... и узнать какой метод выполняется можно только под дебарегом.
кстати, вы раз делаете такие выводы, то явно не читали Александреску — "современное проектирование". Как не плодить ненужные сущности — это как раз можно сказать и есть главная тема его книги. два самых мощных инструмента для компактной, гибкой и расширяемой архитектуры — множественное наследование и развитые шаблоны. раз уж люди выпускают целые языки программирования, которые называют современными, в которых нет ни первого ни второго, то понятно, что книжка Александреску понятна будет не каждому и многие сочли ее просто сбором извращений, хотя мысли ее очень простые, глубокие и компактные.
Re[11]: [ANN] Руководство MICROSOFT® по проектированию архит
Здравствуйте, __kot2, Вы писали:
__>>>когда у нас есть повторяющееся действие незачем его переписывать копипастом, выдели ф-ию. когда есть общее поведение сущностей — выдели общий ф-ал в базовый класс, когда есть обобщенный прием работы — выдели в шаблон.
ZS>>Вот так и рождается код, который невозможно понять без поллитры, когда есть MyClass, MySpecialClass, MySpecialClassForSpecialUser... и узнать какой метод выполняется можно только под дебарегом. __>это неправильное использование наследования. __>тут нужно уметь разделять класс на ортогональные, то есть по сути независимые сущности и параметризовать реализацию этой сущностью. в С++ это реализуется шаблонами.
Ну значит я неправильно вас понял, возможно, потому что вы нечетко сформулировали.
Re[11]: [ANN] Руководство MICROSOFT® по проектированию архит
Здравствуйте, __kot2, Вы писали:
__>кстати, вы раз делаете такие выводы, то явно не читали Александреску — "современное проектирование". Как не плодить ненужные сущности — это как раз можно сказать и есть главная тема его книги. два самых мощных инструмента для компактной, гибкой и расширяемой архитектуры — множественное наследование и развитые шаблоны. раз уж люди выпускают целые языки программирования, которые называют современными, в которых нет ни первого ни второго, то понятно, что книжка Александреску понятна будет не каждому и многие сочли ее просто сбором извращений, хотя мысли ее очень простые, глубокие и компактные.
"Не плодить ненужные сущности" и уменьшение сложности — не одно и то же.
Re[12]: [ANN] Руководство MICROSOFT® по проектированию архит
Здравствуйте, ZevS, Вы писали:
ZS>Здравствуйте, __kot2, Вы писали:
__>>кстати, вы раз делаете такие выводы, то явно не читали Александреску — "современное проектирование". Как не плодить ненужные сущности — это как раз можно сказать и есть главная тема его книги. два самых мощных инструмента для компактной, гибкой и расширяемой архитектуры — множественное наследование и развитые шаблоны. раз уж люди выпускают целые языки программирования, которые называют современными, в которых нет ни первого ни второго, то понятно, что книжка Александреску понятна будет не каждому и многие сочли ее просто сбором извращений, хотя мысли ее очень простые, глубокие и компактные.
ZS>"Не плодить ненужные сущности" и уменьшение сложности — не одно и то же.
программа как идея. когда в ней сказано все что нужно и ничего лишнего, она четкая и понятная. когда мысль пытается сформулировать человек который ее неглубоко понимает, мысль запутывается и обрастает ненужными сущностями, взаимосвязями и исключениями из правил. когда человек не понимает того что делает программа он плодит сущности, чтобы реализовать ту часть которую он понимает в данный момент. если есть понимание программы целиком, то создается лишь минимальный набор сущностей и взаимодействий.
Re[12]: [ANN] Руководство MICROSOFT® по проектированию архит
Здравствуйте, ZevS, Вы писали: ZS>"Не плодить ненужные сущности" и уменьшение сложности — не одно и то же.
представим себе, что программист- бог и он проектирует первого человека
берет тз. рисует туловище — контейнер внутренностей. по тз — должен ходить — рисует ноги. должен думать — рисует голову. дальше смотрит по тз — должен есть. рисует рот. так, а как пищу принимать будет? значит, ему нужна ложка. пририсовывает к туловищу манипулятор с ложкой. еще он должен уметь водить машину. пририсовывает руль к груди человека. крутить он его пусть зубами будет.
так, значит, ему нужно ходить в толчок и потомство заводить. значит, у мужчины еще будет член. о! оптимизация! можно руль убрать а сделать чтобы членом можно было как джойстиком зубами крутить и так будет машина управляться.
потом вспоминает про вилку, но решает для оптимизации сделать ее складывающейся в ухо. еще он должен охотиться уметь — пририсовывает манипулятор с ножом к туловищу.
а всего-то нужно было понять задачу целиком и осознать, что схеме не хватает рук с кучей степеней свобод и 5ю пальцами! но рук нет в тз и и нужно уметь разглядывать как можно введя неочевидную сущность полностью упростить архитектуру.
Re[2]: [ANN] Руководство MICROSOFT® по проектированию архите
Здравствуйте, ZevS, Вы писали:
G>>Что именно? Чистейшая правда написана. ZS>То что это — цитата капитана очевидность в квадрате. Наследование увеличивает зависимость между родительским и дочерними классами, котороые стали родительским и дочерними в результате наследования...
К.О. здесь ни при чем. Я видел несколько архитектур где слои приложения связаны между собой НАСЛЕДОВАНИЕМ.
Re[6]: [ANN] Руководство MICROSOFT® по проектированию архите
Здравствуйте, ZevS, Вы писали:
ZS>Похоже я не очень ясно выразился. Попробую так — говорить что наследование увеличивает зависимость между родительским и дочерним классом все равно что говорить, что рождение сына улучшает с ним отношения.
А что там в английском ?
Re[8]: [ANN] Руководство MICROSOFT® по проектированию архите
Здравствуйте, ZevS, Вы писали:
_FR>>Оно не столько увеличивает, сколько цементирует зависимость. Зачастую намертво, ибо что бы разорвать, часто лучше переделать сызново. ZS>Оно ее не увеличивает, а рождает. ) Как можно увеличить то, чего нет?
Ну было у тебя два класа, а потом ты решил что много дублирования и один пронаследовал от другого.
Re[3]: [ANN] Руководство MICROSOFT® по проектированию архите
