Какие инструменты и методики хорошо работают?
UML - годнота?
Как не скатиться в ООП-головного мозга?
До какого уровня конкретики стоит доводить проект на бумаге: буквально до набросков реализации или остановиться на описании объектов и их взаимодействия, а остальное уже доводить до ума в процессе имплементации?
Банда четырех
Компилятор и текстовый редактор хорошо работают. Методики -- зависит от предметной области, наверное
Безусловно
Не писать на ООП-языках
Степанов сказал, что реально никто не начинает с классов и объектов, все начинают с алгоритмов. Я доверяю Степанову, он умный мужик, STL придумал как-никак.
Я всё ещё верю, что существуют люди, которые реально сидят и рисуют диаграммки и пишут алгоритмы на "АЛГ НАЧ КОН" перед тем, как запустить IDE. Верю, но никогда их не видел.
Книги Head first - говно, не читай.
>UML - годнота?
Только если ты быстро и грамотно на нем пишешь, для грамотных людей которые могут это быстро понять и дать фидбек, ну или для документации.
>До какого уровня конкретики стоит доводить проект на бумаге
Сколько бумагу не марай, все никогда не всех нюансов не предвидишь
Лично я читал только выше упомянутую "Банда четырех", и методичку курса по ООП, после этого все вопросы по поводу ООП отпали.
>>1602189
главные минусы проседании быстродействие за счет сложной организации программной системы, если меру знать и не городить огороды из патернов, можно элегантно составлять решение задач, не теряя в производительности и сохраняя все плюсы ооп - естественность, понятность, надежность, легкое сопровождение и расширение программы.
Бесполезно читать про это.
Ебать наконец-то появился этот тред. Я искренне не понимаю, почему его ещё не было или нет в закрепе. Подписываюсь на тред. Сам пытаюсь вкатиться в архитектуру.
Работаю в небольшом ит отделе небольшое компании над внутренним CRM проектом. Благо подобие архитектуры дал веб фреймворк с которым мы работаем, но в целом архитектуры нет и код в основном пишется там где видится. Постоянные правки связанные с изменением бизнес логики приводят к перепахиванию значительной части не очень большого, но относительно сложного проекта.
Все осложняется тем, что у нас нет ни senior'ов, ни архитекторов, и просто напросто некому подсказать как и что делать.
Вот сейчас сам пытаюсь понемногу вкатиться в ООП и паттерны и нащупать хоть какую-то почву под ногами.
Причём решаемые задачи нашей системы самые классические:
- расчёт зп
- выставление счетов
- работа с товарами
- склад
И если бы у нас работал хоть сколько-нибудь опытный архитектор, то сложность и объём переработок кода сократилась бы в разы.
>объектному подходу
А что это такое? Если это "называть структуры данных так же, как объекты реального мира", то ООП -- это велосипед, ибо так делали еще в Си.
Кстати, аргумент в пользу ООП "ну реальный мир то из объектов состоит а не из функций)))00)" на мой взгляд дурацкий, ибо ООП это не только объекты, но еще и сообщения между ними. В связи с чем у меня возникает вопрос: что нужно курить, чтобы камни начали обмениваться сообщениями с деревьями, ручьи с облаками и т.д.? В ФП объекты -- это типы, и никаких загадочных сообщений нет, есть морфизмы-стрелки -- это функции (выражения). И примеры преобразований одних объектов в другие в реальном мире есть, например, из льда можно сделать пар, достаточно сильно разогрев его, из муки, яиц, соды и других ингредиентов можно сделать пирог и т.д.
Поэтому ООП-бляди зря себе присваивают т.н. "объектный подход", этим все и так пользуются без ООП.
>называть структуры данных так же, как объекты реального мира
Не структуры данных, а объекты
Не реального мира, а предметной области
>так делали еще в Си
Поподробней можно?
>ООП это не только объекты, но еще и сообщения между ними
Не сообщения, а связь
> В ФП объекты -- это типы
У тебя не может быть типа данных Window, следовательно это не объекты, следовательно твои "объекты" - это примитивные типы данных, если же у тебя полноценные структуры и классы, то это уже не ФП
У нас есть определенное состояние и его мутации. Функциональщина больше подходит для моделирования окружающего мира.
Кстати, было исследование, где в пиндосии ставили эксперименты над студентами. Они куда быстрее врубались в фп, чем другая группа в ООП.
> Функциональщина больше подходит для моделирования окружающего мира.
Вместо того, чтобы просто изменить объект, создаётся его полная копия, но немного изменённая. При этом старая никуда не девается. Так похоже на реальный мир, да.
> Они куда быстрее врубались в фп, чем другая группа в ООП.
Потому что математика головного мозга. Они такие: "как x = x = 1, если x не равно x + 1"
О, запахло старыми добрыми ООП-тредами, как же я траллил тогда, эх, молодость.
ОП, книги нужно читать самые разные, даже сраного Буча, но они ничего не дадут из коробки. Надо пробовать, пытаться, переосмысливать, возвращаться, перечитывать и так 20 лет.
Один из самых надежных признаков дилетанта (или тролля) - вопли на тему превосходства/голимости ООП/ФП, или, как разновидность, развешивание ярлыков "это не ФП"/"это не ООП". Можно и на ассемблере писать ООП, или на C, как подметил >>1603141-кун. Да, сахара не будет, а таблицы виртуальных методов для полиморфизма придется писать врукопашную - но можно. Прошаренный проектировщик вмегда помнит о главной цели: нам надо управлять рождением и/или развитием конкретной сложной системы, и только успех в решении данной задачи является критерием успеха подхода. ООП очень много дал инженерам в этом смысле, и что немаловажно - отрицательного, что сильно повлияло на вектор развития современных языков.
Принадлежность к парадигме определяет то, какими инструментами ты будешь пользоваться при решении определенной проблемы, минимизируя при этом количество кода. В Си можно наверняка сделать и объекты, и монады, и композицию (вообще не факт, но предположим), и потом через них решить задачу, но ты все равно их будешь делать за счет императивных средств вроде прямого управления памятью и т.д. И наоборот, в ФП можно писать императивный код, но прямое обращение к памяти и т.д. ты будешь делать используя средства ФП. В первом случае было бы быстрее (читай -- экономнее в плане количества строк кода) сразу работать с тем, что есть в Си, а во втором случае сразу работать с тем, что дает ФП.
>>1603443
>Потому что математика головного мозга.
Как что-то плохое. Новука та же описывает мир через математические модели. Те новуки, которые не описывают, являются хуитой вроде психоанализа, марксизма и астрологии.
Виталик Л. прав.
ООП скорее про принцип проектирования, который можно реализовать на чём угодно. В принципе можно сказать, что если у тебя потребность писать в ООП стиле даже не на ООП языках с соответствующим оверхедом, то ООП явно оправдан.
Просто эту концепцию, как и массу других, иногда пытаются приткнуть просто, чтобы была, не понимая, какие проблемы ты решаешь, откуда там сложности берутся и как с ними бороться.
ООП из названия видно, что ориентировано на объекты. Вот когда ты в программе имеешь дело с какими-то сложными объектами, со сложным внутренним состоянием, с большим количеством функций, к ним применимых (завязанных на состояние), особенно когда разнородные, но схожие объекты есть, то ООП подход по отношению к ним оправдан.
Но когда религиозники начинают "всё есть объект" и рожают ООП на пустом месте, то там пиздец начинается. Они не решают проблемы проектирования, а создают их.
Что такое объект и методы.
У тебя есть объект, то есть структура данных, какая-то область памяти, где хранятся переменные и указатели, ссылка на описание класса объекта, таблицу виртуальных функций и т.п., тут специфика каждого языка. Метод объекта - это самая обычная функция, куда одним из аргументов передаётся указатель на объект. Эта функция просто берёт указатель на объекта, получает переменные оттуда и что-то с ними делает.
Например в питоне этот указатель даже явно в методах указывается, первый параметр, принято его self называть. Чаще принято неявно его передавать, и в функции этот указатель называется обычно this.
Как было в сишечке. Самый яркий пример - функции для работы с файлами. Там два типа функций было. Более показательный f-вариант
FILE *f = fopen(name, attr);
c = fgetc(f) // прочитать следующий символ из открытого файла
В сущности FILE - это какой-то сложный объект. И во все функции ты первым параметром передаёшь указатель на этот объект.
И так можно реализовывать любые объекты.
Можно и самому наследование поддержать, и виртуальные функции, и другое.
По сути: современные языки мультипарадигмовые, сюда идёт развитие. Они не пытаются выжать максимум из одной парадигмы, а больше базу берут от каждой, которой ты можешь пользоваться. Как в конкретном случае удобнее, так и пользуешься.
Питон, JS - они и немного ООП, но немного, и немного ФП.
Общий тренд сейчас - асинхронные инструменты, их запиливают во все языки, async/await. Полезно знать, но это тоже не панацея даже для асинхронных задач. Просто один из принципов проектирования соответствующего сервисного кода.
Суть ООП - есть объект, некая сущность. Настоящий объект это то, что нельзя скопировать, к нему можно только применить методы. Вот как Window, или структура файла, сокета или чего ещё. Скопировать объект - это целая песня, он же может содержать ссылки на другие объекты, как эксклюзивно, как и шареные между другими объектами. В общем случае скопировать объект невозможно. Вот как в реальном мире, где состояние квантовой частицы скопировать невозможно.
ФП опирается больше на математические идеи, где всё есть какое-то выражение, можно всегда скопировать, сохранить и т.п.
Невозможно применить ФП к настоящим объектам, у них просто недетерминированное состояние. ФП не может быть заменой ООП в реально жизни примерно никогда. Вот из-за этих свойств объекта. Но на самом деле это проблема объектов, а не их сильная сторона. Было бы куда проще, если бы объекты было легко клонировать, сохранять и восстанавливать, пересылать по себе. И вот реально надо проектировать так, чтобы максимально уходить от этого "квантового" свойства объектов, это реально убирает массу проблем и открывает массу возможностей. Но возможно далеко не всегда, а когда возможно, не всегда разумно.
В ООП языках для говноедов, никакой особой идеи нет, это просто надстройка над процедурным программированием, код - это утверждения МЕНЯЮЩИЕ глобальное состояние программы. В языках для людей код - это выражения. Выражения соответствуют математическим объектами и ОБОЗНАЧАЮТ их величины.
Харкнул в ебло этому пролетарию.
>Виталик Л. прав.
Я не он (хотя и работал с одним Виталиком Л. в Авито пару лет назад).
>>1603501
>религиозники начинают "всё есть объект" и рожают ООП на пустом месте, то там пиздец начинается
Люто двачую, особенно этот пиздец проявляется при работе с большими объемами данных (вроде текстовых редакторов) и сложными абстрактными структурами (вроде конечных автоматов в компиляторах). Важно уметь увидеть, где подход на пользу, а где во вред, а не совать его везде. Тут еще проблема в том, чаще всего ООП действительно хорош в прикладных задачах уровня крудошлепства; это порождает ложное убеждение, что он хорош всегда и везде.
1. Твой пик по шаблонам
2. Patterns of Enterprise Application Architecture
3. Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems
>ООП очень много дал инженерам в этом смысле, и что немаловажно - отрицательного, что сильно повлияло на вектор развития современных языков.
По подробнее можно? Я только знаю про DOD когда ООП тормозило кеш на убогом соснольно-соснульном железе:
https://www.youtube.com/watch?v=rX0ItVEVjHc
Там чистая, микросервисы, cqrs es
Что-нибудь где эту херь на практике показывают. От статей пухнет голова как от непонятной теории.
Поэтому от двача нужно отказаться, ну, или заходить раз в месяц, два, после такого текста.
Чел, ООП это альтернатива реальному миру, она не говорит о том, что ООП сделали для объектов реального мира.
>Objects sometimes correspond to things found in the real world
удаляюсь с вашего позволения.
>В связи с чем у меня возникает вопрос: что нужно курить, чтобы камни начали обмениваться сообщениями с деревьями, ручьи с облаками и т.д.?
Ничего курить не нужно, потому что именно так обстоят дела в реальном мире. Звёзды на небе это энергия излучённая в момент Х, которую ты своими рецепторами уловишь и обработаешь к момент Y, причём те картинки что ты увидишь далеко не то что было на самом деле, да и никакого объекта к этому моменту может и не быть, т.е. объект звезда существует только внутри сообщения в твоём мейлбоксе и его свойства сужены до уровня, который твой интерфейс способен обрабатывать.
ООП не дает строгого определения объекта, это открывает огромные возможности для маневрирования. Приводишь в пример очередной костыль-паттерн и в ответ слышишь: КО-КО-КО ЭТО НЕ НАСТОЯЩИЙ ООП. НАСТОЯЩИЙ ООП ЭТО [очередной набор баззвордов вперемешку без какого-либо смысла].
Очень похоже на ситуацию с верунами, которые по разному интерпретируют писания троллей и даунов из прошлых веков.
> Какие книги по проектированию стоит почитать?
Точно не из той серии, что на оппике, где на обложке всякие босоногие долбаебы с отвратительной формой стопы (даже мне, фут-фетишисту, блевать хочется).
Я пытался читать Хавьера Design Patterns .NET. НИАСИЛИЛ, каюсь
> Какие инструменты и методики хорошо работают?
Если ты не Senior Solution Arcitect, то тебе это не нужно. А то забьешь себе голову всякой хуйней и будешь потом оборачивать функцию сложения двух чисел в декоратор, который создается фабрикой через прокси, которая в свою очередь создается билдером а над всем этим Abstract Factory ебнуть, сам не зная зачем, но не зря ж книжку читал
> UML - годнота?
Если твой проект будет иметь 100 000+ сущностей, которые будут распределены по 1000 БД, а бизнес логика такая, что даже будучи распределенной поровну в головы целой армии китайцев не поместится, то да. В остальных случаях практически бесполезна.
> Как не скатиться в ООП-головного мозга?
Ты так говоришь, как будто это что-то плохое
> До какого уровня конкретики стоит доводить проект на бумаге: буквально до набросков реализации или остановиться на описании объектов и их взаимодействия, а остальное уже доводить до ума в процессе имплементации?
Обычно это делается так:
1. Тебе объясняют на пальцах то, чего от тебя хотят
2. Тебе все предельно понятно и ты идешь кодить
3. Начинаешь кодить и чет уже не так все понятно
4. Идешь уточнять, тебе уже не так уверенно отвечают на твои вопросы
5. Ты идешь и рисуешь на бумаге схему, как ты понял, что от тебя хотят и несешь показывать со словами "ЭТО ВЫ БЛЯТЬ ХОТИТЕ?"
6. Тебе говорят "НЕТ, БЛЯТЬ НЕ ЭТО!"
7. Ты говоришь "ТАК НАРИСУЙ БЛЯТЬ КАК НАДО!"
8. Тебе рисуют, вроде все понятно, идешь кодить
9. Возвращаешься на шаг 3
>>не читай.
Конкретно эту рецензировал и рекомендовал Эрих Гамма и какой то второй из банды. Она считается проще и понятнее оригинала. К тому же примеры - на джаве. Опять же надо понимать что хэд фест - это учебник для нубов, а не справочник. Поэтому воды много. В начале первая страница об этом.
>>1602051 (OP)
>>Какие книги по проектированию стоит почитать?
Книги Боба Мартина и Мартина Фаулера наверни.
>Боба Мартина и Мартина Фаулера
Мошенники, которые зарабатывают тем, что пишут свои мутные книжки и выступают на конференциях где рассказывают о своих бредовых идеях. Удивительно, что кто-то ведется на таких говорящих голов, которые никогда и нигде не работали программистами.
>Те новуки, которые не описывают, являются хуитой вроде психоанализа, марксизма и астрологии
Вообще-то марксизм описывает, если мы про марксистскую экономику говорим. С предсказательной силой там беда, но это общая проблема всех экономических и социологических теорий, а математика на месте.
2) Как развивать ООП-мышление? Мне сказали, что я все равно пишу структурным подходом, несмотря на использование классов.
Как бы вы спроектировали элегантно?
Есть класс УниверсальныйРисовательТаблиц (УРТ), который пишет наименование объекта и в столбцах его свойства (разных типов). Есть класс Товар, у него свойства: вес, состав, дата изготовления, срок годности, адрес производителя. УРТ может нарисовать каталог таких товаров. Но в магазине хранится другая структура {Товар, цена, количество} , и УРТ должен нарисовать и список таких записей тоже, причем уже не все свойства Товара надо отобразить, а напимер так: наименование, дата изготовления, вес, цена, количество.
Я думал сделать интерфейс, который передается УРТ, из него УРТ может получить массив названий свойств (строк). И еще сделать в интерфейсе метод GetValue(int tovarId, string propertyName), а в реализации этого метода if (propertyName == "состав") { ... }. Но они же разных типов могут быть. Что делать?
Ну и что что разных типов, у тебя будет отдельная реализация этого интерфейса для товара и никогда её не будет использовать для других типов.
Нормальная у тебя идея - Урт может получать (с помощью сеттера) ноль и более интерфейсов "отдаватель списка интересующих полей", поставленных в соответствие с типом, к которому такой отдаватель надо получать.
Это конечно если не хочется вручную выдирать из товара нужные поля и пихать в урт , я бы сделал вручную
1) Иерархия классов Фигура->СимметричнаяФигура. Надо будет проверять, является ли фигура симметричной. Если является, то кастовать ее к этому типу и отражать. И если у меня нет множественного наследования, я не смогу подобным образом добавить другие свойства.
2) Интерфейсы. Опять надо проверять тип и кастовать. Также для всех Симметричных типов придется накопипастить одинаковую реализацию. Я не знаю как тут не копипастить.
3) Универсальный класс фигуры, в котором есть все свойства всех фигур и методы проверки, реализовано это свойство или нет.
Что лучше, другие варианты?
http://www.aosabook.org/en/index.html
Ты наверное архитектуры больше чем Хелоуворда не продумывал.
А вот пришлось как-то писать с нуля кросплатформенное приложение, читающее сенсоры с разных мат.плат. везде свои стандарты, где-то подключено к чипсету напрямую, где-то к SIO, да и везде свои SIO и чипсеты, где-то данные идут по 8бит, где-то по 16, короче, в линуксе одни методы доступа к аппаратуре, в винде другие, короче, заёб полный с этой стандартизацией, чтобы потом не росло как больное дерево.
Надо сначала продумывать и детально и где-то записывать. Чтоб потом следовали четко документации, а не так: "слушай я тут хуйню придумал, давай её заимплементим, потом доделаем и будем её тоже поддерживать", вот именно на этой стадии проект "размазывается" и начинается возня в болоте.
А также купил на рефакторинг.гуру за полторашку весь камтент, копейки же.
Архитекторов нет, это сверхлюди, которые были до нас. Это великие умы на которых держится Вселенная. Мы только приходим\уходим, чиним\добавляем баги на фундамент залеженный богами.
мимо ФП господин
сейчас есть техлиды, входящие в отделы архитектуры, сам такой
Задачи отдела архитектуры - разбивка и оценка проекта на этапе pre sale, архитектура и выбор основного стека, запуск проекта, передача постоянному техлиду, поддержка техлида на время существования проекта. Как правило дают пол процета-процент доли прибыли проекта.
>>1656154
из UML самая полезная - sequence diagram, разбираешься ли ты в существующей системе или встраиваешь что-то новое
"изучать UML" тебе нахуй не всралось, идешь да рисуешь её на примере. В пикрелейтед OAuth, глянул на диаграму, сразу понятно что к чему.
Диаграму классов рисуют гораздо реже, в основном если заказчик в документации требует.