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

BDA>>Во-первых, это бездумная ссылка на авторитетов, которая, как паттерн поведения, устарела еще до Просвещения. Ну, гугл, и что? Нам, современным людям, нужно объяснение, почему это плохо. Объяснения я не увидел.

G>Да, согласен. Я, признаться, думал, что это ты любишь гугл и для тебя это авторитет. Ты говорил про результат и "делом надо заниматься, а не программированием". Вот гугл денег много заработал, дел выгодных много сделал, карманы набил. Я думал, ну раз ты человек бизнеса, то это тебе ближе.

Вы не слышали про культ карго? Это он и есть. Давайте будем слепо поклоняться гугловым гайдлайнам, раз гугл с ними заработал, и мы заработаем. Ну смешно же, честное слово. Если кто-то хочет заработать денег, крайне не рекомендовал бы пытаться сделать это так. Объясню на примере. Допустим, вы видите, что у компании Miscrosoft есть свой R&D-центр. Денег на него тратится — море. Вы думаете: наверное, он очень хорошо окупается. Дай-ка и я открою при своем стартапе из 3 программистов R&D-центр в виде четвертого. Между тем, инсайдеры рассказывали, что ихний центр это идея лично БГ и служит он пенсией для тех, кому лямку тянуть надоело. Он же изначально умных нанимал, да еще натаскивал их потом, а куда они пойдут на свободе? Ну, объедут свет, купят ресторан, а потом? Потом к конкурентам или свой стартап открывать. При ЕГО масштабе и рыночном положении выгоднее было дать им возможность играть в бирюльки и платить, чтобы просто обезвредить. При масштабе «3 программиста, CEO и собака» балласт в виде четвертого может погубить все дело. Вот что бывает, когда гоняешься за авторитетами, а не объяснениями.

>Ну раз это не так, тогда ладно. Стало быть ты тоже инженер и программист. Тогда дам тебе ссылку на подробное объяснение почему пихать все в один класс не рекомендуется. C++ Coding Standards. Chapter 33. Prefer minimal classes to monolithic

Вы определенно издеваетесь. Или по-другому не умеете.

Divide and conquer: Small classes are easier to write, get right, test, and use. They are also more likely to be usable in a variety of situations. Prefer such small classes that embody simple concepts instead of kitchen-sink classes that try to implement many and/or complex concepts (see Items 5 and 6).

Designing fancy large classes is a typical mistake when starting object-oriented design. The prospect of having a class that offers complete and complex functionality in one shot can be quite alluring. However, designing smaller, minimal classes that can be easily combined is an approach that is more successful in practice for systems of any size, for many reasons:

A minimal class embodies one concept at the right level of granularity. A monolithic class is likely to embody several separate concepts, and using one implies dragging the intellectual overhead of all others. (See Items 5 and 11)

A minimal class is easier to comprehend, and more likely to be used and reused.

A minimal class is easier to deploy. A monolithic class must often be deployed as a bulky indivisible unit. For example, a monolithic Matrix class might attempt to implement and deploy exotic functionality such as computing the eigenvalues of a matrixeven when the majority of clients just want simple linear algebra. A better packaging would implement various functional areas as nonmember functions operating on a minimal Matrix type. Then the functional areas can be tested and deployed in separation to the callers who need them. (See Item 44)

Monolithic classes dilute encapsulation. When a class has many member functions that don't need to be members but areand therefore have gratuitous visibility to the class's private implementationthen the class's private data members become nearly as bad as public variables.

Monolithic classes usually result from an attempt to predict and deliver a "complete" solution to a problem; in practice, they virtually never succeed. There's always something more that people wantand something less, for that matter.

Monolithic classes are harder to make correct and error-safe because they often tackle multiple responsibilities. (See Items 5 and 44)

Покажите, как это относится, например, к String::Printf, String::Split, String::ToLower. Это не the right level of granularity? Или это dilutes encapsulation? Или с деплоем проблемы? Короче, завязывайте с джастификационизмом и вскрывайте суть.

BDA>>Во-вторых, нет слова «антипаттерн», вас кто-то обманул. Неявная теория за этим словом стоит такая: есть книжка GoF и там перечислены паттерны.
G>ГОФ вообще тут не причем. Если даже слова такого нет, то понятие такое точно есть. Просто люди называют его по разному. Припарковать машину на железнодорожных путях — это антипатерн.

Я говорю, что за этим словом стоит неразумная теория. А значит слово не имеет права на существование. Что не мешает его употреблять даже мне самому, если проблему я вижу задолго до применения этой неразумной теории, например, как в случае с кастингами.

BDA>>Так вот, про цели и объяснения. Что значит «минимализм»? Ничего лишнего в бинарях? Это C++, он статически линкуется, главное, дайте исходники. Я вас уверяю, что если никто не вызовет String::Split, этот код в конечный продукт не попадет. Ничего лишнего в головах? Ну так он там и так есть, поскольку есть в ECMAScript. Или, может быть, в хайлоудных проектах гугла ни одна универсальная реализация не годится, ибо подправленная реализация даже

G>Ну есть еще SOLID и S это single responsibility. Подробное объяснение есть в гугле. Если с ним конкретно не согласен, можно подискутировать. Я сам согласен с ним и на практике для себя его подтвердил.

Ну, вот это уже по существу. Я утверждаю: форматирование строк (String::Printf) или смена регистра (String::ToLower) это по своему характеру ГОРАЗДО БОЛЕЕ строковые операции, чем std::string::swap. Спрашивается, кто нарушает single responsibility — я или Степанов?

BDA>>Дело не в том, где такого совсем нет. Дело в том, что платят за результат (который сам на 3/4 очковтирательство, но это неважно). И программист, ориентированный на результат, сталкивается с тем, что во всех приличных языках в системной библиотеке есть нужный ему код, а в этом языке — нет. Что делает язык не очень подходящим для использования программистами, ориентированными на результат. О чем и речь.

G>Так а кто запрещает использовать несколько библиотек. Зачем все должно быть в системной. Ведь лучше чтобы все занимались тем, что у них лучше получается. Это как десктопный компьютер. Пользователь может сам подобрать компоненты под задачу.

Затем, что хотя каждый язык и метит в свою нишу (один с уклоном в сторону одних прикладных задач, другой — других), есть базовые вещи, которые встречаются при работе с почти всеми прикладными задачами. Покрытие близко к 100%, хотя я и затрудняюсь указать число. Это строки и контейнеры, например. Поэтому большинство языков и поддерживает работу с ними в системной библиотеке (но так куце, как C++, по-моему, один только C++). В результате избегаются следующие проблемы:

1. Программисту не надо писать свой код для каждого нового проекта либо подключать левую библиотеку прямо с первых же шагов, поскольку базовые вещи в базовой библиотеке не сделаны.
2. Программисту не надо думать про взаимные преобразования, возникающие из-за того в п.1 разные программисты выбирает разные библиотеки. Например, про char*, wchar_t*, LPC(T)STR, OLECHAR*, _bstr_t, CString, std::string, std::wstring, QString... и продолжать могу еще долго.

G>>>Это компенсируется стабильностью. Опытный программист обучается обходить грабли и использует это умение много лет. Да, порог вхождения выше, зато, когда вошел, выходить не надо еще много лет, в отличии от того же дот нета.

BDA>>Перефразаирую: да, дерьмо, но зато они его не исправляли много лет. От себя добавлю: и не собираются.

G>Я не считаю, что STL настолько плох. Если душа к нему не лежит, нужно искать другую работу. Каждому свое.

Спасибо, но я пока лучше выберу другие языки и других людей.

BDA>>Опять антипаттерн. Ну ладно, а какой кастинг не антипаттерн? Только не говорите, что все — они и без указателей нужны, а уж с указателями-то просто must have.

G>92. Avoid using reinterpret_cast и 93. Avoid using static_cast on pointers

А, так значит dynamic_cast<T>(o), который вы пропустили — не «антипаттерн» (что бы это слово ни значило)? Тогда зачем ОН режет глаз? Чтоб жизнь медом не казалась?

G>А может в клауд запустить вижуал студию? Ну там пять узлов, horizontal scaling. Если серьезно, то на работе купили самые современные, дорогие десктопы с SSD и прочими прибамбасами. За антивирусом я уже давно научился следить. Так вот, тормозит даже на топовом железе. Я не спорю если я себе промышленный сервер под стол поставлю, то я не замечу разницы. А вообще тормознутость и прожерливость студии признают даже ее создатели, но разводят руками.

Ну так и сколько пустая студия у вас открывается в секундах?