Программирование


Ответить в тред Ответить в тред

Check this out!
<<
Назад | Вниз | Каталог | Обновить тред | Автообновление
58 2 24

Проектирование ПО Аноним 14/02/20 Птн 20:32:55 16020511
1022150425.jpg (777Кб, 1030x1200)
1030x1200
Какие книги по проектированию стоит почитать?
Какие инструменты и методики хорошо работают?
UML - годнота?
Как не скатиться в ООП-головного мозга?
До какого уровня конкретики стоит доводить проект на бумаге: буквально до набросков реализации или остановиться на описании объектов и их взаимодействия, а остальное уже доводить до ума в процессе имплементации?
Аноним 14/02/20 Птн 20:42:07 16020602
>>1602051 (OP)
Банда четырех
Компилятор и текстовый редактор хорошо работают. Методики -- зависит от предметной области, наверное
Безусловно
Не писать на ООП-языках
Степанов сказал, что реально никто не начинает с классов и объектов, все начинают с алгоритмов. Я доверяю Степанову, он умный мужик, STL придумал как-никак.
Аноним 14/02/20 Птн 21:26:12 16020993
>>1602051 (OP)
Я всё ещё верю, что существуют люди, которые реально сидят и рисуют диаграммки и пишут алгоритмы на "АЛГ НАЧ КОН" перед тем, как запустить IDE. Верю, но никогда их не видел.
Аноним 14/02/20 Птн 21:34:16 16021134
>>1602099

Ну с алгоритмами ты малость перебрал, но вот рисовать диаграммы взаимодействия - вроде как обычная практика.
Аноним 14/02/20 Птн 21:36:13 16021175
>>1602113
Да, рисуют, но прям задрачивают их единицы.
14/02/20 Птн 21:44:42 16021256
14/02/20 Птн 22:46:55 16021667
>2020
>UML
>ООП
14/02/20 Птн 23:03:30 16021728
Аноним 14/02/20 Птн 23:04:38 16021739
>>1602166

А какой хороший курс есть по uml?
(Если мимо будет проходить аноноархитект, то порекомендуй и по bpmn)
Аноним 14/02/20 Птн 23:17:52 160217910
>>1602051 (OP)
>UML - годнота?
Только если ты быстро и грамотно на нем пишешь, для грамотных людей которые могут это быстро понять и дать фидбек, ну или для документации.

>До какого уровня конкретики стоит доводить проект на бумаге
Сколько бумагу не марай, все никогда не всех нюансов не предвидишь
Аноним 14/02/20 Птн 23:26:31 160218311
Что скажите про "Объектно-ориентированный анализ и проектирование" Гради Буча?
Аноним 14/02/20 Птн 23:34:22 160218912
А про ООП все так бугуртят же в основном от того, что решения получаемые им плохо ложатся на современную вычислительную архитектуру? Верно ведь?
Аноним 14/02/20 Птн 23:36:22 160219113
Аноним 14/02/20 Птн 23:47:12 160219814
>>1602183
Лично я читал только выше упомянутую "Банда четырех", и методичку курса по ООП, после этого все вопросы по поводу ООП отпали.

>>1602189
главные минусы проседании быстродействие за счет сложной организации программной системы, если меру знать и не городить огороды из патернов, можно элегантно составлять решение задач, не теряя в производительности и сохраняя все плюсы ооп - естественность, понятность, надежность, легкое сопровождение и расширение программы.
Аноним 15/02/20 Суб 00:22:13 160222015
>>1602198
Под сложностью программной системы можно много чего понимать, и далеко не всё будет ухудшать быстродействие
Аноним 15/02/20 Суб 00:45:36 160223216
>>1602189
Бугуртят и взамен предлагают такую хуиту, что сложно поверить, что они правда так считают.

> плохо ложатся на современную вычислительную архитектуру
Нормально там всё ложится.
Аноним 15/02/20 Суб 05:10:15 160232517
Аноним 15/02/20 Суб 17:49:15 160304818
А есть вообще какие-то альтернативы объектному подходу в проектировании? Декомпозиция задачи, выделение сущностей с их областями ответственности, иерархическая структура - это ведь используется независимо от того, на функциональном или императивном языке ты пишешь. Это просто естественные способы моделирования сложных систем.
Аноним 15/02/20 Суб 17:58:39 160305819
>>1603048
Нет, нету никакой альтернативы. Попытки что-то писать на процедурных или функциональных языках всегда приводят к изобретению "объектного подхода".

> Это просто естественные способы моделирования сложных систем.
This.
Аноним 15/02/20 Суб 18:21:33 160308320
>>1602051 (OP)
Ебать наконец-то появился этот тред. Я искренне не понимаю, почему его ещё не было или нет в закрепе. Подписываюсь на тред. Сам пытаюсь вкатиться в архитектуру.
Работаю в небольшом ит отделе небольшое компании над внутренним CRM проектом. Благо подобие архитектуры дал веб фреймворк с которым мы работаем, но в целом архитектуры нет и код в основном пишется там где видится. Постоянные правки связанные с изменением бизнес логики приводят к перепахиванию значительной части не очень большого, но относительно сложного проекта.
Все осложняется тем, что у нас нет ни senior'ов, ни архитекторов, и просто напросто некому подсказать как и что делать.

Вот сейчас сам пытаюсь понемногу вкатиться в ООП и паттерны и нащупать хоть какую-то почву под ногами.

Причём решаемые задачи нашей системы самые классические:
- расчёт зп
- выставление счетов
- работа с товарами
- склад

И если бы у нас работал хоть сколько-нибудь опытный архитектор, то сложность и объём переработок кода сократилась бы в разы.
Аноним 15/02/20 Суб 18:28:48 160309521
>>1603083
На данный момент читаю книгу для даунов или детей, или детей даунов или детей-даунов на refactoring guru.
Аноним 15/02/20 Суб 18:38:10 160312122
>>1603048
>объектному подходу
А что это такое? Если это "называть структуры данных так же, как объекты реального мира", то ООП -- это велосипед, ибо так делали еще в Си.
Кстати, аргумент в пользу ООП "ну реальный мир то из объектов состоит а не из функций)))00)" на мой взгляд дурацкий, ибо ООП это не только объекты, но еще и сообщения между ними. В связи с чем у меня возникает вопрос: что нужно курить, чтобы камни начали обмениваться сообщениями с деревьями, ручьи с облаками и т.д.? В ФП объекты -- это типы, и никаких загадочных сообщений нет, есть морфизмы-стрелки -- это функции (выражения). И примеры преобразований одних объектов в другие в реальном мире есть, например, из льда можно сделать пар, достаточно сильно разогрев его, из муки, яиц, соды и других ингредиентов можно сделать пирог и т.д.
Поэтому ООП-бляди зря себе присваивают т.н. "объектный подход", этим все и так пользуются без ООП.
Аноним 15/02/20 Суб 18:45:51 160313223
>>1603121
Зато в ООП это получается наиболее естественно, чем в трудно совместимых с реальным миром идеях об иммутабельности.
Аноним 15/02/20 Суб 18:51:13 160313824
>>1603121
>называть структуры данных так же, как объекты реального мира
Не структуры данных, а объекты
Не реального мира, а предметной области

>так делали еще в Си
Поподробней можно?

>ООП это не только объекты, но еще и сообщения между ними
Не сообщения, а связь

> В ФП объекты -- это типы
У тебя не может быть типа данных Window, следовательно это не объекты, следовательно твои "объекты" - это примитивные типы данных, если же у тебя полноценные структуры и классы, то это уже не ФП

Аноним 15/02/20 Суб 18:54:56 160314125
>>1603138
>> так делали еще в Си
> Поподробней можно?
В ООП-языке у тебя класс, в которых поля и методы, обращающиеся к полям.
В сишке у тебя структура с несколькими полями и функции, принимающие первым аргументом эту структуру.

мимо
Аноним 15/02/20 Суб 18:56:49 160314326
>>1603132
ФП бывает не только иммутабельным.
Аноним 15/02/20 Суб 19:00:19 160314827
>>1603138
>Не сообщения, а связь
А связь это что тогда? Очередная неведомая хуйня из мира такого очень похожего на реальный ООП?
Аноним 15/02/20 Суб 19:00:20 160314928
>>1603143
Ага. Называется оно "ООП".
Аноним 15/02/20 Суб 19:14:48 160316329
>>1603148
Нет, связь между объектами это, например, один объект управляет другим
Аноним 15/02/20 Суб 19:45:30 160320030
Аноним 15/02/20 Суб 23:18:52 160341531
ООП - срань.
У нас есть определенное состояние и его мутации. Функциональщина больше подходит для моделирования окружающего мира.
Кстати, было исследование, где в пиндосии ставили эксперименты над студентами. Они куда быстрее врубались в фп, чем другая группа в ООП.
Аноним 16/02/20 Вск 00:10:13 160344332
>>1603415
> Функциональщина больше подходит для моделирования окружающего мира.
Вместо того, чтобы просто изменить объект, создаётся его полная копия, но немного изменённая. При этом старая никуда не девается. Так похоже на реальный мир, да.

> Они куда быстрее врубались в фп, чем другая группа в ООП.
Потому что математика головного мозга. Они такие: "как x = x = 1, если x не равно x + 1"
Аноним 16/02/20 Вск 00:12:50 160344533
>>1602051 (OP)
О, запахло старыми добрыми ООП-тредами, как же я траллил тогда, эх, молодость.

ОП, книги нужно читать самые разные, даже сраного Буча, но они ничего не дадут из коробки. Надо пробовать, пытаться, переосмысливать, возвращаться, перечитывать и так 20 лет.

Один из самых надежных признаков дилетанта (или тролля) - вопли на тему превосходства/голимости ООП/ФП, или, как разновидность, развешивание ярлыков "это не ФП"/"это не ООП". Можно и на ассемблере писать ООП, или на C, как подметил >>1603141-кун. Да, сахара не будет, а таблицы виртуальных методов для полиморфизма придется писать врукопашную - но можно. Прошаренный проектировщик вмегда помнит о главной цели: нам надо управлять рождением и/или развитием конкретной сложной системы, и только успех в решении данной задачи является критерием успеха подхода. ООП очень много дал инженерам в этом смысле, и что немаловажно - отрицательного, что сильно повлияло на вектор развития современных языков.
Аноним 16/02/20 Вск 00:32:38 160345134
>>1603445
Принадлежность к парадигме определяет то, какими инструментами ты будешь пользоваться при решении определенной проблемы, минимизируя при этом количество кода. В Си можно наверняка сделать и объекты, и монады, и композицию (вообще не факт, но предположим), и потом через них решить задачу, но ты все равно их будешь делать за счет императивных средств вроде прямого управления памятью и т.д. И наоборот, в ФП можно писать императивный код, но прямое обращение к памяти и т.д. ты будешь делать используя средства ФП. В первом случае было бы быстрее (читай -- экономнее в плане количества строк кода) сразу работать с тем, что есть в Си, а во втором случае сразу работать с тем, что дает ФП.
>>1603443
>Потому что математика головного мозга.
Как что-то плохое. Новука та же описывает мир через математические модели. Те новуки, которые не описывают, являются хуитой вроде психоанализа, марксизма и астрологии.
Аноним 16/02/20 Вск 00:34:29 160345235
>>1603451
биология не описывает
Аноним 16/02/20 Вск 00:41:22 160345536
>>1603452
Это не совсем так, в некоторых областях биологии широко применяется математика.
Физика тоже не всегда была точной наукой, часть её разделов изначально были описательными.

мимо
Аноним 16/02/20 Вск 01:11:44 160346037
1001001100
16/02/20 Вск 01:25:51 160347138
Аноним 16/02/20 Вск 03:31:35 160350139
>>1603445
Виталик Л. прав.

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

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

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

Но когда религиозники начинают "всё есть объект" и рожают ООП на пустом месте, то там пиздец начинается. Они не решают проблемы проектирования, а создают их.
Аноним 16/02/20 Вск 03:47:07 160350340
>>1603141
Что такое объект и методы.

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

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

Как было в сишечке. Самый яркий пример - функции для работы с файлами. Там два типа функций было. Более показательный f-вариант
FILE *f = fopen(name, attr);
c = fgetc(f) // прочитать следующий символ из открытого файла

В сущности FILE - это какой-то сложный объект. И во все функции ты первым параметром передаёшь указатель на этот объект.

И так можно реализовывать любые объекты.

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

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

Питон, JS - они и немного ООП, но немного, и немного ФП.

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


Аноним 16/02/20 Вск 04:09:13 160350741
Ещё соплей, чуть из серии ООП vs ФП.

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

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

Невозможно применить ФП к настоящим объектам, у них просто недетерминированное состояние. ФП не может быть заменой ООП в реально жизни примерно никогда. Вот из-за этих свойств объекта. Но на самом деле это проблема объектов, а не их сильная сторона. Было бы куда проще, если бы объекты было легко клонировать, сохранять и восстанавливать, пересылать по себе. И вот реально надо проектировать так, чтобы максимально уходить от этого "квантового" свойства объектов, это реально убирает массу проблем и открывает массу возможностей. Но возможно далеко не всегда, а когда возможно, не всегда разумно.



Аноним 16/02/20 Вск 15:12:14 160378142
>>1602051 (OP)
В ООП языках для говноедов, никакой особой идеи нет, это просто надстройка над процедурным программированием, код - это утверждения МЕНЯЮЩИЕ глобальное состояние программы. В языках для людей код - это выражения. Выражения соответствуют математическим объектами и ОБОЗНАЧАЮТ их величины.
Аноним 16/02/20 Вск 15:16:24 160378843
>>1603781
> В языках для людей код - это выражения.
А ещё в языках для людей зарплата - это борщ.
Аноним 16/02/20 Вск 15:59:39 160385944
16/02/20 Вск 16:02:22 160386545
>>1603788
Кто о чём, а РАБотничек на дядю о зарплате.
Аноним 16/02/20 Вск 16:09:31 160388046
>>1603865
Ну точно, борщехлеб.
Аноним 16/02/20 Вск 16:21:55 160390547
5BECB4E9-AA6D-4[...].jpeg (56Кб, 732x566)
732x566
>>1603880
Харкнул в ебло этому пролетарию.
Аноним 16/02/20 Вск 17:43:17 160403348
>>1603501
>Виталик Л. прав.
Я не он (хотя и работал с одним Виталиком Л. в Авито пару лет назад).

>>1603501
>религиозники начинают "всё есть объект" и рожают ООП на пустом месте, то там пиздец начинается
Люто двачую, особенно этот пиздец проявляется при работе с большими объемами данных (вроде текстовых редакторов) и сложными абстрактными структурами (вроде конечных автоматов в компиляторах). Важно уметь увидеть, где подход на пользу, а где во вред, а не совать его везде. Тут еще проблема в том, чаще всего ООП действительно хорош в прикладных задачах уровня крудошлепства; это порождает ложное убеждение, что он хорош всегда и везде.
Аноним 17/02/20 Пнд 00:24:57 160468649
>>1602051 (OP)
1. Твой пик по шаблонам
2. Patterns of Enterprise Application Architecture
3. Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems
Аноним 19/02/20 Срд 09:52:44 160750950
>>1603141
Методы в ООП под капотом работают аналогично сишным функциям, принимающим указатели на структуру. Всегда сркытно первым аргументом идет ссылка на сам объект. В яве так, по-моему.
Аноним 19/02/20 Срд 09:56:32 160751251
>>1603445
>ООП очень много дал инженерам в этом смысле, и что немаловажно - отрицательного, что сильно повлияло на вектор развития современных языков.

По подробнее можно? Я только знаю про DOD когда ООП тормозило кеш на убогом соснольно-соснульном железе:

https://www.youtube.com/watch?v=rX0ItVEVjHc
Аноним 20/02/20 Чтв 21:29:39 160952952
>>1607512
Fragile base class как фундаментальный неустранимый недостаток, к примеру. В итоге современные best practices избегают длинных цепочек наследования, а в некоторых языках наследование реализации вообще недопустимо.
Аноним 20/02/20 Чтв 21:30:57 160953353
>>1607512
>ООП тормозило
ООП не может "тормозить кэш", это может делать компилятор, не умеющий в оптимизацию.
Аноним 20/02/20 Чтв 22:10:30 160959154
>>1609533

Может.
Особенно заметно в плюсах, развесистый ооп вызывает регулярные кэш мисы.
Остальные языки слишком тормозные, что бы это сильно влияло.
Аноним 21/02/20 Птн 10:41:43 160995855
>>1602099
А нахуя их рисовать? Я могу начать за месяц думать над решением задачи, не приступая к написанию кода. Могу долго думать, как это лучше написать. Когда структура более-менее прозрачна, сажусь писать.
Аноним 21/02/20 Птн 17:49:05 161044856
>>1603095
Как называется книжка?
Аноним 21/02/20 Птн 18:21:59 161048357
Аноним 21/02/20 Птн 19:22:39 161053858
>>1603095

А ее сливали? Или купил?
Аноним 22/02/20 Суб 12:49:17 161132059
>>1609591
>развесистый ооп вызывает регулярные кэш мисы
Это делает не ооп, а конпелятор крестов. ООП - это просто способ записывать программу, а как ее выполнять - вопрос совершенно другой. Тот же раст на этапе конпеляции вытворяет такое, что крестам и не снилось.
Настройки X
Ответить в тред X
15000 [S]
Макс объем: 40Mб, макс кол-во файлов: 4
Кликни/брось файл/ctrl-v
Стикеры X
Избранное / Топ тредов