Моя история вынужденного использования паттернов

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Я считаю, что без ООП и паттернов жизни нет. Тем не менее до сих пор можно встретить множество холиваров различной величины о том насколько вредно или полезно ООП.

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

Все резоны в пользу ООП выглядят для начинающего программиста достаточно натянуто, а пробраться сквозь лес интерфейсов и абстрактных классов бывает непросто. Хуже всего то, что действительно объясняющих книг немного. И самая плохая книга которая нереально высоко задирает порог вхождения это самая полезная книга Банды Четырёх о паттернах. Она написана скучным, тоскливым языком с вычурными аккадемическими примерами.

Люди которые ратуют за красивые архитектуры, но при этом объясняют их необходимость на примерах с логерами, авторизациями, кэшем и щедро дают названия классам в виде Foo и Boo делают очень вредное дело. Хотя я и понимаю, что эти люди являются обычно локомативом всего доброго и светлого в программировании. Это очень обидный парадокс.

Хорошо что есть книги такие как Фримен Э. (2 штуки) Паттерны Проектирования. Она послужила и служит истиным озарением для меня при изучении и самое главное практическом использовании паттернов. Я читал книги и посложнее, но не читал полезнее.

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

Изначально, Заказчик сформулировал одну из подзадач примерно так «Мы отправляем документы, написанные на языке клиента, в разные страны. В этих странах свои языки на которых документы могут быть приняты. Необходимо учитывать стоимость перевода и то какой из переводчиков что переводит»

Нет вопросов подумал я и написал первый раз модуль «Переводы» не мудрствуя лукаво и без всяких паттернов

Прошло некоторое время и Заказчик принёс из реального мира следующую новость «Неплохо было бы учитывать тот факт, что брать деньги за один и тот же перевод, который направляется в разные страны — это нехорошо и сильно бросается в глаза»

Я подумал, что это логично и сделал первую прямолинейную оптимизацию модуля «Переводы» по дублированию.

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

Я логично согласился и написал, как мне казалось, максимально сложный алгоритм двойного перевода с оптимизацией по цене.

Если вы думаете, что на этом реальный мир оставил нас в покое, то вы наверное совсем недавно в програмирование.

С небольшим перерывом добавились следующие реальные факты: Документы состоят из частей и некоторые части почти полностью повторяют другие части; У клиента могут быть документы на двух и более языках, один из которых надо «вычитать»; Существуют особые условия в некоторых случаях, например, в некоторых странах документы должны быть переведены на все доступные языки, а в некоторых достаточно одного; Клиент может подождать одного перевода от более дешёвого переводчика и отдать готовый перевод вместе со своими языками... и это ещё не всё, просто я немного устал перечислять.

Если бы вы увидели мой модуль «Переводы» к этому моменту, то основной аргумент противников ООП «работает же без всякого ООП» сильно бы пошатнулся. Алгоритм стал настолько запутанным, что я сам уже с трудом разбирался в нём. И не помогали даже десятки листиков с блок-схемами.

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

И в этот момент произошло чудо озарения.

Я долго был не уверен, что инкапсуляция алгоритма допустима при написании алгоритма. Хотя это же очевидно, даже слова похожие, но я не мог поверить, что отдав объектам на откуп их ответственность можно заменить строгую и однозначную логику моих бесконечных foreach и if else. Но я решился и теперь у меня над головой нимб с background image как заставка в Матрице.

И кстати, я давным давно думал, что делиться своими примерами с кем то бесплатно это дикость, а открытый код в конце концов погубит индустрию — это тоже оказалось неправдой. Делиться это здорово. Вот я и делюсь, несколько упростив код.

Для решения моей самой общей задачи я использовал патерны Стратегия и Наблюдатель (у семьи Фриманов они первые в книге, но это совпадение)

Для начала реализуем интерфейс и инкапсулируем стратегии для различных условий перевода в разных странах

public interface ITranslateBehavior
    {
        bool IsTranslate(StepTranslate stepTranslate, List<languagecomplite> languageList);
    }

Вот так выглядит реализаця базового требования «Один из доступных языков

public class BaseTransalte : ITranslateBehavior
    {
        public bool IsTranslate(StepTranslate stepTranslate, List<languagecomplite> languageList)
        {
            foreach (LanguageComplite curr in languageList)
            {
                if (curr.IdLanguage == stepTranslate.IdToLanguage)
                {
                    curr.Iscomplite = true;
                    curr.Step = stepTranslate;
                    stepTranslate.Rating++;
                    return true;
                }
            }
            return false;
        }
    }

а вот так вариант «Все из доступных»

public class SpecificTransalteRequirement : ITranslateBehavior
    {
        public bool IsTranslate(StepTranslate stepTranslate, List<languagecomplite> languageList)
        {
            foreach (LanguageComplite curr in languageList)
            {
                if (curr.IdLanguage == stepTranslate.IdToLanguage)
                {
                    curr.Iscomplite = true;
                    curr.Step = stepTranslate;
                    stepTranslate.Rating++;
                }
            }
            return (!languageList.Where(x => x.Iscomplite == false).Any());
        }
    }

Вариантов выполнения перевода в зависимости от условий может быть сколько угодно. И теперь для их реализации не потребуется переписывать весь алгоритм. Алгоритма вообще почти не осталось. Нужно будет просто написать новый небольшой класс с новыми требованиями.

StepTranslate — это определённый этап перевода, а List<languagecomplite> — это набор языков с результатами применения этого шага перевода.

public class StepTranslate
    {
        public int IdFromLanguage { get; set; }
        public int IdToLanguage { get; set; }
        public decimal Price { get; set; }
        public int Step { get; set; }
        public bool BeUsed { get; set; }
        public int Rating { get; set; }
    }

public class LanguageComplite
    {
        public int IdLanguage { get; set; }
        public bool Iscomplite { get; set; }
        public StepTranslate Step { get; set; }
    }

Теперь со стратегией перевода можно определятся просто добавляя различные новые классы самых неожиданных желаний реального мира.

Для оповещения частей документа о том что наш переводчик перевёл какую то пару языков будем использовать паттерн Наблюдатель.

Определяем интерфейс для переводчика

public interface ITranslator
    {
        void RegisterParagraph(Paragraf p);
        void RemoveParagraf(Paragraf p);
        void TranslationParagrafs();
    }

Paragraf — Это наша часть документа, которая реализуется вот так

public class Paragraf
    {
        public int IdCountry { get; set; }
        public int IdTypepart { get; set; }
        public ITranslateBehavior translateBehavior;
        public List<languagecomplite> Languages { get; set; }
        public bool transaltedValue = false;
        public Translator translator;

        public Paragraf(Translator translator)
        {
            this.translator = translator;
            //Это подписка на переводы
            this.translator.RegisterParagraph(this);
        }

        public bool PerformIsTranslate(StepTranslate stepTransalte)
        {
            //Это реализация паттерна Стратегия
            return translateBehavior.IsTranslate(stepTransalte, Languages);
        }
    }

В моём виртуальном реальном мире Paragraf объявлен как abstract для того чтобы если в мир переводов каким нибудь образом проникнут другие зависимости поведения я мог бы на них отреагировать. Здесь для простоты я реализую его непосредственно.

И собственно сам переводчик

public class Translator : ITranslator
    {
        private List<paragraf> listParagraf;
        private List<steptranslate> stepTranslate;

        public Translator(List<steptranslate> stepTranslate)
        {
            listParagraf = new List<paragraf>();
            this.stepTranslate = stepTranslate;
        }
        public void RegisterParagraph(Paragraf p)
        {
            listParagraf.Add(p);
        }

        public void RemoveParagraf(Paragraf p)
        {
            listParagraf.Remove(p);
        }

        public void TranslationParagrafs()
        {
            foreach (StepTranslate currentStep in this.stepTranslate.OrderBy(x => x.Step).ThenBy(y => y.Price))
            {
                foreach (Paragraf currentParagraf in this.listParagraf.Where(x => !x.transaltedValue))
                {
                    currentParagraf.transaltedValue = currentParagraf.PerformIsTranslate(currentStep);
                    
                }
            }
        }
    }

Картинки никак чтоли?

Диаграммка классов...

Я несколько упростил код для демонстрации. Убрал оптимизацию по цене и абстракции, и в реальном приложении всё немного сложнее, но в целом достигнутый результат меня радует — код стал понятен любому постороннему человеку, а самое главное он стал понятен мне, и он стал примерно в 50 раз короче.

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

Резюме — есть ситуации когда для написания корректно работающих и легко поддерживаемых программ ООП является единственным выходом. И это почти все ситуации в реальном программировании приложений для реального мира.

Спасибо за внмание.

зы Формализую условное ТЗ

Необходимо составить алгоритм двухступенчатого перевода частей документа на языки (языки стран), допустимые в заданном списке стран с учётом минимальной стоимости всего пакета переводов.

Первоначально документ и все его части могут быть предоставлены на нескольких языках — языках клиента.

Условия при которых считается что документ может быть отправлен в страну могут быть вида
— В стране есть несколько языков и достаточно одного из них;
— В стране несколько языков и все они обязательные;
— Для некоторых частей документа некоторое подмножество языков страны обязательное;
— Для некоторых частей документа достаточным является хотя бы один из языков из подмножества языков страны;

Условия могут менятся. Например, могут появится условия типа
— Для некоторых частей документа достаточным является первод не менее чем на два языка из специального подмножества языков страны

зы Первоначальный заголовок вызвавший неоднозначную реакцию «История о том как я просил 1200, а меня взяли на 2700*»
*заголовок для привлечения внимания

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

*заголовок для привлечения внимания

Куда котиться ДОУ?

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Вы начинаете нарабатывать код для убийцы фейсбука?

Фейсбук же на пыхе, значит и его убийца тоже должен быть на пыхе

Уважаемый аККадемик, выучите для начала русский язык, а то читать сей опус тяжело. ))

ну не всем совесть позволяет пользоватиься нелицензионным мелкомягким оффисом :-)
будем ждать пока на доу появится проверка синтаксисиа и орфографии.

ду ю спик олбански?

У меня украинский дефолтный, так что не поможет. Дело не в грамотности, это просто такой человек, очень возможно, что сам такой же косноязычный и безграмотный. Псевдограммарнацци. Имя им легион. На всех не угадишь.

Это вы ударение не правильно ставите — я имел в виду угАдишь, от слова гАдить

А «исправел» от слова правЕло?

Да и правильно будет «угодишь», если что.

Реальная, сетевая конкуренция всяким там www.grammarly.com/ И недороо.

Да я чё? Я -ничё. :)
Просто, хотя бы в комментариях про грамматику можно было б не допускать очевидных ошибок. Ведь к таким сообщениям двойное внимание граммарнаци. А вообще, как по мне, то главное, чтоб человек хороший был и не писал «лудше» или «лутше».

Успехов Вам!

Взаимно.

по сабжу — это форум. я не статью написал, а топик.

Да я всё это шутя писал. Не принимайте близко к сердцу.

перед тем как сесть за руль автомобиля — желательно почитать правила дорожного движения и узнать об устройстве автомобиля. а перед тем как программировать и особенно проектирвовать системы используя ООП — почитать хотя бы GOF и Фаулера.

К сожалению я этого не знал и всё, начиная с двоичной системы исчисления, придумал сам.

Также было бы интересно узнать что по вашему является не «хотя бы» если там у вас Фаулер и Банда Четырёх?

гоф и фаулер этот как библия, каждый девелопер из мира ооп должен хотя бы их прочитать и оосзнать. а дальше уже в зависимости от области разработки. например я как .net разработчик вэб-приложений, предпочитающий domain driven model, посоветую почитать Дино Эспозито, Джимми Нильсона, Эрика Эванса, Джеймса Коплиена, Джуди Бишопа. Ну и также «Чистый код»
Роберт Мартин, хотя это и не имеет отношения к патернам и проектирвоанию.

Эспозито за какие заслуги затесался? И эти двое —

Джеймса Коплиена, Джуди Бишопа

Я знаю кто это. Просто он мне кажется достаточно примитивным хоть и эксперт с большим опытом. Нет в нём лёгкости, что ли. Типа Магданурова — вроде всё правильно, но как то совсем уже по крестьянски.

эспозито — это архитектурные патерны корпоративных приложений, а аткже asp.net и ajax. Возможно Бишоп более известен в мире java, но и его книгу Design Patterns мрочитатеть не лишне. из 2 сотен книг по архитектуре и дизайну, что есть в электронной коллекции нашей компании, я пока прочитал не более 3 десятков. некоторрые кинигри типа фаулера, еванса или гофа я постоянно отурываю и что-то ищу новое. я привел пример лишь тех авторов, которые больше всего запомнились. Еще мне очень понравилась кни га Стивена Сандерсона, она хоть и специфична (MVC), но там много обобщенных архитектурных и design решений по разработке архитектуре приложения.

Да, Сандерсон тоже молодец. Хотя часто слишком конкретен в выборе технологий и упускает общую концепцию в угоду конкретной библиотеке. Но за его MVC 2 и MVC 3 отдельное спасибо ему.

Я имел в виду, что Эспозито как то прямолинейно пишет. У него типо моего топика, но с поправкой на десятикратный опыт конечно. Он не учитель, он преподаватель.

очень давно, еще до эпохи .Net прочитал хорошую книгу Мейера что-то типа «Object Oriented Software Constructing». Возможно она уже не очень актуальна, но почитать можно. Я окончил институт очень давно, и нам кроме кроме ричи, страутструпа ничего и не преподавали. Современные студенты уже в вузах знакомятся и с гаммой, и с фаулером.

Может быть в столице, но в провинциях досихпор все уныло

Я давно закончил непрограмный ВУЗ — ХАИ.

Честно говоря, я сомневаюсь в адекватности донесения Фаулера. Всё таки это больше искусство которое требует ко всему опыта программной разработки. Хотя знакомить безусловно надо.

а вот про Кериевски с его рефакторингом с использованием паттернов в институте точно упоминать не нужно :-)

Не видел. Отзывы интересные. Надо полистать.

Полистал оглавление — реальная бомба. Надеюсь, потяну хотя бы смысл пока. Спасибо.

сначала программист прочитав гоф, фаулера + (еспозито/сандерса и т.д.) делает как ему кажется правильную систему. Потом после внедерния и эксплутатации ему кажется что он чего то упустил и можно сделать как-то лучше, чтоб поддерживать было проще — и вот тогда берем с полки кериевски :-)

У меня есть предположение, что осознать паттерны с листа может только чистый кодер, такой образец аутичного языковеда без связи с реальным миром, для которого протокол и контракт означают несколько иные вещи чем для большинства людей. Остальным людям, так или иначе связанным с программированием для осознания паттерна нужен контекст — то есть живой кусок собственного кода. Паттерны в отличие от общей парадигмы ООП не имеют ясных аналогий в реальном мире. И если понимать Фабрику как реальную фабрику то можно никогда не перейти на новый уровень а так и остаться на уровне базовой ООП концепции, в которой например наследование или тип имеют очень хорошии аналогии из реальног мира.

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

Я читаю и Фауллера и Банду и Нильсона и Мартина и пару других фамилий, но читаю по мере продвижения. Потому что изначально архитектура и паттерны всё-же слишком абстрактны для понимания. В них есть одна тонкость которую сложно объяснить на пальцах. А если не объяснять то опять скатишься в спаггети только уже спагетти с паттернами. Имхо.

Читайте Фримена, там более разжевано

Замечательная настольная книга. С Бандой я бы ещё долго танцевал вокруг да около. Хотя есть опасность увлечься примитивизмом, конечно. Но остальные надеюсь не дадут расслабиться.

Нет смысла целенаправленно вникать и изучать паттерны. Тем более пробовать каждый заимплементить или применить хоть где-нибудь. Паттерны — это не самоцель, а просто подсказки. Важно знать что они есть и где их найти. А когда возникнет потребность — тогда уже искать подходящий. Поэтому и описаны они так сухо — это справочник. А объяснений и примеров в сети найти можно массу и для всех языков.

Замкнутый круг — не зная голых паттернов не начнёшь чувствовать когда они могут помочь и соответсвенно не узнавешь паттернов. Я практикую степ бай степ — наговнокодил, почитал, вернулся переговнокодил, опять почитал и т д Но рост есть. Уже по крайней мере твёрдо знаю где проблема и куда копать.

Вообще паттерны парадоксальная область человеческих знаний — с одной стороны всё настолько просто насколько может вообще быть, тем более в c#, с другой стороны допустимая сложность реализации парадигмы не имеет границ. Как в биологии — кислота, вода, углерод — бах мамонт получился.

Приятно видеть когда девелопер старается применять «best practices». Не важно что задача не архисложная — хорошее, гибкое и расширяемое решение всегда ценится.
Очень рекомендую написать для этого кода юнит тесты с использованием какой-нибудь мок-библиотеки (например MOQ). Тесты не только позволят проверить код, но так же выявить места где сильная связность мешает изоляции.
Следующим шагом может стать использование Dependency Inversion Container (например Unity). Это позволит собирать требуемую реализацию на основе XML — конфига на рантайме.

Еще одна обратная сторона декомпозиции: глядя только на исходный код (много мелких классов и методов) сложно ухватить всю картину. Обязательно нужны UML диаграммы. Диаграмма классов есть — и это замечательно. Диаграмма взаимодействия или блоксхема помогли бы еще больше. Так же нужды комментарии. Как минимум описание классов и их ответственностей. Выбирать «говорящие» названия для классов и методов — это придет со временем (и с изучением английского).

Доброе слово и кошке приятно.

Тесты и зависимости в процессе, на NUnit и Unity, для MVC соответственно Ninject. С моками пока тишина. XML испоьзую пока только как транспорт для сохранённых процедур и необходимость конфигов пока не ощущаю, кроме двух-трёх стандартных файлов, а значит не понимаю.

Хуже всего с UML диаграммами — такая там свобода что плеваться хочется. Никто не хочет охранять стандарт. В каждой книге написано «Мы используем свой вариант UML немного более свободный для лучшего дизайна» в результате сплошная каша получается. Нет стандарта — нет концепции — нет повсеместного применения. Начинаю рисовать и скатываюсь в своё кунг-фу которое тоже «лучше для дизайна»

Никто не хочет охранять стандарт.
Стандарт не очень важен. Важнее удобство тулов и среды разработки. Если UML оторван от кода — такие диаграммы только лишний балласт. Мне нравится VS 2010 Ultimate — вполне удобная поддержка разработки с помощью диаграмм. Можно делать Model Driven Development, особенно если использовать DSL тулы и T4 генерацию кода.

Я пока на Express, на Ultimate не насобирал ещё.

Слышал об осторожном отношении к кодогенерации на базе диаграмм в VS. Реально работает?

Можно сказать наконец-то работает как надо (с 10 студии). Язык T4 — это полностью открытые файлы, похожие по синтаксису на старый ASP или Razor. Т.е. код теперь генерит не «студия» а именно эти файлы и их можно менять и добавлять свои как угодно.
Model Driven Development — мне очень нравится. Диаграммы и схемы (модели) — это как раз тот более высокий уровень абстракции который стоит над ООП.

DSL еще не на одном коммерческом проекте не применял, но если проект крупный и доменная область сложная то думаю это прекрасный инструмент для архитектора. Т.е. архитектор разрабатывает доменную модель, «язык» и шаблоны кодогенерации. Девелоперы добавляют нужную ручную реализацию в «частичные» классы и пишут тесты.

на Ultimate не насобирал ещё

ISO образ есть на торрентах :)

Разумеется. Но пока нет необходимости. Надо ещё покачать дельту и икроножную.

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

Оффтоп — лучший способ запомнить тригонометрию вывести её всю из единичной окржности несколько раз.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Специально зарегался, потому что увидел что на DOU кто-то не прав.
Во-первых, в IT практически нет «единственных выходов». Любое решение является результатом компромиссов. В том числе и решение использовать объектно-орриентированный подход.

Если бы вы полностью описали задачу, специалисты могли бы подобрать несколько возможных вариантво реализации, и ни один из них не был бы единственно правильным. Они бы имели определенные преимущества и недостатки по некоторым критериям. И если бы один из критериев был «нам нужен готовый прототип сегодня до 15, потому что нужно его демонстрировать совету директоров», то ООП подход бы не подошел, и тем более не был бы единственно правильным. А подход «быстро накидать на форму кнопок и жестко закодить алгоритм в обрабочтике события» — подошел бы.

Во-вторых есть серьезные замечания по реализации.

1. Нет правил именования типов
Видим 4 типа:
* ITranslateBehavior
* BaseTransalte
* SpecificTransalteRequirement

* StepTranslate

Можно ли сказать, в каких зависимостях друг к другу относятся эти классы?
Вот пример из FCL
Stream
BinaryStream
NetworkStream

Encoding

Исходя из нотации можно предположить, что Stream является родительским классом, BinaryStream и NetworkStream — дочерние классы. А Encoding пока не понятно как ко всему этому относится.

Из твоей же нотации я могу предполжоить что BaseTranslate и StepTranslate принадлежат к одному уровню иерархии и наследуются от общего типа. Но это не так, эти классы имеют совершенно другое отношение. А родственные связи между BaseTranslate, SpecificTranslateRequirement и ITranslateBehavior я бы не заподозрил. Чтоб выяснить уровень их отношений, нужно смотреть документацию, Object Browser или исходный код.

2. Метод ITranslateBehavior.IsTranslate. Исходя из названия я предположил что это Pure метод, т.е. метод, который не изменяет внутреннее состояние. Делает какие-то проверки и выдает результат true/false. Примеры из жизни FCL — String.IsNullOrEmpty, Regex.IsMatch. На практике же все совсем не так. Несмотря на то что метод называется как Pure метод, он еще и модифицирует внутреннее состояние объектов, которые в него переданы.

curr.Iscomplite = true;
curr.Step = stepTranslate;

stepTranslate.Rating++;

Если разобраться в исходном коде, можно прийти к выводу, что это как-то связано с процесом принятия решения о том откуда и куда переводить. Хорошо, но мы получаем проблему — вызывающему коду нужно знать детали реализации Behavior, нужно учитывать что он модифицирует переменные передаваемые в программу.
Это могло бы не быть проблемой, если бы из метода было понятно что он не Pure. Например CheckIsTranslateAndModifyState

Вместо этого может быть стоит использовать подход, подобный тому что используется в Roslyn — в метод передается синтаксическое дерево. Дерево доступно только для чтения, и если его нужно модифицировать, метод должен создать копию этого дерева (или его части) и проводить свои манипуляции над копией, оригинал остается незинменным.

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

Спасибо. Справедливые, полезные замечания. А Pure был pure изначально, но потом что-то пошло не так :)

Я только учусь.

С именами туговато по причине слабого английского. Хорошо, что они меня тоже не устраивают. В работающем приложении я чуть чуть исправил, но всё равно не нравится.

Я создаю копии синтаксического дерева в реальном приложении. Но весь код тут явно не поместился бы и смысла в этом не было бы никакого.

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

Возможно тут есть место ещё для какого-нибудь паттерна

Формализовал задачу в постскриптуме в топике

Резюме — есть ситуации когда для написания корректно работающих и легко поддерживаемых программ ООП является единственным выходом.

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

Да и что толку слушать человека который знает на практике только об одной парадигме? Это как врач который всё лечит кровопусканием и проповедует, что это единственный выход.

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

Какие тут ещё могут быть прадигмы я затрудняюсь ответить и было бы полезно если бы вы их озвучили более менее подробно, а не по аббревиатуре и ссылкам на англоязычные статьи.

Собственно говоря ожидание помощи, критики, советов это и было целью написания топика.

Так он же и свалился в макаронный Ад в конце-концов.

... функциональный подход ... быстро привёл ...

Может процедурный подход? Функциональное и процедурное программирование это немного разные вещи.

Я формализовал задание в постскрипте в топике

Да, разумеется процедурный. Функциональный по вики это крутовато вообще-то

Паттерны это хорошо когда в меру

Осторожное заявление, которое встречается во многих книгах по паттернам и в комментариях, но при этом примеров безмерной патернализации не приводится. Подозреваю, потому что их очень мало. Очень много паттернов это ещё и показатель IQ разработчика, который по идее должен бы удерживать от бездумного и повсеместного тыканья.

Паттерны — это хорошо, когда Java

Если нет интерфейсов и статических методов — чуть хуже.

Мне, например, не ясен момент с зарплатой.
Допустим, менеджмент знает состояние рынка труда. Также, прикинув обязанности, которые будет выполнять новый специалист, рассчитали ориентировочную стоимость его работы.
В таком случае, если человек указывает желаемую компенсацию в 2,5 раза меньше, это явный сигнал, что он не готов возложить на себя необходимую ответственность в полной мере.

Либо менеджеры просчитались в своих расчетах, сколько может стоить необходимый спец.

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

Все это инструмены.
Не всегда эффективно использовать ООП. Иногда АОП или ФП (пр.) намного лучше использовать. Зависит от контекста.
Тоже самое и с шаблонами.

Статья в чем-то познавательная.

Я транслирую свой опыт и ощущения. Пока мне кажется, что в языказ типа c# и java глупо плыть против их ООП сущности в которую вбухали столько человеко часов. Возможно, в php или c++ действтельно стоит крепко подумать перед написанием очередного паттерна. Но я знаком только с c# и там этот подход покрывает 99% задач.

в языказ типа c# и java глупо плыть против их ООП
Это да)...а как вам такая формулировка: если данную задачу эффективнее всего решать средствами ООП, то выбор C# или Java на 100% оправдан.

Мне кажется, все таки, исходить нужно от задачи, а не от средства её решения.

Практически не реализуется, хотя и звучит логично. Язык — это 10 лет. Скорее приходится решать только те задачи которые подходят под инструмент.

У этих недобитков ООП сущности, как таковой, и нет. Правда, движуцца в ту сторону (вон уже появились даже анонимныеклассы, хотя метаклассов еще нед), но параллельно намешивают кучу фигни отовсюду.

А ваш опыт и ощущения, по сути своей, смехотворны. Пхать паттерны повсюду не имеет смысла. 99% задач — я хз, зачастую работаете с одним — двумя паттернами и все. Если у вас паттерн на паттерне сидит и паттерном погоняет — у вас что-то очень не так.

Мощно разрулили ). Всё работает всегда, иначе не было бы смысла о чём то вообще говорить. Даже сайты на HTML прекрасно работают. Даже текст можно отразить в броузере.

Вопрос в том будет ли работать если потребуются изменения и сколько эти изменения будут стоит.

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

>Всё работает всегда, иначе не было бы смысла о чём то вообще говорить.

Согласен. Вам говорить пока не имеет смысла.

>Мощно разрулили

Да что мне-то разруливать? Тут юноша, который впервые узнал о мощи паттернов (буде таковая имеецца), толкает речи о том, что его инструмент — самый инструментастый инструмент из всех инструментов, бездумно пхая его во все дыры, а я читаю и познаю, почему украинский синиор получает меньше иностранного джуниора.

Поржал про одиночное программирование и размышления, что с ними связаны. Скажи, а ты хоть когда-нить писал что-нить, что не связано с формошлепством? А то очень легко размышлять о несвязанности кода и гибкости, пока не пробовал писать что-нить серьезнее, чем три веб-формочки и парочки свистоперделок.

>Вначале проекта это было не так очевидно.

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

Блин да как вы ложку то ко рту подносите?!

>Блин да как вы ложку то ко рту подносите?!

Да легко.

Не сливайся с темы и отвечай на мои ответы. А то попердеть в лужу — то ты хорош, а вот отстаивать свою точку зрения не умеешь. Или просто нечего возразить?

А мне-то зачем? Я лучше тут посижу и поржу со школоты с копеечными ЗП. Кстати да, удачный у тебя и годный слив, ибо ничего толком обосновать не можешь.

ну посиди посиди. палец из носа вынь только, а то мозг испортишь.

Тю. Мозг окончательно и бесповоротно испорчен твоей безграмотностью (и грамматической, и программерской). А палец из носа я и так высовываю, когда намайненую соплю собираюсь сожрать.

Все еще уныло, ибо ты так и не способен был выдать ни одного годного ответа. Я требую, чтобы ты ответил на мои ответы. Или кишка у формошлепов нонеча тонка?

для тебя лучший собеседник это время. адьёс, мучачо.

Обосрался и сбежал? Ну не убегай, не надо. Ты такой забавный же. ХОчешь, я тебе конфетку пососать дам? Ты только не прекращай набрасывать.

Я хорошо знаю SQL и как то читал в одной книге про ООП в SQL — этот вариант мне показался очень натянутым, хотя и позволил взглянуть на привычные вещи под другим углом зрения.

АОП используется в связке с ФП или ООП. Или под АОП понимается не аспектно-ориентированное программирование?

Коментар порушує правила спільноти і видалений модераторами.

Редакция ДОУ, припилите, пожалуйста, к тегу pre способность отступы не резать, а то как то действительно код не совсем кошерно смотрится.

Там, по ходу, надо pre писать.

test;
    test2 = test3; // test

Код не виглядає на 2700. Погано відформатований і має граматичні помилки в англійських словах :)

Коментар порушує правила спільноти і видалений модераторами.

Коментар порушує правила спільноти і видалений модераторами.

Пусть это волнует теперь тех кто меня взял на 2700

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

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

Сомнительно. Если бы понял, то привел бы тут не свой код, а xml-конфиг :)

Вы так говорите «свой код» как будто это что-то плохое

Java- программисты, думаю, поняли шутку.

А если серьезно, возвращаясь к теме паттернов:

Я не вижу всей задачи которая перед вами стояла, поэтому не могу судить про эффективность решения. Но у меня такое странно предчувствие, что если бы вы не концентрировались на паттернах, то задача решилась бы куда проще (понятнее/гибче).

Да ну я же уже повторял про вынужденное думанье. Уверяю вас эта задача с определённого уровня в принципе не решается без паттернов. Вся задача описана во вступлении.

шутка в стиле Spring фреймворка =)

так взяли на 2700, после code-review?

Тогда причем история о ООП? Не важно сколько ты технологий знаешь — важно сколько у тебя з.п.

На самом деле, высказывания а — ля «и без ООП работает» принадлежат недалеким менеджерам, которые как огня боятся того, чего не понимают.

Их можно понять.

Понять, не значит простить.

Не надо:

A) Гнать на Книгу Банды Четырёх. Там нормальный язык и вполне адекватные примеры.

B) Забивать гвозди микроскопом. Паттерны, интерфейсы, сто тыщ пяцот уровней бизнес — логики — не лучшем образом сказываются на производительности, а в малом проекте безбожно усложняют код.

Как тут недавно говорил один самовлюблённый, бесполезный, чёрный ящик: «набор вызывающе невежественных утверждений», имхо

А у тебя я вижу батхерд от осознания собственной тупости до сих пор не прошел.

Всегда приветствую конструктивную самокритику.

Ах, ну прошу прощения. Вы правы, даёшь сто тыщ пяцот паттернов в хеллоу ворлд,

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

Если по делу — все эти холивары, ООП vs FP, абстрактные классы vs интерфейсы, быть или не быть паттернам осточертели. Всему своё место и применение. ООП — не панацея, и паттерны не панацея, одни задачи они решать помогают, другие мешают, Так что да, «есть ситуации когда для написания корректно работающих и легко поддерживаемых программ ООП является единственным выходом», но «И это почти все ситуации в реальном программировании приложений для реального мира.», «Я считаю, что без ООП и паттернов жизни нет» — глупость, так как жизнь не ограничевается кругом задач, для которых ООП предпочтительнее.

Ну как встретите такие где не ограничивается, пишите примеры. Будет познавательно.

Просто попробуйте написать простенькую экспертную системму на Шарпе или Джаве, а потом на Клипсе и почуствуйте разницу.

у меня есть свои соображения, но не для здесь и сейчас

И, кстати, заголовок для привлечения внимания — жуткий моветон.

Это ДОУУУУУУУ!!

P.S. Да, да, боян.

Зачем километры и килограмы ненужного кода? В большинстве случаев, 99% подходит www.microsofttranslator.com и его API

Комментировать не читая — это полезная привычка которая экономит много времени.

Так х... поймешь изначально, о чем эта статья.

Алгоритм стал настолько запутанным, что я сам уже с трудом разбирался в нём. И не помогали даже десятки листиков с блок-схемами
Пока не приучишь себя писать комментарии и summary — будешь страдать сам, и кто после тебя твой код попиливать будет, а потом —
он был к этому моменту очень похож на рукотворный Ад
:)
Далее, на ДОУ при нажатии правой мышкой не появляется Go To Definition, поэтому
Для начала реализуем интерфейс
bool IsTranslate(StepTranslate stepTranslate, List<languagecomplite> languageList);
Пардон, это не начало, это какая-то середина конца, или конец середины, или ппц какой-то т.к. для начала нужно и эти классы создать, верно?
Блин, ну время твоих коллег же тоже уважать нужно? ИМХО, писал бы комментарии (ты, или предыдущий разработчик) — не было бы таких извращений. А так, я понял, все это было сделано для того, чтобы приложение не превратилось в Ад, по мере его усложнения (и соответственно, по мере еще большего отсутствия комментариев в коде)
ИМХО, кто игнорирует написание комментариев, и считает, что у другого разработчика есть третий глаз для чтения его кода — будет гореть в Аду :)
код стал понятен любому постороннему человеку
Да ну? :)
и он стал примерно в 50 раз короче
Та пусть он будет хоть в 100 раз длиннее, но разбит на небольшие хорошо документированные функции — и у тебя меньше будут гореть уши
p.s. А воспевание паттернов тут ни к селу, ни к городу, т.к. не ясен профит от их использования в данном контексте. Пока что я понял, что это нужно было для гибкости, т.к. х... поймешь, как оно все до тебя работало. Если так — то свое мнение на этот счет я уже высказал :)

Привычка писать комментарии не дочитав до середины экономит только половину времени. )

Комментарии в коде устаревают сразу после их написания. Тем более в алгоритме который пишется «поживому». Именно в этом и проффит в данном случае от паттерна Стратегия — потребность в комментариях почти отсутствует.

И вообще одно из преимуществ паттернов это птичий язык между разработчиками который сильно упрощает понимание.

Я пишу комментарии. Смысл топика был показать как в самом неожиданном месте где паттерны не предполагались изначально дело дошло до того что без них никак.

А по поводу середины конца и хз — это же одно из отличий ООП от процедурного подхода. Все интерфейсы и классы достаточно равнозначны и какой писать первым определить трудно. Такой же беспорядок в любой книге по паттернам. Нет главного интерфейса или класса с которого всё начинается

Комментарии в коде устаревают сразу после их написания

Стратегия — потребность в комментариях почти отсутствует.

Ну вот для таких индивидуумов и создали правила в соурс контролах, когда если хотя-бы публичные члены документированы не будут — фиг вчекинишь :) Со временем понимаешь, что это — правильно

А сигнатуры устаревают тоже? :) Гугл или MSDN в помощь по тэгу summary (нажать три подряд обратных слеша перед любым членом, особенно функцией, в коде)

Я пишу комментарии

Которые сразу устаревают? :)

и какой писать первым определить трудно

Я не об этом — я о понимании статьи

который сильно упрощает понимание

Упрощает общение, я сказал бы

Тем более в алгоритме который пишется «поживому»

Это как? Типа, как стенографист, с пылу с жару? Даже не продумав? :)

Это как? Типа, как стенографист, с пылу с жару? Даже не продумав? :)

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

Согласен, что для топика была бы не лишней uml диаграмка, но пока не нашёл удобного инструмента бесплатного.

Когда речь идет о реальных приложениях, то они часто падают с грохотом под тяжестью красивой архитектуры, из-за банального отсутствия комментариев в коде.

была бы не лишней uml диаграмка

Мне уже все ясно, в смысле к чему приведет ваш подход :)

пока не нашёл удобного инструмента бесплатного

Если так тянет на извращения — под ultimate студией ставьте visual studio modelling tools :)

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

Я пишу комментарии для себя чтобы ментальную карту настроить. Для других я буду писать понятный код. Стараться во всяком случае.

Я просто оставлю это здесь:
www.ibm.com/...ft10/index.html

www.ibm.com/...ft11/index.html

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

Резюме — есть ситуации когда для написания корректно работающих и легко поддерживаемых программ ООП является единственным выходом. И это почти все ситуации в реальном программировании приложений для реального мира.

Вот как вы определяете почти все? Вы что работали во всез сферах прикладного ПО. Я могу привести с десяток областей, где паттерны будут не нужны и прекрасно укладывают в рамках парадигмы функционального программирования. Так категорично говорить нельзя, ищите дзен...

Я говорю о приложениях для реального мира. Мир математических абстракций для которого , как я понимаю, FP подходит лучше всего, не является частью реального мира, в общепринятом понимании.

И вы во второй раз пытаетесь увести обсуждение в FP vs notFP — я же написал топик для наглядной демонстрации OOP vs notOOP. Всё таки это принципиально разные обсуждения.

Ничего против или за FP я пока не имю поскольку текущих задач писать чистые математические абстракции не стоит.

зы Хотел бы я посмотреть на программиста чей опыт не лежит через практику своих же ошибок. Да и на человека, вообще.

«OOP vs notOOP» это сравнение 2х разных уровней и я буду продолжать уводить дисскуссию в это русло, это все равно что устраивать сравнение assembler vs C.

Почему студент 2 курса решает задачи лучше чем 8 классник? Потому, что обладает разными подходами к решению задачи, о которых 8 классник не знает, у него нет такого уровня абстракции.т.е вы заведомо становитесь со стороны победителей. Однако во всей этой среде есть игрок в виде ФП который проявлял себя еще с далеких 60х годов, начиная с lisp.

Области где ФП проявляет себя адекватнее,чем ООП:
— финансовый сектор (биржевые транзакции), знаю ребят из Бостона, у которых написано все на lisp, c странсляцией кода в специальное железо на FPGA. Там объекты нафик не нужны.
— NLP
— ML
— AI
— Maтематические расчеты (физика и смежная дифференциальная математика )
— high-load для web (в основном на scala или clojure)
— шаблонная генерация для web
— телекоммуникационное ПО (в основм на erlang)
— медицинская обработка изображений (в основном на ML или подобных языках)
— рейтинговые системы, типа mailrank, который полностью написан на haskell благополучно куплен Facebook.

Для того, чтоб понять, что мир не упирается в ООП и процедурное программирование, нужно мыслить в мировых масшатбах, а ведь есть еще и метапрограммирование и DSL, которые тоже решают свои задачи. Сводить все к что-то-vs-что-то потому, что я не видел ничего другого — это по-детски, вы же взрослый человек.

Насчет математики, это та наука, которая лежит в основе любого ПО, для разработчиков она очень часто закрыта большими уровнями абстракции и об этом забывают. Фактически математическим языком можно описать любое явление, в том числе и человеческую деятельность, уже другое дело выразить это просто.

P.S: это все реальный мир, просто он лежит больше в области прототипов или hi-tech или научно-прикладных задач, но требует большей подготовки от программиста.

А по делу что-то?

Я не говорил про middleware, там ООП, самый лучший выбор или игровое ПО. Суть в том, что всему свое место и ни в кого камнями не кидал.

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

Пусть автор выложет код в репозиторий с поставленной задачей и я с радостью перепишу его в функциональном стиле.

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

А vs to vs это с больной головы на здоровую. В моём примере нет места FP никаким боком.

Ваше решение переход от процедурное -> ООП можно заменить на процедурное->ФП, и они будут на одном уровне и их нужно сравнивать.

Нет, математический язык никак не связан ни с какими явлениями и тем более человеческой деятельностью.

Почитайте теорию систем и теорию хаоса....

Почитайте определение математики.

Это бесполезное и глупое препирательство.

Почитайте определение математики.

Матема́тика (от др.-греч. μάθημα — изучение, наука) — наука о структурах, порядке и отношениях (ru.wikipedia.org/...wiki/Математика)

Не сходитсо с:

математический язык никак не связан ни с какими явлениями и тем более человеческой деятельностью.

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

ИМХО, у вас довольно странное представление о метематике и ФП.

Бесполезный спор. Прочитайте вдумчиво что там на вики написано.

=) mathworld.wolfram.com/...athematics.html

“Mathematics is a broad-ranging field of study in which the properties and interactions of idealized objects are examined”

Как вам определение от Стивена Вольфрама? Довольно солидный деятель, кстати определений математики ооочень много...

Хватит дёргать из контекста. Сходите на день своего ВУЗА и спросите у вашего математика как его наука связана с реальным миром.

В свой ВУЗ я уже не скоро попаду =)

А вообще, очень связана, знаете про такую штуку как PageRank? Это была работа на соискание докторской степени у Сергея Брина и Ларри Пейджа и именно эта математическая система легла в основу поискового движка...

Я вам еще раз говорю, что вы ограничиваете реальный мир сильно, а он большой и красочный..

Ох. Математика поставляет абстракции которые могут совпадать с некоторыми явлениями реального мира, большого и красочного. Ничем другим математика не занимается. Прикладная математика может накладывать ограничения на готовые абстракции для того чтобы их можно было применять — в результате получаются алгоритмы типа PageRank.

У меня классическое представление о математике. А представление о ФП я почерпнул из вики.

У меня классическое представление о математике.

Похоже мы читали разных классиков :)

Ну прочитайте тогда внимательно общую вики, а не только начало статьи.

В моём примере нет места FP никаким боком.

Ааа? Вот:

return (!languageList.Where(x => x.Iscomplite == false).Any());

Класс

public class Translator : ITranslator

и метод

public void TranslationParagrafs()

Реализации ложатся в ФП на раз-два. По описанию задачи, похоже, что и вся она вполне подходит для ФП (код даже понятнее получитсо), но надо проверять :)

Это совершенно ге главное. Главное это инкапсуляция алгоритма и селектор текущего перевода вместо размотанного на десять страниц процедурного алгоритма. Плюс возможность расширения алгоритма по требованиям без изменения уже написанного.

>медицинская обработка изображений (в основном на ML или подобных языках)

Со всем согласен, но для обработки изображений классически используют матричные (статистические) языки, типа R. Ну а некоторые критические рутины узкие пишут уже на Asm/С/С++.

Есть знакомый, все писалось на Ocaml, по производительности не уступает С/С++, ко всему язык мультипарадигменный, обрабатывали многослойные изображения с томографов и электронных микроскопов.

Возможно есть приложения на R, я не спорю, но у меня вышеуказанный use case, поэтому добавил в общий список.

Я говорю о приложениях для реального мира.

Гггггггггггггггггг, чисто історія про одного з чотирьох мудреців, які в темряві пощупали слона.

Ви пощупали реальний світ за вухо і узагальнили. Я не поділяю вашу точку зору, бо я щупав за ногу.

Ну так вместо аутичных комментариев сложно написать про ногу-то? А то тут умников с тупейшими комментариями самого общего смысла и без вас хватает.

Я могу привести с десяток областей, где паттерны будут не нужны и прекрасно укладывают в рамках парадигмы функционального программирования.

Примеры в студию!

спасибо за ссылки. интересное чтиво.

Вот на хабре народ переводы запостил:
habrahabr.ru/post/142591
habrahabr.ru/post/142673

Если интересно еще.

*заголовок для привлечения внимания

Куда котиться ДОУ?

История о том как я просил 1200, а меня взяли на 2700*

*заголовок для привлечения внимания

Спсыбо, шо написали первой строкой :)
Тока смыслу нима такое делать, если ваша цель обсудить что-то связанное с ООП.

Когда дочитаю ваш поток сознания отпишусь по теме. Правда, к тому времени, хотелось бы чтобы тему озвучили :)

Имхо, на нынешнем ДОУ есть смысл.

Реальная тема

Моя история вынужденного использования паттернов

На Хабр не думали запостить? Вроде бы негласное правило: технические статьи — туда, а дискуссии о профессии — здесь.

Хабр с кармой и там лемминги вообще жёсткие. Да и интересно здесь по месту. Можно потом клуб огрганизовать любителей воздухоплавания паттернов проектирования

и там лемминги вообще жёсткие

а вы кто — д’Артаньян на белом коне?

Я в хорошем смысле — про леммингов.

Ну не знаю, мне кажется, что на Хабре достаточно много пользователей, которые только-только начинают свою карьеру, и все они с радостью проголосуют за такой топик.

А смысл такое постить на хабре? Там заминусуют такой топик сразу т.к К.О

Ну можно было бы и проверить. Да только там инвайт нужен, карма и ещё что-нибудь. И насчёт КО — так там походу и Фаулера за это же заминусовали бы и Кнутта. Много там минсусовальщиков это факт. Хорошо, что пока на ДОУ можно так вот — без последствий.

Ну, это относительно хорошо, просто ДОУ так аудиторию держат. Просто суть в чем, что это ваше личное озарение (уже второй топик), как явление известно чуть меньше 20 лет, а на хабре боянов не любят.

Кстати, важный аспект которому не учат в вузах, это история ИТ, уже 50 лет, чтоб человек понимал откуда ноги растут и как из «00000101» перешли на уровень стратегий...и иерархию подходов программирования, но это уже тема для отдельного топика....

Суть в том, что мне глубоко наплевать на то, что любят на хабре, а что нет.

Ваш максимализм надеюсь природный, а не маскхалат для отсутствующих знаний. Вы просто не понимаете, что 20 лет назад не было языков для комфортной реализации паттернов, да и Банда четырёх разрадилась только в 1995-ом. И поверьте если бы это всё было баяном то за последние пять лет не издались бы и не переиздались бы пару десятков книг по паттернам и архитектуре.

Я просто люблю досконально изучать предмет со всех сторон, может и максимализм, не знаю =)

Ну, хабр это тоже отдельный социум со своими правилами.

Кстати, по архитектуре вспомнил. Есть такая серия книг, или альманахов не знаю, как их даже назвать: Pattern-Oriented Software Architecture, 4 тома, а недавно 5 вышел. Там по паттернам все, что хочешь есть и что это за явление вообще. GoF нудная тут я с вами согласен.

GoF писали о С++, и как бы в 1992 он уже был, Smalltalk под паттерны хорошо ложится...

Да ну хватить троллить уже. Сами то надеюсь не верите в точ то 20 лет назад можно было на паттернах архитектуру строить реальную. За POSA спасибо, посмотрю.

Тут хоть когда-то добавят кнопку «Поржал»?

Ну можно уже в подпись поставить, наверное.

Функционала «подпись» у них тоже нет :)

Оу. Какие глубокие у нас знания.

>Вы просто не понимаете, что 20 лет назад не было языков для комфортной реализации паттернов, да и Банда четырёх разрадилась только в 1995-ом.

Smalltalk, Objective-C — это из чистых ООП — языков. Инструменты, до которых тем, которыми вы пользуетесь сегодня, еще далеко.

А ведь есть еще Lisp (за счет возможности созадния сложных синтаксических конструкций и макронадстроек), не забываем и С, на котором вполне можно пользовать ООП — парадигму и прочие-прочие. Ну про разные адовы смеси, типа С++ и Python я вообще молчу.

Підписатись на коментарі