как спроектировать....

Robert C. Martin - Clean Architecture: A Craftsman’s Guide to Software Structure and Design

И много, много опыта. Можно ещё Brown, Wilson - The Architecture of Open Source Applications почитать.

мимо.

grokking-the-system-design-interview

Это про то как интервью проходить. Там нет ничего общего с реальным system design.

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

ну т.е. есть например вот такая штука: https://www.educative.io/courses/grokking-the-system-design-interview

Прикольно. А есть такое в тексте и бесплатно?

А у них и есть в тексте)

Videos are holding you back. The average video tutorial is spoken at 150 words per minute, while you can read at 250. That‘s why our courses are text-based.

Хорошая попытка оправдать тупую экономию)

Гради Буч «Объектно-ориентированное проектирование»?

Ну ок, впервые заплачу за курсы, посмотрим что это такое :)

На мой взгляд самая лучшая книга о проектировании ПО - Г. Майерс «Надёжность программного обеспечения», в СССР издавалось в 1980 году.

Расскажи потом тут.

Гради Буч «Объектно-ориентированное проектирование»?

Щас тебя говном заплюют: ООП это не модно и не молодёжно.

например как сделать CAD?

Чувак, ты FreeCAD видел? Никто в опенсорце не знает, как сделать CAD, это знание по крохам созревает вот уже третий десяток лет.

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

Потому и не делают, что не знают что и как.

Видеотуториалы на тему программирования - для даунов. Никакая это не экономия, а нежелание иметь такую целевую аудиторию.

Компания которая занимается обучением целенаправленно завышает порог вхождения?))

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

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

Моё поведение их маркетологам пофиг, я всё равно ни на какие платные курсы (да и на бесплатные думаю тоже) никогда не пойду.

Но ты уже записался в адепты их методов и уже в авангарде доказываешь как они правы)

На Z-Library есть.

На Z-Library есть.

это кто? линк?

или например как правильно делать плагины в мире Java?

Вообще плагины лучше всего делать в отдельных процессах для любого языка (из мне известных). Это позволяет:

1. Не падать, когда падает плагин. А перезапустить плагин.

2. Часто есть возможность зарезать права плагина так, чтобы он чихнуть не мог. Ну если говорить про классический юникс, можно запустить его от nobody. Если про OpenBSD, то сделать всякие pledge. Если про Linux, там вообще куча вариантов, в которых я сам особо не разбираюсь.

3. Можно установить приоритеты плагина по CPU, I/O, а также установить лимиты по RAM.

Это всё по сути использование штатных возможностей ОС. Теперь что касается Java. Поскольку VM это такая маленькая недо-ОС, то некоторые её возможности позволяют реализовывать подобные ограничения и в рамках одного процесса, но, конечно, с оговорками.

1. Не падать. В целом в Java это делается с помощью try .. catch, всё, что может упасть, это исключение. Ну в идеале. На практике можно через unsafe нагадить куда-нибудь, можно через native код упасть, можно System.exit дёрнуть… В общем для типовых случаев работает.

2. Вообще в Java есть понятие Security Manager. Который позволяет в теории ограничить права плагину и запретить ему пользоваться, например, I/O и даже гранулярно дать доступ к каким-то файлам. К сожалению на практике оно работает не так хорошо, как хотелось бы. Во-первых вся эта система напоминает дуршлаг и когда ей пользовались в большом масштабе, то дыры там находили чуть ли не быстрей, чем латали. Во-вторых он уже deprecated и в будущих версиях его выпилят, так что вот так вот.

3. Тут JVM, к сожалению, сосёт причмокивая. Ничего подобного лимитам для отдельных модулей в JVM нет и не было. И не планируется. И если CPU или I/O обычно не представляют проблемы, то отжирание памяти это проблема. И когда твоя программа отжирает гигабайты из-за кривого плагина, это неприятно.

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

Прикольно. А есть такое в тексте и бесплатно?

хз, я задался вопросом «а что есть еще прикольного», но чет пока безрезультатно :(

Линки на пиратский контент не приветствуются. Если тебе нужно, сможешь найти.

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

Гугл? А вообще, всё проектирование сводится к правильному подбору ключевых слов. Для классов это существительные, для функций это глаголы. Еще можно использовать reverse dictionary по типу https://www.onelook.com/reverse-dictionary.shtml?s=vector%20to%20bitmap для выявления ключевых слов.

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

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

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

Есть хороший список на 50 пунктов «вредные советы программисту», типа как делать не надо, не могу найти, там все антипаттерны перечислены

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

проектирование это не только семантика

Всё остальное вторично. Если ты не правильно подобрал ключевые слова, то всё проектирование пойдёт по одному месту.

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

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

это стратегия формошлепов, из за этого они думают что DRY это про одинаковый код.

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

Всё остальное вторично. Если ты не правильно подобрал ключевые слова, то всё проектирование пойдёт по одному месту.

что вторично? правильное проведение границ в проекте и контроль за распространением изменений по коду с подачи акторов вторичны?

Да. Ты хочешь ынтырпрайз со 100500 [s]индусами[/s] макаками. Это вторично для инди разработчика.

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

Вот отличная статья Анатолия Шалыто, зав. каф. ИТМО: http://is.ifmo.ru/main/article_ap.pdf . Внутри есть ссылки для дальнейшего изучения.