Банда четырех
Компилятор и текстовый редактор хорошо работают. Методики -- зависит от предметной области, наверное
Безусловно
Не писать на ООП-языках
Степанов сказал, что реально никто не начинает с классов и объектов, все начинают с алгоритмов. Я доверяю Степанову, он умный мужик, STL придумал как-никак.
Я всё ещё верю, что существуют люди, которые реально сидят и рисуют диаграммки и пишут алгоритмы на "АЛГ НАЧ КОН" перед тем, как запустить IDE. Верю, но никогда их не видел.
Ну с алгоритмами ты малость перебрал, но вот рисовать диаграммы взаимодействия - вроде как обычная практика.
Да, рисуют, но прям задрачивают их единицы.
Книги Head first - говно, не читай.
>2020
>UML
>ООП
>UML
>ООП
>>ООП
ФП, да?
А какой хороший курс есть по uml?
(Если мимо будет проходить аноноархитект, то порекомендуй и по bpmn)
>UML - годнота?
Только если ты быстро и грамотно на нем пишешь, для грамотных людей которые могут это быстро понять и дать фидбек, ну или для документации.
>До какого уровня конкретики стоит доводить проект на бумаге
Сколько бумагу не марай, все никогда не всех нюансов не предвидишь
Что скажите про "Объектно-ориентированный анализ и проектирование" Гради Буча?
А про ООП все так бугуртят же в основном от того, что решения получаемые им плохо ложатся на современную вычислительную архитектуру? Верно ведь?
Нет, не поэтому.
Лично я читал только выше упомянутую "Банда четырех", и методичку курса по ООП, после этого все вопросы по поводу ООП отпали.
главные минусы проседании быстродействие за счет сложной организации программной системы, если меру знать и не городить огороды из патернов, можно элегантно составлять решение задач, не теряя в производительности и сохраняя все плюсы ооп - естественность, понятность, надежность, легкое сопровождение и расширение программы.
Под сложностью программной системы можно много чего понимать, и далеко не всё будет ухудшать быстродействие
Бугуртят и взамен предлагают такую хуиту, что сложно поверить, что они правда так считают.
> плохо ложатся на современную вычислительную архитектуру
Нормально там всё ложится.
Бесполезно читать про это.
А есть вообще какие-то альтернативы объектному подходу в проектировании? Декомпозиция задачи, выделение сущностей с их областями ответственности, иерархическая структура - это ведь используется независимо от того, на функциональном или императивном языке ты пишешь. Это просто естественные способы моделирования сложных систем.
Нет, нету никакой альтернативы. Попытки что-то писать на процедурных или функциональных языках всегда приводят к изобретению "объектного подхода".
> Это просто естественные способы моделирования сложных систем.
This.
Ебать наконец-то появился этот тред. Я искренне не понимаю, почему его ещё не было или нет в закрепе. Подписываюсь на тред. Сам пытаюсь вкатиться в архитектуру.
Работаю в небольшом ит отделе небольшое компании над внутренним CRM проектом. Благо подобие архитектуры дал веб фреймворк с которым мы работаем, но в целом архитектуры нет и код в основном пишется там где видится. Постоянные правки связанные с изменением бизнес логики приводят к перепахиванию значительной части не очень большого, но относительно сложного проекта.
Все осложняется тем, что у нас нет ни senior'ов, ни архитекторов, и просто напросто некому подсказать как и что делать.
Вот сейчас сам пытаюсь понемногу вкатиться в ООП и паттерны и нащупать хоть какую-то почву под ногами.
Причём решаемые задачи нашей системы самые классические:
- расчёт зп
- выставление счетов
- работа с товарами
- склад
И если бы у нас работал хоть сколько-нибудь опытный архитектор, то сложность и объём переработок кода сократилась бы в разы.
На данный момент читаю книгу для даунов или детей, или детей даунов или детей-даунов на refactoring guru.
>объектному подходу
А что это такое? Если это "называть структуры данных так же, как объекты реального мира", то ООП -- это велосипед, ибо так делали еще в Си.
Кстати, аргумент в пользу ООП "ну реальный мир то из объектов состоит а не из функций)))00)" на мой взгляд дурацкий, ибо ООП это не только объекты, но еще и сообщения между ними. В связи с чем у меня возникает вопрос: что нужно курить, чтобы камни начали обмениваться сообщениями с деревьями, ручьи с облаками и т.д.? В ФП объекты -- это типы, и никаких загадочных сообщений нет, есть морфизмы-стрелки -- это функции (выражения). И примеры преобразований одних объектов в другие в реальном мире есть, например, из льда можно сделать пар, достаточно сильно разогрев его, из муки, яиц, соды и других ингредиентов можно сделать пирог и т.д.
Поэтому ООП-бляди зря себе присваивают т.н. "объектный подход", этим все и так пользуются без ООП.
Зато в ООП это получается наиболее естественно, чем в трудно совместимых с реальным миром идеях об иммутабельности.
>называть структуры данных так же, как объекты реального мира
Не структуры данных, а объекты
Не реального мира, а предметной области
>так делали еще в Си
Поподробней можно?
>ООП это не только объекты, но еще и сообщения между ними
Не сообщения, а связь
> В ФП объекты -- это типы
У тебя не может быть типа данных Window, следовательно это не объекты, следовательно твои "объекты" - это примитивные типы данных, если же у тебя полноценные структуры и классы, то это уже не ФП
>> так делали еще в Си
> Поподробней можно?
В ООП-языке у тебя класс, в которых поля и методы, обращающиеся к полям.
В сишке у тебя структура с несколькими полями и функции, принимающие первым аргументом эту структуру.
мимо
ФП бывает не только иммутабельным.
>Не сообщения, а связь
А связь это что тогда? Очередная неведомая хуйня из мира такого очень похожего на реальный ООП?
Ага. Называется оно "ООП".
Нет, связь между объектами это, например, один объект управляет другим
Нет.
ООП - срань.
У нас есть определенное состояние и его мутации. Функциональщина больше подходит для моделирования окружающего мира.
Кстати, было исследование, где в пиндосии ставили эксперименты над студентами. Они куда быстрее врубались в фп, чем другая группа в ООП.
У нас есть определенное состояние и его мутации. Функциональщина больше подходит для моделирования окружающего мира.
Кстати, было исследование, где в пиндосии ставили эксперименты над студентами. Они куда быстрее врубались в фп, чем другая группа в ООП.
> Функциональщина больше подходит для моделирования окружающего мира.
Вместо того, чтобы просто изменить объект, создаётся его полная копия, но немного изменённая. При этом старая никуда не девается. Так похоже на реальный мир, да.
> Они куда быстрее врубались в фп, чем другая группа в ООП.
Потому что математика головного мозга. Они такие: "как x = x = 1, если x не равно x + 1"
О, запахло старыми добрыми ООП-тредами, как же я траллил тогда, эх, молодость.
ОП, книги нужно читать самые разные, даже сраного Буча, но они ничего не дадут из коробки. Надо пробовать, пытаться, переосмысливать, возвращаться, перечитывать и так 20 лет.
Один из самых надежных признаков дилетанта (или тролля) - вопли на тему превосходства/голимости ООП/ФП, или, как разновидность, развешивание ярлыков "это не ФП"/"это не ООП". Можно и на ассемблере писать ООП, или на C, как подметил -кун. Да, сахара не будет, а таблицы виртуальных методов для полиморфизма придется писать врукопашную - но можно. Прошаренный проектировщик вмегда помнит о главной цели: нам надо управлять рождением и/или развитием конкретной сложной системы, и только успех в решении данной задачи является критерием успеха подхода. ООП очень много дал инженерам в этом смысле, и что немаловажно - отрицательного, что сильно повлияло на вектор развития современных языков.
Принадлежность к парадигме определяет то, какими инструментами ты будешь пользоваться при решении определенной проблемы, минимизируя при этом количество кода. В Си можно наверняка сделать и объекты, и монады, и композицию (вообще не факт, но предположим), и потом через них решить задачу, но ты все равно их будешь делать за счет императивных средств вроде прямого управления памятью и т.д. И наоборот, в ФП можно писать императивный код, но прямое обращение к памяти и т.д. ты будешь делать используя средства ФП. В первом случае было бы быстрее (читай -- экономнее в плане количества строк кода) сразу работать с тем, что есть в Си, а во втором случае сразу работать с тем, что дает ФП.
>Потому что математика головного мозга.
Как что-то плохое. Новука та же описывает мир через математические модели. Те новуки, которые не описывают, являются хуитой вроде психоанализа, марксизма и астрологии.
биология не описывает
Это не совсем так, в некоторых областях биологии широко применяется математика.
Физика тоже не всегда была точной наукой, часть её разделов изначально были описательными.
мимо
1001001100
100001001.
Виталик Л. прав.
ООП скорее про принцип проектирования, который можно реализовать на чём угодно. В принципе можно сказать, что если у тебя потребность писать в ООП стиле даже не на ООП языках с соответствующим оверхедом, то ООП явно оправдан.
Просто эту концепцию, как и массу других, иногда пытаются приткнуть просто, чтобы была, не понимая, какие проблемы ты решаешь, откуда там сложности берутся и как с ними бороться.
ООП из названия видно, что ориентировано на объекты. Вот когда ты в программе имеешь дело с какими-то сложными объектами, со сложным внутренним состоянием, с большим количеством функций, к ним применимых (завязанных на состояние), особенно когда разнородные, но схожие объекты есть, то ООП подход по отношению к ним оправдан.
Но когда религиозники начинают "всё есть объект" и рожают ООП на пустом месте, то там пиздец начинается. Они не решают проблемы проектирования, а создают их.
Что такое объект и методы.
У тебя есть объект, то есть структура данных, какая-то область памяти, где хранятся переменные и указатели, ссылка на описание класса объекта, таблицу виртуальных функций и т.п., тут специфика каждого языка. Метод объекта - это самая обычная функция, куда одним из аргументов передаётся указатель на объект. Эта функция просто берёт указатель на объекта, получает переменные оттуда и что-то с ними делает.
Например в питоне этот указатель даже явно в методах указывается, первый параметр, принято его self называть. Чаще принято неявно его передавать, и в функции этот указатель называется обычно this.
Как было в сишечке. Самый яркий пример - функции для работы с файлами. Там два типа функций было. Более показательный f-вариант
FILE *f = fopen(name, attr);
c = fgetc(f) // прочитать следующий символ из открытого файла
В сущности FILE - это какой-то сложный объект. И во все функции ты первым параметром передаёшь указатель на этот объект.
И так можно реализовывать любые объекты.
Можно и самому наследование поддержать, и виртуальные функции, и другое.
По сути: современные языки мультипарадигмовые, сюда идёт развитие. Они не пытаются выжать максимум из одной парадигмы, а больше базу берут от каждой, которой ты можешь пользоваться. Как в конкретном случае удобнее, так и пользуешься.
Питон, JS - они и немного ООП, но немного, и немного ФП.
Общий тренд сейчас - асинхронные инструменты, их запиливают во все языки, async/await. Полезно знать, но это тоже не панацея даже для асинхронных задач. Просто один из принципов проектирования соответствующего сервисного кода.
Ещё соплей, чуть из серии ООП vs ФП.
Суть ООП - есть объект, некая сущность. Настоящий объект это то, что нельзя скопировать, к нему можно только применить методы. Вот как Window, или структура файла, сокета или чего ещё. Скопировать объект - это целая песня, он же может содержать ссылки на другие объекты, как эксклюзивно, как и шареные между другими объектами. В общем случае скопировать объект невозможно. Вот как в реальном мире, где состояние квантовой частицы скопировать невозможно.
ФП опирается больше на математические идеи, где всё есть какое-то выражение, можно всегда скопировать, сохранить и т.п.
Невозможно применить ФП к настоящим объектам, у них просто недетерминированное состояние. ФП не может быть заменой ООП в реально жизни примерно никогда. Вот из-за этих свойств объекта. Но на самом деле это проблема объектов, а не их сильная сторона. Было бы куда проще, если бы объекты было легко клонировать, сохранять и восстанавливать, пересылать по себе. И вот реально надо проектировать так, чтобы максимально уходить от этого "квантового" свойства объектов, это реально убирает массу проблем и открывает массу возможностей. Но возможно далеко не всегда, а когда возможно, не всегда разумно.
Суть ООП - есть объект, некая сущность. Настоящий объект это то, что нельзя скопировать, к нему можно только применить методы. Вот как Window, или структура файла, сокета или чего ещё. Скопировать объект - это целая песня, он же может содержать ссылки на другие объекты, как эксклюзивно, как и шареные между другими объектами. В общем случае скопировать объект невозможно. Вот как в реальном мире, где состояние квантовой частицы скопировать невозможно.
ФП опирается больше на математические идеи, где всё есть какое-то выражение, можно всегда скопировать, сохранить и т.п.
Невозможно применить ФП к настоящим объектам, у них просто недетерминированное состояние. ФП не может быть заменой ООП в реально жизни примерно никогда. Вот из-за этих свойств объекта. Но на самом деле это проблема объектов, а не их сильная сторона. Было бы куда проще, если бы объекты было легко клонировать, сохранять и восстанавливать, пересылать по себе. И вот реально надо проектировать так, чтобы максимально уходить от этого "квантового" свойства объектов, это реально убирает массу проблем и открывает массу возможностей. Но возможно далеко не всегда, а когда возможно, не всегда разумно.
В ООП языках для говноедов, никакой особой идеи нет, это просто надстройка над процедурным программированием, код - это утверждения МЕНЯЮЩИЕ глобальное состояние программы. В языках для людей код - это выражения. Выражения соответствуют математическим объектами и ОБОЗНАЧАЮТ их величины.
> В языках для людей код - это выражения.
А ещё в языках для людей зарплата - это борщ.
Содомит
Кто о чём, а РАБотничек на дядю о зарплате.
Ну точно, борщехлеб.
Харкнул в ебло этому пролетарию.
>Виталик Л. прав.
Я не он (хотя и работал с одним Виталиком Л. в Авито пару лет назад).
>религиозники начинают "всё есть объект" и рожают ООП на пустом месте, то там пиздец начинается
Люто двачую, особенно этот пиздец проявляется при работе с большими объемами данных (вроде текстовых редакторов) и сложными абстрактными структурами (вроде конечных автоматов в компиляторах). Важно уметь увидеть, где подход на пользу, а где во вред, а не совать его везде. Тут еще проблема в том, чаще всего ООП действительно хорош в прикладных задачах уровня крудошлепства; это порождает ложное убеждение, что он хорош всегда и везде.
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
Fragile base class как фундаментальный неустранимый недостаток, к примеру. В итоге современные best practices избегают длинных цепочек наследования, а в некоторых языках наследование реализации вообще недопустимо.
>ООП тормозило
ООП не может "тормозить кэш", это может делать компилятор, не умеющий в оптимизацию.
Может.
Особенно заметно в плюсах, развесистый ооп вызывает регулярные кэш мисы.
Остальные языки слишком тормозные, что бы это сильно влияло.
А нахуя их рисовать? Я могу начать за месяц думать над решением задачи, не приступая к написанию кода. Могу долго думать, как это лучше написать. Когда структура более-менее прозрачна, сажусь писать.
Как называется книжка?
Спасибо, почитаю
А ее сливали? Или купил?
>развесистый ооп вызывает регулярные кэш мисы
Это делает не ооп, а конпелятор крестов. ООП - это просто способ записывать программу, а как ее выполнять - вопрос совершенно другой. Тот же раст на этапе конпеляции вытворяет такое, что крестам и не снилось.
А накидайте курсов бесплатных/которые есть на торрентах по архитектуре.
Там чистая, микросервисы, cqrs es
Что-нибудь где эту херь на практике показывают. От статей пухнет голова как от непонятной теории.
Там чистая, микросервисы, cqrs es
Что-нибудь где эту херь на практике показывают. От статей пухнет голова как от непонятной теории.
Бамп
хорошая книга, стоит читать.
Поэтому от двача нужно отказаться, ну, или заходить раз в месяц, два, после такого текста.
Чел, ООП это альтернатива реальному миру, она не говорит о том, что ООП сделали для объектов реального мира.
>Objects sometimes correspond to things found in the real world
удаляюсь с вашего позволения.
>В связи с чем у меня возникает вопрос: что нужно курить, чтобы камни начали обмениваться сообщениями с деревьями, ручьи с облаками и т.д.?
Ничего курить не нужно, потому что именно так обстоят дела в реальном мире. Звёзды на небе это энергия излучённая в момент Х, которую ты своими рецепторами уловишь и обработаешь к момент Y, причём те картинки что ты увидишь далеко не то что было на самом деле, да и никакого объекта к этому моменту может и не быть, т.е. объект звезда существует только внутри сообщения в твоём мейлбоксе и его свойства сужены до уровня, который твой интерфейс способен обрабатывать.
С ОО-даунами бесполезно спорить и что-то им доказывать.
ООП не дает строгого определения объекта, это открывает огромные возможности для маневрирования. Приводишь в пример очередной костыль-паттерн и в ответ слышишь: КО-КО-КО ЭТО НЕ НАСТОЯЩИЙ ООП. НАСТОЯЩИЙ ООП ЭТО [очередной набор баззвордов вперемешку без какого-либо смысла].
Очень похоже на ситуацию с верунами, которые по разному интерпретируют писания троллей и даунов из прошлых веков.
ООП не дает строгого определения объекта, это открывает огромные возможности для маневрирования. Приводишь в пример очередной костыль-паттерн и в ответ слышишь: КО-КО-КО ЭТО НЕ НАСТОЯЩИЙ ООП. НАСТОЯЩИЙ ООП ЭТО [очередной набор баззвордов вперемешку без какого-либо смысла].
Очень похоже на ситуацию с верунами, которые по разному интерпретируют писания троллей и даунов из прошлых веков.
Абстрактный объект на то и абстрактный, что о нём известен только некий набор свойств. Собственно, математика изучением объектов, о которых почти ничего не известно.
test
Как перестать быть программистом и устроиться наконец архитектором? Есть какой роадмап?
>2020
>архитектор
Разве ещё остались распилочные конторы где есть эта маняпозиция из 90х?
Люся большая контора?
О, как раз хотел спросить про книгу с ОП-пика. Оно еще актуально, или устаревшее говно мамонта?
Паттерны не устаревают.
Сама корзинка говно по сравнению с бандой четырех, но почему бы и нет.
> Какие книги по проектированию стоит почитать?
Точно не из той серии, что на оппике, где на обложке всякие босоногие долбаебы с отвратительной формой стопы (даже мне, фут-фетишисту, блевать хочется).
Я пытался читать Хавьера Design Patterns .NET. НИАСИЛИЛ, каюсь
> Какие инструменты и методики хорошо работают?
Если ты не Senior Solution Arcitect, то тебе это не нужно. А то забьешь себе голову всякой хуйней и будешь потом оборачивать функцию сложения двух чисел в декоратор, который создается фабрикой через прокси, которая в свою очередь создается билдером а над всем этим Abstract Factory ебнуть, сам не зная зачем, но не зря ж книжку читал
> UML - годнота?
Если твой проект будет иметь 100 000+ сущностей, которые будут распределены по 1000 БД, а бизнес логика такая, что даже будучи распределенной поровну в головы целой армии китайцев не поместится, то да. В остальных случаях практически бесполезна.
> Как не скатиться в ООП-головного мозга?
Ты так говоришь, как будто это что-то плохое
> До какого уровня конкретики стоит доводить проект на бумаге: буквально до набросков реализации или остановиться на описании объектов и их взаимодействия, а остальное уже доводить до ума в процессе имплементации?
Обычно это делается так:
1. Тебе объясняют на пальцах то, чего от тебя хотят
2. Тебе все предельно понятно и ты идешь кодить
3. Начинаешь кодить и чет уже не так все понятно
4. Идешь уточнять, тебе уже не так уверенно отвечают на твои вопросы
5. Ты идешь и рисуешь на бумаге схему, как ты понял, что от тебя хотят и несешь показывать со словами "ЭТО ВЫ БЛЯТЬ ХОТИТЕ?"
6. Тебе говорят "НЕТ, БЛЯТЬ НЕ ЭТО!"
7. Ты говоришь "ТАК НАРИСУЙ БЛЯТЬ КАК НАДО!"
8. Тебе рисуют, вроде все понятно, идешь кодить
9. Возвращаешься на шаг 3
Двачую. Пробовал читать их книгу по C# - чуть не блеванул.
>>не читай.
Конкретно эту рецензировал и рекомендовал Эрих Гамма и какой то второй из банды. Она считается проще и понятнее оригинала. К тому же примеры - на джаве. Опять же надо понимать что хэд фест - это учебник для нубов, а не справочник. Поэтому воды много. В начале первая страница об этом.
>>Какие книги по проектированию стоит почитать?
Книги Боба Мартина и Мартина Фаулера наверни.
>Боба Мартина и Мартина Фаулера
Мошенники, которые зарабатывают тем, что пишут свои мутные книжки и выступают на конференциях где рассказывают о своих бредовых идеях. Удивительно, что кто-то ведется на таких говорящих голов, которые никогда и нигде не работали программистами.
В моей шараге есть такие преподаватели
Кто-то еще ходит учиться в вузик к людям, которые никогда не работали программистами.
Это "не читал, но осуждаю", или ты что-то конкретное сказать можешь?
>или ты что-то конкретное сказать можешь?
Не может - он ведь тоже никогда не работал программистом.
Помогите с 5 uml-диаграмамми за донат, Украина(((
Размести объяву о найме джуна без опыта, скидывай как тестовое. у вас же там и так полно программистов за миску борща
>Те новуки, которые не описывают, являются хуитой вроде психоанализа, марксизма и астрологии
Вообще-то марксизм описывает, если мы про марксистскую экономику говорим. С предсказательной силой там беда, но это общая проблема всех экономических и социологических теорий, а математика на месте.
>Размести объяву о найме джуна без опыта, скидывай как тестовое
Лол, а ведь идея на миллион.
Давайте пертрем за Event Storming. Кто умеет/практикует?
1) На каком этапе надо учить и пробовать применять паттерны, сразу после общих концепций ооп?
2) Как развивать ООП-мышление? Мне сказали, что я все равно пишу структурным подходом, несмотря на использование классов.
2) Как развивать ООП-мышление? Мне сказали, что я все равно пишу структурным подходом, несмотря на использование классов.
толсто
Как бы вы спроектировали элегантно?
Есть класс УниверсальныйРисовательТаблиц (УРТ), который пишет наименование объекта и в столбцах его свойства (разных типов). Есть класс Товар, у него свойства: вес, состав, дата изготовления, срок годности, адрес производителя. УРТ может нарисовать каталог таких товаров. Но в магазине хранится другая структура {Товар, цена, количество} , и УРТ должен нарисовать и список таких записей тоже, причем уже не все свойства Товара надо отобразить, а напимер так: наименование, дата изготовления, вес, цена, количество.
Я думал сделать интерфейс, который передается УРТ, из него УРТ может получить массив названий свойств (строк). И еще сделать в интерфейсе метод GetValue(int tovarId, string propertyName), а в реализации этого метода if (propertyName == "состав") { ... }. Но они же разных типов могут быть. Что делать?
Ну и что что разных типов, у тебя будет отдельная реализация этого интерфейса для товара и никогда её не будет использовать для других типов.
Нормальная у тебя идея - Урт может получать (с помощью сеттера) ноль и более интерфейсов "отдаватель списка интересующих полей", поставленных в соответствие с типом, к которому такой отдаватель надо получать.
Это конечно если не хочется вручную выдирать из товара нужные поля и пихать в урт , я бы сделал вручную
View Model
Есть некая игра на прямоугольной доске. В клетках стоят фигуры разных типов. Если начинать с самой простой реализации, то доска - двумерный массив, а фигуры - целые константы const int A = 0, B = 1... или enum { A, B, C ... }. Тут уже возникает мысль, что фигуры должны уметь себя рисовать, значит надо сделать их классами с методом Draw(), но пока не до этого, будем отделять логику игры, от ее отображения. Далее выясняется, что некоторые фигуры могут быть Левыми и Правыми. Продолжая вариант с перечислениями получаем enum { A, B, CLeft, CRight, DLeft, DRight... }. Тут конечно проблема, если я хочу функцию, меняющую ориентацию фигуры, придется ифами перебирать все типы. Я тут 3 варианта вижу, и все они не очень.
1) Иерархия классов Фигура->СимметричнаяФигура. Надо будет проверять, является ли фигура симметричной. Если является, то кастовать ее к этому типу и отражать. И если у меня нет множественного наследования, я не смогу подобным образом добавить другие свойства.
2) Интерфейсы. Опять надо проверять тип и кастовать. Также для всех Симметричных типов придется накопипастить одинаковую реализацию. Я не знаю как тут не копипастить.
3) Универсальный класс фигуры, в котором есть все свойства всех фигур и методы проверки, реализовано это свойство или нет.
Что лучше, другие варианты?
1) Иерархия классов Фигура->СимметричнаяФигура. Надо будет проверять, является ли фигура симметричной. Если является, то кастовать ее к этому типу и отражать. И если у меня нет множественного наследования, я не смогу подобным образом добавить другие свойства.
2) Интерфейсы. Опять надо проверять тип и кастовать. Также для всех Симметричных типов придется накопипастить одинаковую реализацию. Я не знаю как тут не копипастить.
3) Универсальный класс фигуры, в котором есть все свойства всех фигур и методы проверки, реализовано это свойство или нет.
Что лучше, другие варианты?
N xor 1
Как это мне поможет?
по-байтоебски в енаме отвести бит на флаг - симметрична ли фигура или нет, и менять флаг через xor.
Ты наверное архитектуры больше чем Хелоуворда не продумывал.
А вот пришлось как-то писать с нуля кросплатформенное приложение, читающее сенсоры с разных мат.плат. везде свои стандарты, где-то подключено к чипсету напрямую, где-то к SIO, да и везде свои SIO и чипсеты, где-то данные идут по 8бит, где-то по 16, короче, в линуксе одни методы доступа к аппаратуре, в винде другие, короче, заёб полный с этой стандартизацией, чтобы потом не росло как больное дерево.
Надо сначала продумывать и детально и где-то записывать. Чтоб потом следовали четко документации, а не так: "слушай я тут хуйню придумал, давай её заимплементим, потом доделаем и будем её тоже поддерживать", вот именно на этой стадии проект "размазывается" и начинается возня в болоте.
О, тред живой, охуенно. Читаю сейчас книгу с оп-пика в бумаге.
А также купил на рефакторинг.гуру за полторашку весь камтент, копейки же.
А также купил на рефакторинг.гуру за полторашку весь камтент, копейки же.
Бамп, ну где же вы, архитекторы?
Архитекторов нет, это сверхлюди, которые были до нас. Это великие умы на которых держится Вселенная. Мы только приходим\уходим, чиним\добавляем баги на фундамент залеженный богами.
Обмонадился с ООП лалок
мимо ФП господин
мимо ФП господин
Иди факториал вычисляй, факториал сам не вычислится
?
Слышал что-то про ленивые вычисления, питушок? Все факториалы объявлены вычисленными наперёд.
значит ничего сложного не писал
сейчас есть техлиды, входящие в отделы архитектуры, сам такой
Задачи отдела архитектуры - разбивка и оценка проекта на этапе pre sale, архитектура и выбор основного стека, запуск проекта, передача постоянному техлиду, поддержка техлида на время существования проекта. Как правило дают пол процета-процент доли прибыли проекта.
из UML самая полезная - sequence diagram, разбираешься ли ты в существующей системе или встраиваешь что-то новое
"изучать UML" тебе нахуй не всралось, идешь да рисуешь её на примере. В пикрелейтед OAuth, глянул на диаграму, сразу понятно что к чему.
Диаграму классов рисуют гораздо реже, в основном если заказчик в документации требует.
Какие инструменты и методики хорошо работают?
UML - годнота?
Как не скатиться в ООП-головного мозга?
До какого уровня конкретики стоит доводить проект на бумаге: буквально до набросков реализации или остановиться на описании объектов и их взаимодействия, а остальное уже доводить до ума в процессе имплементации?