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

PD>Слушай, не придуривайся сам. Из того, что в существующем FW никто с ним работать иначе как со string не будет (еще бы!) вовсе не следует, что в расширении FW его нельзя будет использовать.
То есть, чтобы посчитать полиндром ты предлагаешь расширить FW, причем в двух местах? Я кажется понимаю, кто здесь придуривается..

PD>Какой к богу проверки ? Создаем наследника от TextBox, к примеру. Кладем его на форму. В нем поле MyString Text1. В него считываем из Win32 edit, создавая при этом экземпляр MyString. Проверяем его на палиндром — здесь же, в наследнике TextBox. Все.
Иными словами, у тебя появился контрол, который ты можешь переиспользовать только с определенным типом строк, и ни с чем другим он работать уже не сможет, зашил логику проверки в UI, что является грубейшей ошибкой, так как ни протестировать толком, ни переиспользовать эту логику так же не получится, ну и финальный гвоздь в монолитность своего приложения ты забил, когда завязался на конкретную реализацию TextBox.
Примерно так проектируют приложение люди познакомившиеся с основами ООП по книжкам, примерно месяц назад и теперь активно спешащие применить все новые фенечки на практике..

PD>Что у вас за дурная манера , господа, называть все, с чем вы не согласны, бредом ?
Мы с этим не просто не согласны, мы знаем, что так делать нельзя и даже пытаемся тебе объяснить почему, но очевидно бесполезно... =)

PD> Логичность в том, что класс их объединяет в нечто логически целое — в данном случае (static class) вот и все.
Объеденить в "логически целое" можно кучей других способов, почему они тебя не устраивают?

PD>Самое прямое. Если я расширяю класс Directory — я создаю более мощный "Directory". То есть static класс есть логически собранный набор методов для определенной области.
Только пользоваться нормально им не получится, как тебе уже показал Антон.

PD>Слова, слова...
Это не слова, это суровая практика. Вот что по этому поводу пишет Меерс:

...
If you reflect a bit and are honest with yourself, you'll admit that you have this alleged inconsistency with all the nontrivial classes you use, because no class has every function desired by every client. Every client adds at least a few convenience functions of their own, and these functions are always non-members. C++ programers are used to this, and they think nothing of it. Some calls use member syntax, and some use non-member syntax. People just look up which syntax is appropriate for the functions they want to call, then they call them. Life goes on. It goes on especially in the STL portion of the Standard C++ library, where some algorithms are member functions (e.g., size), some are non-member functions (e.g., unique), and some are both (e.g., find). Nobody blinks. Not even you.

PD>Если ты не понимаешь разницу между введением еще одного класса, не имеющего никакого отношения к данному и созданием наследника, расширяющего возможности данного и лишь подсчитываешь число классов — о чем тогда вообще говорить!
Мы-то как раз очень хорошо понимаем разницу и все ее последствия.