Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Я просто имел в виду, что все методы в Яве виртуальные. S>Я просто имел в виду, что это неправда.
PD>>Перечитал. Те, кто используют обычный string — да, должны. Те, кто будут использовать MyString — не должны. Вот напишу свою PalindroManager и в нем будет исключительно MyString использоваться. S>Павел, ты правда не понимаешь, или придуряешься? S>Твоим MyString не пользуется никто. Текстбоксы не возвращают MyString. TextReader не читает MyString из стрима. StringBuilder не собирает MyString. Нет ни одного метода во всем огромном множестве кода, который бы вернул тебе MyString.
Слушай, не придуривайся сам. Из того, что в существующем FW никто с ним работать иначе как со string не будет (еще бы!) вовсе не следует, что в расширении FW его нельзя будет использовать.
S>Твоя библиотека или приложение не будет работать в вакууме. Придется как-то интероперировать с окружающим миром. И ты на полном серъезе предлагаешь только ради проверки на палиндромность порождать новый класс, который потребует предварительной конверсии каждой строки для выполнения проверки?
Какой к богу проверки ? Создаем наследника от TextBox, к примеру. Кладем его на форму. В нем поле MyString Text1. В него считываем из Win32 edit, создавая при этом экземпляр MyString. Проверяем его на палиндром — здесь же, в наследнике TextBox. Все. Во всем остальном он ведет себя как обычный String и в таком виде может быть употреблен где угодно в существующем FW, которому совсем не надо знать, что он MyString. Никакая дополнительная виртуальность здесь не нужна.
S>Какая идея может оправдать этот немыслимый бред? По-моему, никакая.
Что у вас за дурная манера , господа, называть все, с чем вы не согласны, бредом ?
PD>>Я разве утверждаю, что это нельзя? Я не согласен, что это правильно. С идейной, а не технической точки зрения. S>Идея — в том, чтобы не заставлять пользователей твоего метода IsPalindrome заниматься непроизводительной работой. То, на чем ты так упорно настаиваешь, отвратительно сказывается на производительности как программиста, так и программы.
Обоснуй насчет производительности программы на примере моего расширения MyString и твоей Utility. Имей в виду — функция не виртуальная, так что насчет callvirt — не надо.
PD>> Вот в этом твоя, как ты сам выражаешься, трагическая ошибка. Ты все ООП сводишь к полиморфизму. А есть еще просто банальное наследование без всякого полиморфизма вообще, и оно, по твоему мнению, оказывается ерундой. А у него вполне определенный смысл — отнюдь не кастомизация базового класса , а просто логическая организация методов и данных. S>А теперь ты лихорадочно пытаешься придумать еще хоть какие-то аргументы в защиту своего заблуждения. Ок, какая именно логичность появляется от того, что MyDirectory отнаследован от Directory.
А какая логичность в том, что в классе MyDirectory обраны эти методы, а не создано 3 класса, по которым их бы разнесли ? Логичность в том, что класс их объединяет в нечто логически целое — в данном случае (static class) вот и все.
PD>>Вот ответь на вопрос — а зачем в C# вообще static классы ? Инстансов от них не дождешься, это просто набор методов. Почему бы просто внеклассовые функции не разрешить, как в С++ ? Упаковать их в namespace и дело с концом, туда никто не запрещает добавлять. Так нет же, все же в класс их поместили. И правильно. S>И какое отношение этот вопрос имеет к разрешению наслледоваться от класса Directory?
Самое прямое. Если я расширяю класс Directory — я создаю более мощный "Directory". То есть static класс есть логически собранный набор методов для определенной области. Средство организации, так сказать. И поэтому все средства для работы с этой областью должны быть в этом классе, а не где угодно еще. Или в расширенном классе.
Если ты с этим не согласен — тогда зачем вообще этот класс ? Разместить их по namespace и дело с концом. Зачем класс нужен ?
PD>>Так все же был бы один класс! Тогда ответь на вопрос — а почему ? Иными словами, какие идейные соображения движут тобой, когда ты принимаешь решение — быть тут одному классу или нескольким ? Подчеркиваю, речь идет о static классах, так чтт без виртуальных рассуждений, please. S>Еще раз повторяю: совершенно неважно, из каких соображений я бы выбирал набор классов для библиотеки. Их слишком много, чтобы озвучивать их здесь все.
Уход от ответа из-за его отсутствия. А если бы ты реально при изготовлении этого класса с нуля разбил его без всякого смысла и логики на 2 — сочувствую...
S>Вопрос, который здесь обсуждается, касается именно расширения существующей библиотеки. Очевидно, что невозможно раз и навсегда выбрать один правильный набор.
Слова, слова...
S>При расширении путем наследования, которое ты проталкиваешь как навязчивую идею, в любом случае вводится еще один класс. Поэтому поищи другие аргументы в его защиту.
Если ты не понимаешь разницу между введением еще одного класса, не имеющего никакого отношения к данному и созданием наследника, расширяющего возможности данного и лишь подсчитываешь число классов — о чем тогда вообще говорить!
На досуге подумай, что будет, если в классе Directory понадобится много новых методов, причем делать будут их разные люди, и каждый будет добавлять свой sealed класс.
