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

BDA>>>http://rsdn.ru/forum/flame.comp/6063107.1

Автор: 0BD11A0D
Дата: 29.05.15

EP>>Там говорится про "типичный" алгоритм — но если у класса сотни методов то как IDE должна выбрать из них "типичные"?
BDA>Все методы, явно помещеные в класс — типичные. Типичными их делает как раз помещение туда.
То есть, в классе строки будут методы для:
1) Base64-кодирования
2) URL-кодирования
3) escape'а для shell'а
4) escape'а для другого shell'а
5) Санитизации строк для SQL injection'а
6) Случайной перестановки букв
7) Проверки пароля с помощью PBKDF2
8) Приготовления кофе.

BDA>Дура-IDE должна показывать все молча. И, конечно, это авторский замысел, то есть, некая модель программистских представлений о сущностях. Например, регексы в FCL лежат отдельно, хотя ничего не мешало бы... То есть, не надо искать тут закономерностей, это удачное (или не очень) представление авторов кода о типичности.
Вот и надо убрать это кретиническое представление вообще.

BDA>Я тоже много чего видел. Например, площадь Сан-Марко, как мне тут с утра напомнили. Но я же не пишу обо всем об этом, а пишу только о том, что имеет отношение к вопросам и ответам. Вопрос был — «А как например выражается алгоритмическая сложность, список возможных исключений». Я говорю: есть такие примеры и вы можете их найти самостоятельно. Незачем зацикливаться на C++.
Тебе говорят, что твой ООП головного моска, осложнённый intellisense'ом, приводит только к говнокоду.

Интеллисенс — это инструмент, которым надо уметь пользоваться, а не заменять им всё.

BDA>2. А я вижу и объяснил почему.
BDA>3. Я предложил привести пример, чтобы его разобрать, но вместо примера получил общие рассуждения.
Ничерта ты не объяснил.

Тебя уже ткнули носом в твои же какашки. Несколько раз.

Минимальная модель проистекает из фундаментальнейшего принципа дизайна ПО — Single Responsibility Principle. Каждый логический модуль занимается только тем, что ему необходимо и не более.

В случае с классами и ООП правильный дизайн приводит к тому, что имеем небольшой компактный класс, доступ к состоянию которого ведётся через минимальный интерфейс. Этот интерфейс проектируется так, что с его помощью нельзя нарушить инварианты класса.

Всё остальное делается внешним кодом, который гарантированно не может нарушить инварианты, так как просто технически вынужден работать через безопасный интерфейс.

В реальности от этого иногда приходится отступать, но это не повод начинать пихать в класс непонятно что.