Здравствуйте, LaPerouse, Вы писали:
LP>Здравствуйте, IB, Вы писали:
IB>>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>> Примеров таких на свете сколько угодно. IB>>Ну давай, практический пример, где бы это было оправдано, хоть один?
LP>Почему же, можно придумать такие примеры.
LP>Собственно, какие преимущества могут быть у создания наследника с нужным методом по сравнению с тем случаем, когда этот метод — внешний (в делегирующем классе или вовсе статич.)? Только одно — полиморфное использование соотв. класса через библиотечный интерфейс — в данном случае String. Чтобы с новым объектом MyString можно было работать как со String. И чтобы библ. методы могли таким образом использовать эту реализацию. Если бы String создавался только через фабрику и мы бы имели бы возможность сделать String.setCurrentFactoty(myStringFactory), то такое очень даже имело бы смысл. Другое дело, что в этом случае автор библиотеки вряд ли стал бы закрывать String... Так как он был бы расчитан на такое вот применение.
Да, еще один очевидный случай забыл написать, хотя и хотел.
Предположим, реализация String нас не устраивает, и мы решили дополнить ее. Но мы хотим, чтобы наши новые методы, использующие реализацию MyString, также работали и со String без всякого
MyString MyString.fromString(String).
Это, кстати, реальнейший пример такой необходимости. По сути, это единственная причина (если не считать сферовакуума с фабрикой, опис. в предыдущем моем посте), которая может завставить это делать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали:
LP>Если бы String создавался только через фабрику и мы бы имели бы возможность сделать String.setCurrentFactoty(myStringFactory), то такое очень даже имело бы смысл.
И каждая сторонняя библиотека пыталась бы установить свою фабрику и ломалась бы при работе с чужими фабриками. Нет уж, спасибо
Здравствуйте, 4058, Вы писали:
4>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Вот, например класс CStringEx — расширяет стандартный класс CString из MFC
4>1. System.String в отличие от CString иммутабелен, в частности по этому класс запечатан.
А я-то не знал . Дискуссию, почему он иммутабелен, открывать, надеюсь, не будем, а вот вопрос один есть.
Этот-то класс запечатан, потому что он иммутабелен, ладно, пусть, а вот почему другие, не иммутабельные классы — то запечатаны ?
Я же привел тебе CStringEx
PD>>Вот, например класс CStringEx — расширяет стандартный класс CString из MFC IB>Если в одном месте накосячили, значит везде нужно? Тут ребята наступили ровно на те же грабли, более того, они это явно осознают: IB>Some of the CStringEx functions use knowledge of the internal structure of the CString object so there is a small chance that these functions might break if the CString implementation changes. IB>Это настолько явный косяк, что тут даже говорить не о чем. И вообще, с каких пор кривые реализации левых библиотек стали аргументом? IB>Эти ребята, всего лишь, в очередной раз показали как нельзя делать.
Ну и т.д. Было бы у меня времени больше — мог бы целый список составить. Да только незачем — это настолько обычная практика в MFC, что как-то даже неудобно доказывать ее право на существование.
А примеры того, где это может быть нужно, можешь там и посмотреть. Там demo есть.
IB>Вот я тебе и объясняю, что это не просто криво, а является грубейшей ошибкой в следствии не понимания того, что собственно представляет собой ООП и как им правильно пользоваться.
Беда в том, что и ты, и Антон, да и не только вы, а многие здесь, относятся к правилам как к чему-то такому, что нарушать нельзя ни в коем случае. Запрещено, и точка. Все равно, что попытка нарушить закон сохранения энергии — того, кто в своих рассуждениях ему противоречит, надо пригвоздить к позорному столбу, вот и все. И если чье-то решение подпадает под некий анти-паттерн, к примеру — анафема, и все.
Что же касается меня, то я к ним отношусь как не более чем неким рекомендациям. Им можно следовать, им, наверное, даже лучше следовать, но если есть к тому основание, ими вполне можно пренебречь. И не бояться при этом обвинений в незнании принципов ООП или некошерности в каком бы то ни было ином смысле, или даже в кривизне решения. Просто надо сравнить проигрыш от неследования этим правилам и выигрыш от этого же неследования. Если второе перевешивает — спокойно нарушаем эти правила и посылаем куда угодно критиков. А перевешивает или нет — зависит от задачи и целей. Кому-то очень важна легкость сопровождения, и ради нее он готов пожертвовать быстродействием, а кому-то (мне) нужно получить максимальное быстродействие любой ценой, потому что все прочие нарушения заказчик мне простит, а вот потерю быстродействия — нет.
А критерием истины, как тут Антон заметил (а впрочем, и до него другие замечали является практика. А поэтому я имею полное основание утверждать, что то, что я говорю, имеет полное право на существование. Потому что я в своей практике все и всяческие каноны нарушал многократно, да еще как нарушал, и ничего — все работает уже много лет, и никто не жалуется, и работает не на 2-3 компьютерах и не в фирме "Рога и копыта"
А в применении к вопросу, из-за которого сыр-бор разгорелся (sealed классы) — я просто одну простую вещь хочу сказать. Не надо меня от меня защищать. Или по крайней мере дайте мне легальную возможность эту защиту отменить. Да, я могу, если мне разрешить, накосячить с реализацией. Да, это будет плохо. Но могу и не накосячить. А поэтому не принимайте за меня решения, оставьте их мне. Накосячу — сам виноват и буду.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну и т.д. Было бы у меня времени больше — мог бы целый список составить. Да только незачем — это настолько обычная практика в MFC, что как-то даже неудобно доказывать ее право на существование.
Неудобно ее доказывать, Павел, вовсе не потому, что она "обычная". А потому, что доказательств нету. Весь этот топик наглядно это показывает.
PD>Беда в том, что и ты, и Антон, да и не только вы, а многие здесь, относятся к правилам как к чему-то такому, что нарушать нельзя ни в коем случае. Запрещено, и точка. Все равно, что попытка нарушить закон сохранения энергии — того, кто в своих рассуждениях ему противоречит, надо пригвоздить к позорному столбу, вот и все. И если чье-то решение подпадает под некий анти-паттерн, к примеру — анафема, и все.
Очередной пассаж с называнием черного белым.
Поясняю мысль: Нет, Павел, всё как раз наоборот. Мы никак не относимся к правилам как к скрижалям. Мы просто понимаем, зачем придумываются правила, и по каким критериям нужно сравнивать решения.
А ты берешь заученные на плохих примерах решения, и не напрягая мысль ни на минуту, твердишь нам "это хорошо, потому что это очевидно хорошо, а кому не очевидно, тот не знает принципов ООП".
Вот привел ты два примера. Оба не работают. Не потому, что нарушают какие-то догматические принципы, а потому, что делают код хуже. По объективным критериям: объем и стоимость поддержки.
PD>А критерием истины, как тут Антон заметил (а впрочем, и до него другие замечали является практика. А поэтому я имею полное основание утверждать, что то, что я говорю, имеет полное право на существование.
Павел, я даже допускаю, что в реальной жизни ты не пишешь такую херню, как в примерах с MyDirectory и MyString.IsPalindrome. Наверное, тебе просто трудно придумать удачный пример, где запечатанность реально мешает.
Если же ты реально веришь, что CStringEx хоть в чём-то лучше, чем PalindromManager.IsPalindrome(this string str), то мне тебя жалко.
PD>Потому что я в своей практике все и всяческие каноны нарушал многократно, да еще как нарушал, и ничего — все работает уже много лет, и никто не жалуется, и работает не на 2-3 компьютерах и не в фирме "Рога и копыта"
PD>А в применении к вопросу, из-за которого сыр-бор разгорелся (sealed классы) — я просто одну простую вещь хочу сказать. Не надо меня от меня защищать. Или по крайней мере дайте мне легальную возможность эту защиту отменить. Да, я могу, если мне разрешить, накосячить с реализацией. Да, это будет плохо. Но могу и не накосячить. А поэтому не принимайте за меня решения, оставьте их мне. Накосячу — сам виноват и буду.
Вот самое что мне нравится в этой дискуссии (как и многих других с тобой), что ты замечательным образом доказываешь правоту своих оппонентов. Ну вот смотри — делается абстрактное заявление "sealed есмь зло, потому что иногда оно может мне помешать". Но когда в течение недели ты не в состоянии привести ни одного примера, где оно реально мешает, посторонний читатель делает совершенно верный вывод: "Раз даже мегаопытный Павел Дворкин не может придумать конкретного примера, значит это действительно практически никогда не нужно. Тогда зачем требовать возможность, которая помогает 1% программистов в 1% их задач, но при этом мешает 90% программистов в 10% их задач?". Всё, бухгалтерия свернулась.
И еще раз поясню, что заблуждения твои связаны с тем, что ты писал исключительно одноразовый прикладной софт. Вопросы повторного использования тебя не волнуют, равно как и вопросы выполнения каких-либо гарантий.
Одно дело, когда ты пишешь своё приложение — как я уже говорил, там можешь хоть на коболе интегралы вычислять, хоть подчерками все переменные называть. С тебя не убудет.
А вот если ты выпускаешь библиотеку, целевая аудитория которой — миллион программистов, то приходится думать и о том, как будет выпускаться версия 2.0.
Это ты за себя можешь сказать "оставьте их мне; сам накосячу — сам виноват и буду". А для вендора библиотеки шанс сломать что-то у 2% use base — смерти подобен.
Потому, что от одного миллиона — это 20000 реквестов "подонки, вы сломали моё приложение". Один ответ от саппорта "сами виноваты" стоит примерно $10. Вот и посчитай, во что выльется одно отдельно взятое счастье Павла Дворкина автору популярной библиотеки.
Поэтому в языке важны средства, позволяющие уменьшить процент недовольных апгрейдом до приемлемого. А в практике вендора библиотеки важно пользоваться этими средствами. О чем я и написал.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Беда в том, что и ты, и Антон, да и не только вы, а многие здесь, относятся к правилам как к чему-то такому, что нарушать нельзя ни в коем случае. Запрещено, и точка. Все равно, что попытка нарушить закон сохранения энергии — того, кто в своих рассуждениях ему противоречит, надо пригвоздить к позорному столбу, вот и все. И если чье-то решение подпадает под некий анти-паттерн, к примеру — анафема, и все.
Беда в том, что антипаттерны в программе многократно усложняют поддержку кода. Пока пишешь программу для себя это может сойти с рук, но когда это коммерческая командная разработка, то это стоит рельных денег, возможно очень болших.
PD>Что же касается меня, то я к ним отношусь как не более чем неким рекомендациям. Им можно следовать, им, наверное, даже лучше следовать, но если есть к тому основание, ими вполне можно пренебречь. И не бояться при этом обвинений в незнании принципов ООП или некошерности в каком бы то ни было ином смысле, или даже в кривизне решения. Просто надо сравнить проигрыш от неследования этим правилам и выигрыш от этого же неследования. Если второе перевешивает — спокойно нарушаем эти правила и посылаем куда угодно критиков. А перевешивает или нет — зависит от задачи и целей.
Проигрыш от наследования от String гораздо больше чем выйгрыш. А наследование от статика просто не нужно, там только синтаксические отличия.
Может адекватные примеры будут?
PD>Кому-то очень важна легкость сопровождения, и ради нее он готов пожертвовать быстродействием, а кому-то (мне) нужно получить максимальное быстродействие любой ценой, потому что все прочие нарушения заказчик мне простит, а вот потерю быстродействия — нет.
А с чего ты взял что применение анти-паттернов приведет к увеличению быстродействия?
Кстаи по теме — override для произвольного метода бъет по JIT оптимизации, также как и не-sealed классы.
PD>А критерием истины, как тут Антон заметил (а впрочем, и до него другие замечали является практика. А поэтому я имею полное основание утверждать, что то, что я говорю, имеет полное право на существование. Потому что я в своей практике все и всяческие каноны нарушал многократно, да еще как нарушал, и ничего — все работает уже много лет, и никто не жалуется, и работает не на 2-3 компьютерах и не в фирме "Рога и копыта"
Про деньги см выше.
PD>А в применении к вопросу, из-за которого сыр-бор разгорелся (sealed классы) — я просто одну простую вещь хочу сказать. Не надо меня от меня защищать. Или по крайней мере дайте мне легальную возможность эту защиту отменить. Да, я могу, если мне разрешить, накосячить с реализацией. Да, это будет плохо. Но могу и не накосячить. А поэтому не принимайте за меня решения, оставьте их мне. Накосячу — сам виноват и буду.
В WinAPI куча недокументированных функций, которые все могут использовать. Это приводит к тому что более новые версии винды должны эмулировать ошибки старых чтобы программы работали. Создатели .NET не хотят пройти по томуже пути.
В этом и разница между писанием приложения и написанием библиотеки. Твой CStringEx ни один здравомыслящий разработчик не будет использовать в библиотеках доступных широкому кругу лиц.
Кроме того string имеет слишком низкоуровневую реализацию, чтобы позволять всем в ней ковыряться.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Ну и т.д. Было бы у меня времени больше — мог бы целый список составить.
Да байта ради, только ты так и не ответил на вопрос, с каких пор кривые реализации левых библиотек стали являться аргументом?
PD> Да только незачем — это настолько обычная практика в MFC, что как-то даже неудобно доказывать ее право на существование.
Наличие кривых реализаций не является аргументом в пользу того, что и дальше так надо делать.
PD>Беда в том, что и ты, и Антон, да и не только вы, а многие здесь, относятся к правилам как к чему-то такому, что нарушать нельзя ни в коем случае.
Какое правило, Павел? Что ты как маленький отмазываешься. Речь здесь ни о каком правиле не идет, мы тебе на пальцах объяснили, почему предложенное тобой решение не является рабочим, не ссылаясь на какие-то там правило, а наглядно расписав все последствия.
Ты же в ответ, кроме "ну другие же так делают", ничего возразить не смог — несерьезно как-то, особенно для преподавателя и практика с большим стажем.
PD> Кому-то очень важна легкость сопровождения, и ради нее он готов пожертвовать быстродействием, а кому-то (мне) нужно получить максимальное быстродействие любой ценой, потому что все прочие нарушения заказчик мне простит, а вот потерю быстродействия — нет.
Причем тут быстродействие?
PD>А в применении к вопросу, из-за которого сыр-бор разгорелся (sealed классы) — я просто одну простую вещь хочу сказать. Не надо меня от меня защищать. Или по крайней мере дайте мне легальную возможность эту защиту отменить. Да, я могу, если мне разрешить, накосячить с реализацией. Да, это будет плохо. Но могу и не накосячить. А поэтому не принимайте за меня решения, оставьте их мне. Накосячу — сам виноват и буду.
Это ты так говоришь, пока не накосячил. А когда накосячишь, винить будешь вовсе не себя, причем так, что только пыль столбом, и самое забавное, что будешь прав.
Проходили уже, разработчики библиотек, они, блин, опытные. Они именно так проектируют не по прихоти, а потому что уже ни раз на эти грабли наступали.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, 4058, Вы писали:
4>>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>>Вот, например класс CStringEx — расширяет стандартный класс CString из MFC
4>>1. System.String в отличие от CString иммутабелен, в частности по этому класс запечатан.
PD>А я-то не знал .
Видимо не знал, если начал проводить аналогии между горе-классом из горе-библиотеки MFC. "С с классами" и ООП очень разные вещи.
PD>Дискуссию, почему он иммутабелен, открывать, надеюсь, не будем, а вот вопрос один есть.
Нет не будем, т.к. эта тема уже перемолота где только можно.
PD>Этот-то класс запечатан, потому что он иммутабелен, ладно, пусть, а вот почему другие, не иммутабельные классы — то запечатаны ?
Это смотря какие... Если идеологически не требуется переопределения поведения, то не грех и запечатать.
Наследование в чистом виде пригодно в ООЯ поддерживающих множественное наследование, если множественное наследование отсутствует, то остается только наследование пригодное для достижение полиморфизма.
Здравствуйте, IB, Вы писали:
IB>Да байта ради, только ты так и не ответил на вопрос, с каких пор кривые реализации левых библиотек стали являться аргументом?
Я тебе их 4 штуки привел. Могу еще привести, времени нет там копаться. Еще раз — такое сплошь и рядом делается в MFC и их приводит сайт, котррый считается одним из наиболее авторитетных источников в плане расширений существующих библиотек. Если ты считаешь все это левым и кривым — это твое право, но я не вижу оснований для таких утверждений.
PD>> Да только незачем — это настолько обычная практика в MFC, что как-то даже неудобно доказывать ее право на существование. IB>Наличие кривых реализаций не является аргументом в пользу того, что и дальше так надо делать.
См. выше. Лично для меня рейтинг этих классов на codeproject является гораздо более серьезным аргументом, чем твои с Антоном рассуждения.
PD>>Беда в том, что и ты, и Антон, да и не только вы, а многие здесь, относятся к правилам как к чему-то такому, что нарушать нельзя ни в коем случае. IB>Какое правило, Павел? Что ты как маленький отмазываешься. Речь здесь ни о каком правиле не идет, мы тебе на пальцах объяснили, почему предложенное тобой решение не является рабочим, не ссылаясь на какие-то там правило, а наглядно расписав все последствия.
Все начинает напоминать разгоаор глухих. Я тебе привожу реальные классы, которые реально используются (судя по тому же рейтингу). а ты мне опять в ответ — это не является рабочим. Эти классы являются рабочим решением или нет ?
IB>Ты же в ответ, кроме "ну другие же так делают", ничего возразить не смог — несерьезно как-то, особенно для преподавателя и практика с большим стажем.
Другие так делают, потому что именно так там принято делать и так правильно делать. Еще раз — это общепринятый там подход.
PD>> Кому-то очень важна легкость сопровождения, и ради нее он готов пожертвовать быстродействием, а кому-то (мне) нужно получить максимальное быстродействие любой ценой, потому что все прочие нарушения заказчик мне простит, а вот потерю быстродействия — нет. IB>Причем тут быстродействие?
Да просто как пример. Легкость сопровождения vs быстродействие. Можно и другие придумать.
PD>>А в применении к вопросу, из-за которого сыр-бор разгорелся (sealed классы) — я просто одну простую вещь хочу сказать. Не надо меня от меня защищать. Или по крайней мере дайте мне легальную возможность эту защиту отменить. Да, я могу, если мне разрешить, накосячить с реализацией. Да, это будет плохо. Но могу и не накосячить. А поэтому не принимайте за меня решения, оставьте их мне. Накосячу — сам виноват и буду. IB>Это ты так говоришь, пока не накосячил. А когда накосячишь, винить будешь вовсе не себя, причем так, что только пыль столбом, и самое забавное, что будешь прав.
А может, предоставишь мне самому решить, кого я буду винить, а ? . Какие у тебя основания утверждать, что буду винить не себя ? Мы лично не знакомы, как я работаю — ты не видел, зачем же такое утверждать ?
Здравствуйте, samius, Вы писали:
S>Здравствуйте, LaPerouse, Вы писали:
LP>>Если бы String создавался только через фабрику и мы бы имели бы возможность сделать String.setCurrentFactoty(myStringFactory), то такое очень даже имело бы смысл.
S>И каждая сторонняя библиотека пыталась бы установить свою фабрику и ломалась бы при работе с чужими фабриками. Нет уж, спасибо
А сторонние библиотеки и не дожны это делать — это дела целевого клиента выбирать реализации, с которым он будет работать. Представь себе такое — я сделал Engine.setRenderer(new DirectXrenderer()), а какой-нибудь SceneGraph переопределил Engine.setRenderer(new OpenGLrenderer()) (техническую невозможность проделать такое опустим).
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Sinclair, Вы писали:
PD>>Ну и т.д. Было бы у меня времени больше — мог бы целый список составить. Да только незачем — это настолько обычная практика в MFC, что как-то даже неудобно доказывать ее право на существование. S>Неудобно ее доказывать, Павел, вовсе не потому, что она "обычная". А потому, что доказательств нету. Весь этот топик наглядно это показывает.
1. Есть классы. Их приводит один из наиболее авторитетных источников — codeproject. Есть рейтинг, он характеризует полезность этого кода для других. 2. Есть твои рассуждения в абстрактном плане. Я предпочитаю аргументы первого рода. Они для меня доказательство. Если тебе нужны иные доказательства — ищи ккие хочешь где хочешь. Мне и этого достаточно. Практика — критерий истины, не ты ли недавно это говорил ?
PD>>Беда в том, что и ты, и Антон, да и не только вы, а многие здесь, относятся к правилам как к чему-то такому, что нарушать нельзя ни в коем случае. Запрещено, и точка. Все равно, что попытка нарушить закон сохранения энергии — того, кто в своих рассуждениях ему противоречит, надо пригвоздить к позорному столбу, вот и все. И если чье-то решение подпадает под некий анти-паттерн, к примеру — анафема, и все.
S>Очередной пассаж с называнием черного белым. S>Поясняю мысль: Нет, Павел, всё как раз наоборот. Мы никак не относимся к правилам как к скрижалям. Мы просто понимаем, зачем придумываются правила, и по каким критериям нужно сравнивать решения.
Тогда ответь на вопрос — можно ли их нарушать и когда это может быть оправданно ?
S>А ты берешь заученные на плохих примерах решения, и не напрягая мысль ни на минуту, твердишь нам "это хорошо, потому что это очевидно хорошо, а кому не очевидно, тот не знает принципов ООП".
Неумно. Я привел реальный код, котрый люди используют. И если он существует и его используют — это хорошо.
S>Вот привел ты два примера. Оба не работают. Не потому, что нарушают какие-то догматические принципы, а потому, что делают код хуже. По объективным критериям: объем и стоимость поддержки.
Нет, я привел 4 примера классов с codeproject и все они, по-видимому и по отзывам других работают. Насчет того, что хуже — а возьми как да сделай лучше тот же CStringEx и попробуй выстави на codeproject. Посмотрим, что выйдет.
S>Павел, я даже допускаю, что в реальной жизни ты не пишешь такую херню, как в примерах с MyDirectory и MyString.IsPalindrome. Наверное, тебе просто трудно придумать удачный пример, где запечатанность реально мешает.
В реальной жизни я вообще предпочитаю виртуальности не использовать — мне даже то ничтожное замедление, что от нее возникает, слишком дорого может обойтись. А вот написать наследника от любого класса без полиморфизма — за милую душу. просто для лучшей организации кода. И доведись мне написать Directory (ну, скажем, на С++) как класс статических методов — спокойно сделал бы наследника с дополнительными методами, если бы не смог почему-то поместить их в исходный класс. Ну а насчет string — у меня нет психологии работы с immutable объектами, поэтому мне с ними лишь мириться приходится.
Придумать иной пример могу, но надо искать, к чему придраться
S>Если же ты реально веришь, что CStringEx хоть в чём-то лучше, чем PalindromManager.IsPalindrome(this string str), то мне тебя жалко.
Дело твое. Я могу лишь одно сказать — CStringEx существует и люди его используют. А StringHelper класса, в котором были бы реализованы те дополнения, которые есть в CStringEx, я не знаю. А практика — критерий истины.
Кстати, на тебе еще один класс — CImageEx.
S>Вот самое что мне нравится в этой дискуссии (как и многих других с тобой), что ты замечательным образом доказываешь правоту своих оппонентов. Ну вот смотри — делается абстрактное заявление "sealed есмь зло, потому что иногда оно может мне помешать". Но когда в течение недели ты не в состоянии привести ни одного примера, где оно реально мешает, посторонний читатель делает совершенно верный вывод: "Раз даже мегаопытный Павел Дворкин не может придумать конкретного примера, значит это действительно практически никогда не нужно. Тогда зачем требовать возможность, которая помогает 1% программистов в 1% их задач, но при этом мешает 90% программистов в 10% их задач?".
Ну насчет примера — я их привел аж 4, из MFC, правда, только ты их видеть не хочешь. А насчет того, что мешает — а в чем, собственно, мешает ? Ну сделал многоопытный и т.д. класс MyDirectory , ну выставил его на всеобщее обозрение — и чем же это кому-то мешает ? Кто их заставляет его использовать ? А если я его не в библиотеку для всеобщего обозрения выставил, а только в своем проекте использую — это уж и вообще никак никому мешать не может, так как о нем никто и знать не будет. У себя в проекте ты уж мне позволь такого наследника сделать , а ? Честное слово — это никому не помешает
S>И еще раз поясню, что заблуждения твои связаны с тем, что ты писал исключительно одноразовый прикладной софт. Вопросы повторного использования тебя не волнуют, равно как и вопросы выполнения каких-либо гарантий.
Без комментариев. Что я писал ,я не обсуждаю. Что касается гарантий — они предельно жесткие, дальше некуда. А вот повторное использование меня, действительно, мало волнует.
S>А вот если ты выпускаешь библиотеку, целевая аудитория которой — миллион программистов, то приходится думать и о том, как будет выпускаться версия 2.0.
Интересно-то как ? Значит, MyDirectory или аналогичное ему (пусть и по иным канонам написанное) с нетерпением ждет миллион программистов. Гм. Надо подумать
S>Это ты за себя можешь сказать "оставьте их мне; сам накосячу — сам виноват и буду". А для вендора библиотеки шанс сломать что-то у 2% use base — смерти подобен. S>Потому, что от одного миллиона — это 20000 реквестов "подонки, вы сломали моё приложение". Один ответ от саппорта "сами виноваты" стоит примерно
$10. Вот и посчитай, во что выльется одно отдельно взятое счастье Павла Дворкина автору популярной библиотеки.
Ладно. Убедил. Не буду я MyDirectory для миллиона программистов выпускать. Дай мне только возможность в своем одноразовом бесгарантийном софте его сделать, и все. Клянусь, я его никому не покажу. Дашь такую возможность ?
Кстати. Не мог бы ты привести пример библиотеки , которой пользуется миллион программистов. Я не .Net имею в виду, а что-нибудь еще. Мне просто интересно знать, какие такие библиотеки существуют .
""
S>Поэтому в языке важны средства, позволяющие уменьшить процент недовольных апгрейдом до приемлемого. А в практике вендора библиотеки важно пользоваться этими средствами. О чем я и написал.
Здравствуйте, LaPerouse, Вы писали:
LP>Здравствуйте, samius, Вы писали:
S>>Здравствуйте, LaPerouse, Вы писали:
LP>>>Если бы String создавался только через фабрику и мы бы имели бы возможность сделать String.setCurrentFactoty(myStringFactory), то такое очень даже имело бы смысл.
S>>И каждая сторонняя библиотека пыталась бы установить свою фабрику и ломалась бы при работе с чужими фабриками. Нет уж, спасибо
LP>А сторонние библиотеки и не дожны это делать — это дела целевого клиента выбирать реализации, с которым он будет работать.
Если бы была глобальная фабрика строк и возможность ее подменять, то уверен, что каждая пятая библиотека ее бы подменяла. Кому-то нужны бы были мутабельные строки, кто-то бы переписал Intern механизмы, а кто-то прикрутил бы ASCII строки. Любителей написать собственную строку слишком много! Дальше это счастье обрастает хучей конвертеров из одного в другое, которые тоже растут из какой-нибудь глобальной фабрики и т.п. Нет уж, меня запечатанный класс String более чем устраивает.
LP>Представь себе такое — я сделал Engine.setRenderer(new DirectXrenderer()), а какой-нибудь SceneGraph переопределил Engine.setRenderer(new OpenGLrenderer()) (техническую невозможность проделать такое опустим).
Если возможность будет, то кто-то непременно ей воспользуется и будут жертвы.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, LaPerouse, Вы писали:
LP>>Здравствуйте, samius, Вы писали:
S>>>Здравствуйте, LaPerouse, Вы писали:
LP>>>>Если бы String создавался только через фабрику и мы бы имели бы возможность сделать String.setCurrentFactoty(myStringFactory), то такое очень даже имело бы смысл.
S>>>И каждая сторонняя библиотека пыталась бы установить свою фабрику и ломалась бы при работе с чужими фабриками. Нет уж, спасибо
LP>>А сторонние библиотеки и не дожны это делать — это дела целевого клиента выбирать реализации, с которым он будет работать. S>Если бы была глобальная фабрика строк и возможность ее подменять, то уверен, что каждая пятая библиотека ее бы подменяла. Кому-то нужны бы были мутабельные строки, кто-то бы переписал Intern механизмы, а кто-то прикрутил бы ASCII строки. Любителей написать собственную строку слишком много! Дальше это счастье обрастает хучей конвертеров из одного в другое, которые тоже растут из какой-нибудь глобальной фабрики и т.п. Нет уж, меня запечатанный класс String более чем устраивает.
Меня тоже. Это лишь ведь пример.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Sinclair, Вы писали:
PD>В реальной жизни я вообще предпочитаю виртуальности не использовать — мне даже то ничтожное замедление, что от нее возникает, слишком дорого может обойтись. А вот написать наследника от любого класса без полиморфизма — за милую душу. просто для лучшей организации кода. И доведись мне написать Directory (ну, скажем, на С++) как класс статических методов — спокойно сделал бы наследника с дополнительными методами, если бы не смог почему-то поместить их в исходный класс. Ну а насчет string — у меня нет психологии работы с immutable объектами, поэтому мне с ними лишь мириться приходится. PD>Придумать иной пример могу, но надо искать, к чему придраться
А зачем наследование от библиотечного класса без полиморфизма? Назови, пожалуйста, хоть одно преимущества. Недостатки очевидны:
1. Пользуясь protected-методами в наследнике вместо контракта, ты можешь нарушить внутреннюю целостность объекта
2. Что хуже всего, появляется зависимость от непубличных методов, что может выйти боком в будущем при изменении их реализации разработчиком библиотеки.
Говоря проще — это есть нарушение инкапсуляции. На эти издержки можно идти, если мы получаем преимущества ввиде полиморфного поведения, но в остуствии таких преимуществ это бесмысленно и вредно.
S>>Если же ты реально веришь, что CStringEx хоть в чём-то лучше, чем PalindromManager.IsPalindrome(this string str), то мне тебя жалко.
PD>Дело твое. Я могу лишь одно сказать — CStringEx существует и люди его используют. А StringHelper класса, в котором были бы реализованы те дополнения, которые есть в CStringEx, я не знаю. А практика — критерий истины.
Люди, привыкшие к такой ублюдочной библиотеке, как MFC, могут выдержать многое. В этом случае никакой это не критерий.
... << RSDN@Home 1.2.0 alpha 4 rev. 1089>>
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я тебе их 4 штуки привел.
Еще раз: с каких пор кривые реализации левых библиотек стали являться аргументом?
PD> Еще раз — такое сплошь и рядом делается в MFC
Еще раз — наличие кривых реализаций не является оправданием для повторения тех же ошибок.
PD>и их приводит сайт, котррый считается одним из наиболее авторитетных источников в плане расширений существующих библиотек.
Кем считается? По моим данным, этот сайт считается сборищем исходников китайских и индусских студентов, которые выкладывают там свои поделки, чтобы иметь строчку в резюме. Собственно, приведенные тобой примеры наглядно это демонстрируют..
PD> Если ты считаешь все это левым и кривым — это твое право, но я не вижу оснований для таких утверждений.
А я вижу. Более того, и я и Антон на пальцах тебе объяснили, откуда берутся эти основания и почему. Ты же, со своей стороны, себя аргументами не утруждаешь, не к лицу это как-то преподавателю.. =)
PD>См. выше. Лично для меня рейтинг этих классов на codeproject является гораздо более серьезным аргументом, чем твои с Антоном рассуждения.
Если мы с Антоном начнем хвастаться своими рейтингами и регалиями, то счет будет совсем не в пользу codeproject, так что лучше не начинай..
PD>Все начинает напоминать разгоаор глухих.
О да, ты соверщенно не слушаешь, что тебе говорят.
PD>Я тебе привожу реальные классы, которые реально используются (судя по тому же рейтингу). а ты мне опять в ответ — это не является рабочим. Эти классы являются рабочим решением или нет ?
Нет. Сейчас я тебе поясню. Как показывает практика, на которую ты очень любишь ссылаться, работать и выполнять требуемый функционал будет любой код, написанный в любом стиле, хоть на чистом ассемблере в одну строчку. И в этом смысле, код на который ты ссылаешься, скорее всего работать будет. Весь вопрос в том, сколько усилий займет реализация, а главное поддержка и модификация. И тут, твоя любимая практика, говорит о том, что мысль о таком подходе из презерватива выпускать нельзя — дешевле будет.
Понимаешь, мне уже давно не интересно просто реализовать функционал или реализовать функционал, чтобы он работал как можно быстрее, это давно пройденый этап. Мне интересно делать решения, которые легко сопровождать и изменять вместе с изменением требований, и как показывает практика, в этом смысле, предложенный тобой подход совершенно не рабочий.
Тебе не хочется подумать хотя бы на шаг вперед, что будет ствоим кодом?
PD>Другие так делают, потому что именно так там принято делать и так правильно делать. Еще раз — это общепринятый там подход.
Во-первых, то что там так принято — это исключительно их проблемы, ктож им доктор?
Во-вторых, это совершенно не означает, что так правильно, скорее даже наоборот.
В третих, насчет общепринятого — смело, но глупо. Это действительно общепринятый подход, как я уже говорил, у студентов, которые месяц назад познакомились с основами ООП и теперь пытаются применить полученные знания на практике. Очень характерный ход, это я тебе как преподаватель говорю..
Ну и, наконец, в четвертых, предлагаю завязать с отсылками к "успешным" сторонним библиотекам в качестве аргументации, если хочешь получить хоть какой-то конструктив.
PD>Да просто как пример. Легкость сопровождения vs быстродействие.
К чему он тут? Какой выигрыш в быстродействии даст твой подход?
PD> Можно и другие придумать.
Давай. Дай хоть одно преимущество, ради которого имело бы смысл гордить ту конструкцию на которой ты упорно настаиваешь.
PD>А может, предоставишь мне самому решить, кого я буду винить, а ? . Какие у тебя основания утверждать, что буду винить не себя ? Мы лично не знакомы, как я работаю — ты не видел, зачем же такое утверждать ?
Я людей знаю, да и "практика говорит"..
Возвращаясь к сути спора — существует множество других способов, которыми можно расширить грамотно написанную библиотеку. Можешь привести хоть один аргумент, почему твой способ лучше и зачем предоставлять такую возможность?
Предупреждаю сразу "все так делают" — не аргумент, надеюсь ты на своих студентов так авторитетом не давишь..
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>1. Есть классы. Их приводит один из наиболее авторитетных источников — codeproject. Есть рейтинг, он характеризует полезность этого кода для других.
Индусам все полезно, они себе в код, что угодно накопипастают (зачастую забывая голову включить).
PD>Неумно. Я привел реальный код, котрый люди используют. И если он существует и его используют — это хорошо.
Здесь очень важно уточнить сферу применения.
В однодневой софтинке? В университетских липовых курсовых/докторских и т.п.?
PD>Нет, я привел 4 примера классов с codeproject и все они, по-видимому и по отзывам других работают.
"Работает" — это пожалуй самое некорректное и невнятное определение качества кода.
Критериев гораздо больше, причем некоторые из них взаимоисключающие.
PD>Насчет того, что хуже — а возьми как да сделай лучше тот же CStringEx и попробуй выстави на codeproject. Посмотрим, что выйдет.
Ну не модно сейчас строки "изобретать", лет 10-15 назад нормально, но никак не сейчас.
Так надежней, так скромней ...
PD>В реальной жизни я вообще предпочитаю виртуальности не использовать — мне даже то ничтожное замедление, что от нее возникает, слишком дорого может обойтись.
И inline-ить не получится, а как-же без этого? Ну если полиморфный вызов дорог, может выбранный ООЯ не подходит для решения задачи?
PD>А StringHelper класса, в котором были бы реализованы те дополнения, которые есть в CStringEx, я не знаю. А практика — критерий истины.
Практика бывает плохая и хорошая, собственно как и теория, и MFC приводить в качестве примера хорошей практики очень сомнительно.
Chrome,
C>Мне кажется, в .Net runtime можно без особых проблем привнести возможность переписать код произвольного метода. C>Любого метода любой managed DLL. Кроме того, любой невиртуальный метод класса можно сделать виртуальным. C>Добавить поля в существующие sealed классы. И много чего еще. C>Нужно это, что бы преодолеть ошибки проектирования существующих библиотек. C>Из минусов вижу некоторые проблемы с безопасностью в trusted environment, но эти проблемы преодолимы. C>Еще возможно, в следующей версии библиотеки автор откажется от поддержки метода, который мы переопределили. Но вероятность этого мала. И я бы пошел на такой риск ради потенциальных преимуществ. C>Почему официальная практика повторного использования кода не движется в этом направлении? C>Зачем проектировщики библиотек заранее гадают, какие возможности понадобится переопределить пользователям их продукта и через раз не угадывают?(Ведь, чем раньше принято решение — тем больше вероятность ошибки).
Такая возможность избыточна в стандартных случаях и явно недостаточна в нестандартных [случаях].
Наиболее перспективно — в рантайме взять AST класса/метода/чего-угодно, поменять его нужным для себя образом и записать либо поверх источника, либо скопировав под именем MyCopy, а затем собственно вызвать. Открывающиеся возможности практически безграничны:
— вставка трейсинга в сторонние (в том числе и стандартные) библиотеки
— исправление глюков, ошибок дизайна в сторонних (в том числе и стандартных) библиотеках
— дополнение сторонних (в том числе и стандартных) классов полезной функциональностью (например, работа с escaped string)
— изоляция метода от левых зависимостей в сторонних (в том числе и стандартных) классах, примерно по принципу Typemock
— горячий фикс без остановки серверов
— ну и много много ещё возможностей
На данный момент реализация подобных возможностей весьма трудоёмка, хотя и возможна через специальные Profiler API (для .net, JVMPI для джавы).
Sinclair,
PD>>А критерием истины, как тут Антон заметил (а впрочем, и до него другие замечали является практика. А поэтому я имею полное основание утверждать, что то, что я говорю, имеет полное право на существование. S>Павел, я даже допускаю, что в реальной жизни ты не пишешь такую херню, как в примерах с MyDirectory и MyString.IsPalindrome. Наверное, тебе просто трудно придумать удачный пример, где запечатанность реально мешает.
Я попробую привести примеры, можно?
1. Автор фреймворка Moq говорит, что запечатанные классы — не рулят. По крайней мере первый пункт железобетонный — запечатанный класс невозможно мОкнуть обычными средствами.
I hate sealed classes!!!
Sealed keyword is by far the most annoying showstopper to extensibility. I hate it so much. I wish there was an FxCop rule that would enforce that:
1 — If a class is sealed, then it *must* implement an interface that extenders can implement to hook custom implementations.
2 — The sealed class cannot be used *anywhere* in an "if (foo is MyDamnSealedClass)" statement. The required interface from 1) must be used instead.
3 — If a method is sealed, the class should be sealed too, or an equivalent method called from the sealed one is provided for inheritors (implementation of the template method pattern). There's no point in providing a non-sealed class where it's most important behavior (say an Execute method in a Command class or something like that) is sealed and there's no way to change its core behavior.
Although the third one is a little bit extreme, the first two are a MUST. Another day I'll tell you where I found a few key such annoying combinations...
2. Как реализовать идею escaped string? Смысл в том, что обычный String передавать нельзя в некоторые места без предварительной "эскепизации", однако в остальных случаях это нормальная строка:
class EscapedString : String { ... }
class UnescapedString : String { ... }
class LoginManager
{
public void Login(EscapedString username, EscapedString password)
{
// затолкать username и password в sql
}
}
Просьба не цепляться к слову sql, здесь могла быть любая обработка или вызов какого-либо интерпретатора.
3. Как добавить к int, double етц информацию о том, что он реализует IAddable, ISubtractable, IDividable, IMultipliable? Чтобы иметь возможность написать:
public class BasicMath<T> where T : IAddable, ISubstractable, IDividable, IMultipliable
{
public T Add(T arg1, T arg2)
{ return arg1 + arg2; }
public T Subtract(T arg1, T arg2)
{ return arg1 — arg2; }
public T Multiply(T arg1, T arg2)
{ return arg1 * arg2; }
public T Divide(T arg1, T arg2)
{ return arg1 / arg2; }
}
Конечно, тут sealed не при чём, тут немного другая проблема. Это больше относится к тому, что неплохо бы иметь больше рукояток
Здравствуйте, IB, Вы писали:
IB>Кем считается? По моим данным, этот сайт считается сборищем исходников китайских и индусских студентов, которые выкладывают там свои поделки, чтобы иметь строчку в резюме. Собственно, приведенные тобой примеры наглядно это демонстрируют..
И все эти люди , в том числе уважаемый SchweinDeBurg, который регулярно выдает [ANN} по этому сайту, используют индуссские поделки ради строчки и т.д.
При таком уровне понимания дискутировать смысла просто нет.
IB>Во-первых, то что там так принято — это исключительно их проблемы, ктож им доктор? IB>Во-вторых, это совершенно не означает, что так правильно, скорее даже наоборот. IB>В третих, насчет общепринятого — смело, но глупо. Это действительно общепринятый подход, как я уже говорил, у студентов, которые месяц назад познакомились с основами ООП и теперь пытаются применить полученные знания на практике. Очень характерный ход, это я тебе как преподаватель говорю..
Предлагаю тебе сделать следующее. Выложи свои рассуждения насчет поделок на codeproject в форум MFC. Посмотрим на реакцию.
. Дискуссию, почему он иммутабелен, открывать, надеюсь, не будем, а вот вопрос один есть.
Мы уже победили, просто это еще не так заметно...
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
