> конвертировать XML в эксепшены абстрактной фабрикой виртуальных фасольных компонент
Обкакался с этого.
Обкакался с этого.
ООП позволяет спрятать внутри себя говнище, а на поверхности ты дергаешь только рычажки у объекта.
Называется это модульностью за счет инкапсуляции.
В чисто процедурном языке такое достигается только по соглашениям (то есть никак).
В ФП - игрушка для антиглоров
Называется это модульностью за счет инкапсуляции.
В чисто процедурном языке такое достигается только по соглашениям (то есть никак).
В ФП - игрушка для антиглоров
Другая фишка, что принято дробить объект по его логической функции - то есть делает что-то одно, и все эти сущности группировать по логике (в подпакеты).
Понятно, когда на решение просто задачи куча классов - ньюфага бросает в дрожь, он теряется, неосиливает и бежит ебаться со скриптами (или с го, судя по их код-стайлу), так как там нормально в одном методе иметь 500 строк кода.
Либо ты растешь как специалист и осиливаешь ООП, либо сиди на всяких го или питонах как чмо
В Питоне есть и активно используется ООП , не гони.
>В чисто процедурном языке такое достигается только по соглашениям
В сишке запросто делается через opaque pointer.
ну я рад что он эволюционирует
Не юзал активно, как показался они юзают там не сам ооп, а возможность писать через оператор точка.
По большому счету, динамическому языку ООП нах не всралась
Она никому и никогда не всралась, вон Шурик из комедии Гайдая спокойно работал себе в НИИ, на Фортране херачил.
Я уже говорил как-то, что суть ООП заключается в том, чтобы затруднить миграцию с венды. А не в мифическом RAII/DI, которые что сами наросли.
>чтобы затруднить миграцию с венды
Нехера у тебя обострение
Суть ООП изолировать логику модуля от внешнего влияния, а наружу вытащить только то что нужно.
Есть у тебя объект в котором 20 состояний, а наружу торчит три метода для взаимодействия. В процедурном мире тебе надо изучить структуру и попытаться найти функции и понять как она вообще взаимодействует. ООП же тебе говорит - чувак, вот тебе все что надо это три твоих метода, остальное это там черный ящик у меня (хочешь посмотри, но тебе это ненужно).
Круто? Конечно. Осталось тебе только осилить это.
Это все ненужно.
>изолировать логику модуля от внешнего влияния
Это суть любого грамотного подхода при программировании в языках поддерживающих ту, или иную модульность, будь то h-фалы в сишке, модули в Модуле, объекты в пхп.
Суть ООП совершенно в другом.
> ООП же тебе говорит - чувак, вот тебе все что надо это три твоих метода, остальное это там черный ящик у меня
Мама тебя тесты не учила писать? Черный ящик требуется покрывать тестами (интеграционных на интерфейсы мало, тут рот не открывай) и ты начинаешь бороться с ООП, ломать инкапсуляцию, а изо рта у тебя течет пена. Объектная парадигма, пропагандирующая черный ящик - мина замедленного действия. Код без тестов - лютое говно, которое невозможно поддерживать.
Мама тебя тесты не учила писать? Черный ящик требуется покрывать тестами (интеграционных на интерфейсы мало, тут рот не открывай) и ты начинаешь бороться с ООП, ломать инкапсуляцию, а изо рта у тебя течет пена. Объектная парадигма, пропагандирующая черный ящик - мина замедленного действия. Код без тестов - лютое говно, которое невозможно поддерживать.
>тесты
Не нужны.
>Код без тестов - лютое говно, которое невозможно поддерживать.
Если ты дебил и говнокодер - то несомненно.
Тесты не нужны, для мамкиных борщехлебов, типа тебя.
Код который пишут больше одного человека - НАДО покрывать тестами, чтобы Васян за столом, не вникая в твое говно, мог внести правку и не сломать все к хуям собачьим.
>НАДО ЯСКОЗАЛ
Ясно.
>Васян за столом
Просто Васяны не нужны.
Ничего личного, Васян, просто смирись.
Тесты нужны, чтобы после того как Васян сломал код, покрытый тестом, это стало очевидным.
В сракотан тебе ебал. #аргумент.
И пофиксил.
Бтв, открытые классы с инкапсуляцией данных прекрасно тестируются и лишены недостатка «20 приватных методов»
>Васян
>пофиксил.
Спасибо, но нет.
Идите, пожалуйста, нахуй на мороз.
Объясняю тупому еще раз:
> :3 <=======|
> :3=====|
> :3=|
> :3=====|
> :3 <=======|
Где :3 - твой сракотан, <=======| - МПХ
Понял?
Ты гофер пидор что ли?
>Я уже говорил как-то, что суть ООП заключается в том, чтобы затруднить миграцию с венды.
Удваиваю.
Алсо, угорел тут ночью по Rust.
Выглядит как годнота.
>Выглядит как говнота.
Согласен с тобой.
Обнаружен поехавший срущий питух.
Колчанька, пожалуйста.
>Это все ненужно.
Гофер??
Это называется инкапсуляция и это ВНИМАНИЕ часть ООП.
И чаще именно без ооп пишут кишками наружу, поэтому ООП уже де-факто модульнее чем любое процедурное говнище.
Как минимум завозят рефлексию, но вы еще это не проходили (а на жабе вообще мутузят байткой как хотят).
Гофер детектед, лол
>инкапсуляция часть ООП
Ага, значит питон - не ООП?
>поэтому ООП уже де-факто модульнее
На ООП можно точно так же спокойно нахуячить паблик методов и паблик свойств.
Сдуру можно и хуй сломать. Дело, в основном, не в языке, а в прослойке между клавиатурой и стулом. Даже на коболе можно писать грамотно.
Рассуждаю с позиции интерпретируемой параши, где рефлексия - частный случай метапрограммирования, которым обмазаться проще простого. И бтв, ломать инкапсуляцию - в т.ч. модификацией и/или отслеживанием методов - один хрен костыль, ведущий к избытку кода что-ли.
>Ага, значит питон - не ООП?
Ну да, питон это язык, а ооп парадигма.
>инкапсуляция часть ООП
часть, одна из частей...
>Ага, значит питон - не ООП?
сам питон не ООП, а вот в нем ООП есть, кривой правда
>На ООП можно точно так же спокойно нахуячить паблик методов и паблик свойств.
Можно и ляшку за машку, если ты уж решил срать в коде, то сделать это можно 100500 способами и без ООП
Аргументация анона - ООП модульнее остальных. Если сказал модульнее - то аргументируй на сколько и в каких единицах измеряется. Пока что это был беспруфный вскукарек, ибо при любой парадигме срется в код легко. Взять ранний PHP, вроде бы ООП есть, а модульность при этом никакая.
Инкапсуляция вообще создана не для сокрытия всякой хуйни и уж тем более не для изолирования чего-то там от внешнего влияния. Наоборот, она изолирует весь внешний код от деталей реализации конкретной функциональности. Вот это и есть настоящая инкапсуляция, а не эти ваши privatы-хуяты. И это достигается не в результате использования той, или иной парадигмы, а трудом программиста.
Ты случаем не тот психопат гофер, который несет постоянно абстрактную хуйню?
Нет, я другой. Но ведь я не несу хуйню, люди в целом неправильно понимают некоторые вещи, например инкапсуляцию как сокрытие всего и вся, и из-за этого абстракции начинают протекать.
Эссенция инкапсуляции в сокрытии объектов внутри объектов.
Кто мне пояснит разницу между виртуальным и статическим методом?
Виртуальный метод - метод объекта.
Когда ты его вызываешь, программа смотрит в таблицу методов объекта, достаёт ссылку на конкретную реализацию и исполняет его.
Статический метод - это метод класса. Он не имеет доступа к полям объектов. Для его вызова не нужен объект. Компилятор сразу вставляет ссылку на него в маш.код при компиляции, т.к. такой метод нельзя перегрузить.
Спасибо, вроде все ясно понятно для меня.
Да что ты говоришь.
Почему вы только переливаете из пустого в порожнее, но не прибегаете к примерам из реальной жизни? К примеру вот задачка, её можно решить как с помощью ООП, так и с помощью ФП, а потом посмотреть какое решение наиболее читабельное и расширяемое (легко ли добавлять новые виды скидок или модифицировать существующие).
Есть продукты A, B, C, D, E, F, G, H, I, J, K, L, M. Каждый продукт стоит определенную сумму.
Есть набор правил расчета итоговой суммы:
Если одновременно выбраны А и B, то их суммарная стоимость уменьшается на 10% (для каждой пары А и B)
Если одновременно выбраны D и E, то их суммарная стоимость уменьшается на 5% (для каждой пары D и E)
Если одновременно выбраны E,F,G, то их суммарная стоимость уменьшается на 5% (для каждой тройки E,F,G)
Если одновременно выбраны А и один из [K,L,M], то стоимость выбранного продукта уменьшается на 5%
Если пользователь выбрал одновременно 3 продукта, он получает скидку 5% от суммы заказа
Если пользователь выбрал одновременно 4 продукта, он получает скидку 10% от суммы заказа
Если пользователь выбрал одновременно 5 продуктов, он получает скидку 20% от суммы заказа
Описанные скидки 5,6,7 не суммируются, применяется только одна из них
Продукты A и C не участвуют в скидках 5,6,7
Каждый товар может участвовать только в одной скидке. Скидки применяются последовательно в порядке описанном выше.
Необходимо написать программу, которая, имея на входе набор продуктов (один продукт может встречаться несколько раз) рассчитывала суммарную их стоимость.
Есть продукты A, B, C, D, E, F, G, H, I, J, K, L, M. Каждый продукт стоит определенную сумму.
Есть набор правил расчета итоговой суммы:
Если одновременно выбраны А и B, то их суммарная стоимость уменьшается на 10% (для каждой пары А и B)
Если одновременно выбраны D и E, то их суммарная стоимость уменьшается на 5% (для каждой пары D и E)
Если одновременно выбраны E,F,G, то их суммарная стоимость уменьшается на 5% (для каждой тройки E,F,G)
Если одновременно выбраны А и один из [K,L,M], то стоимость выбранного продукта уменьшается на 5%
Если пользователь выбрал одновременно 3 продукта, он получает скидку 5% от суммы заказа
Если пользователь выбрал одновременно 4 продукта, он получает скидку 10% от суммы заказа
Если пользователь выбрал одновременно 5 продуктов, он получает скидку 20% от суммы заказа
Описанные скидки 5,6,7 не суммируются, применяется только одна из них
Продукты A и C не участвуют в скидках 5,6,7
Каждый товар может участвовать только в одной скидке. Скидки применяются последовательно в порядке описанном выше.
Необходимо написать программу, которая, имея на входе набор продуктов (один продукт может встречаться несколько раз) рассчитывала суммарную их стоимость.
При чем тут паттерн матчинг?
метод ЯтвоюМамкуЕбал
цена = МодульРассчетаЦен.new(корзина).посчитать
конец
...
где-то в модуле РассчетаЦен
метод посчитать
....
скидка = МодульСкидок.new(корзина).посчитать
...
цена_товара = базовая_цена - скидки ± ...± ... etc
вернуть цена_товара
конец
...
где-то в МодулеСкидок
метод посчитать
список_скидок = получить_список_скидок
сумма = список_скидок.аггрегирровать_твою_мамку { |скидка| скидка.посчитать(корзина) }
вернуть сумму
конец
и хуячешь множество наследников от абстрактной_скидки c конкретными правилами, не забудь про иерархию типов. С тебя 200 баксов.
ебать гавнище
надеюсь ты не работаешь нигде
>ебать гавнище
Вы смотрите, квалифицированный работник в трениках из грязной подворотни голос подал.
>Суть ООП изолировать логику модуля от внешнего влияния, а наружу вытащить только то что нужно.
Тебе уже написали, что инкапсуляция есть в любом процедурном языке хоть в сишке, хоть в паскале. Даже в форте, где вообще нихуя нет, ни локальных переменных, ни модулей, ни скоупов, инкапсуляция есть.
>инкапсуляция и это ВНИМАНИЕ часть ООП
Но инкапсуляция не эксклюзивная фича ООП. Она была задолго до. К тому же инкапсуляция может быть достингнута многими другими средствами, а не только говнарскими protected/private, my/our и тому подобным говнарстом.
дебилушка, за такую хуиту, что ты высрал, в нормальных конторах публично ссут в тупое ебало
>инкапсуляция
У меня есть коллега, который презирает уровни доступа С++. Он работает на низком уровне, использует С++, как С с классами. Драйвера, софт для embedded и т.п. Когда я ему начинаю говорить про типобезопасность, инкапсуляцию, он говорит, что возьмет и получит нужные данные по смещению. Ну и что ему возразишь? Ничего. Он прав. Если кто-то захочет - он сделает. Даже в мейнстримовых песочницах можно. Вопрос цены только.
Конечно это не значит, что нужно все это забыть. Но категоричность сбавить можно было бы :)
У меня есть коллега, который презирает уровни доступа С++. Он работает на низком уровне, использует С++, как С с классами. Драйвера, софт для embedded и т.п. Когда я ему начинаю говорить про типобезопасность, инкапсуляцию, он говорит, что возьмет и получит нужные данные по смещению. Ну и что ему возразишь? Ничего. Он прав. Если кто-то захочет - он сделает. Даже в мейнстримовых песочницах можно. Вопрос цены только.
Конечно это не значит, что нужно все это забыть. Но категоричность сбавить можно было бы :)
Ну я тоже все кишками наружу делаю. Так проще и быстрее, и понимание практически не затрудняет. value() setValue() действительно необходимы для pimpl как в Qt или на границе больших модулей, где надо четко API зафиксировать.
>сам питон не ООП, а вот в нем ООП есть, кривой правда
А в чем проявляется эта КРИВОТА?
А вот объясните на пальцах, буквально в двух словах, что же такое ООП? Почему я должен учиться размышлять такими абстракциями? Я не семеню, правда, просто совсем ньюфаг, не знаю, что к чему, а с вашей помощью стану более развит в этой сфере.
В большинстве ООП языков закрытые данные можно получить рефлексией, если нужно.
Инкапсуляция нужна, чтобы криворукие индусы не поломали хрупкие внутренности объекта, а работали с ним только через ограниченный список безопасных методов.
Ты мамкин борщец любишь?
>буквально в двух словах, что же такое ООП?
Когда данные лежат в одном месте, и операции с ними осуществляется методами через точечку (или квадратные скобочки).
>Почему я должен учиться размышлять такими абстракциями?
Единственная причина - повсеместная практика.
Статический метод - это простая функция из необъектного Си или Паскаля, только видимая лишь в неймспейсе класса.
Нестатический невиртуальный метод - аналогичен статическому, тоже простая функция, но у нее есть невидимый первый параметр this, при вызове он получает адрес объекта.
Сам объект - это структура. Помимо обычных полей, у нее есть дополнительное поле vmt, где хранится таблица виртуальных методов - массив указателей на процедуры.
Виртуальный метод, собственно и есть указатель из этого массива. Он всегда нестатический.
При вызове конструктора класса выделяется память под структуру и заполняются все поля, включая vmt. Поэтому у разных классов vmt разные, указатели в них разные, отсюда и виртуальные методы тоже будут разные.
Это если есть только классы с одиночным наследованием (Turbo Pascal, первая версия C++), при множественном наследовании/интерфейсах/трейтах все намного усложняется.
>что ты высрал
Я мимокродил вообще.
>дебилушка
>высрал
>публично ссут в тупое ебало
>в нормальных конторах
Ну как скажешь.
> инкапсуляция это часть ООП
> но в питоне нет ее
> значит в питоне ООП кривое
и тут ты спрашиваешь в чем кривота ООП в питоне - ну ебанный врот, ты тред чем читаешь?
>> но в питоне нет ее
Там самая правильная инкапсуляция - по соглашению. Хочешь дергать приватные методы, дергай под свою ответственность.
ООП позволяет разбить с помощью паттернов и SOLID архитектуру сложного проекта на примитивные модули (классы). Сотню таких модулей можно аутсорсить в Индию, Китай или другую страну, наняв за тарелку риса местных Раджанов, худо-бедно выучивших, что такое циклы и переменые, каждому по модулю. А гнущего пальцы Ивана, помнящего наизусть число тактов в каждом опкоде Z80, можно выкинуть на помойку. Бизнесу сотня Равшанов обходится дешевле одного Ивана. Потому ООП и популярно.
Настоящая расширяемость, модифицируемость — это не когда вам дали два гнезда и вы можете воткнуть в одно — функцию, раскрашивающую вывод, а во вторую константу, отвечающую за размер буфера. Расширяемость, в том виде в каком к ней надо стремиться — это возможность взять вещь, посмотреть как она устроена, разобрать, что-то вынуть, что-то поставить свое. Утиная типизация, подсовывание своего объекта вместо чужого, все ручки на виду и перезаписываемые. При проектировании под расширяемость надо учитывать ровно одну вещь — что ты понятия не имеешь, кто и что с твоей библиотекой захочет сделать.
Ведь почему мы так любим Кложу? Потому что в ней принято делать открытые системы (с подачи Рича, конечно). Первое — библиотеки гоняют данные, и на вход, и на выход, и внутри. Данные, понятно, открыты, это не классы, их легко распечатать, легко поменять, сгенерировать в нужном виде — короче, библиотека никак не диктует, что и как вам делать с данными. Второе — протоколы, протоколом прикинуться легко. Третье — открытые неймспейсы, куда можно при необходимости залезть, посмотреть, поменять что-то. Позволяет, например, тестировать даже то, что для тестирования не предназначалось.
Это приводит к тому, что почти всегда библиотеку на Кложе можно понять и можно заставить делать то, что нужно. Очень трудно загнать пользователя в угол, если только специально не прилагать усилий. Это важно, и я рад, что Кложе-сообщество подхватило этот тренд.
Но куда идет общественное мнение? Общественное мнение склоняется к тому, что разработчику библиотеки виднее, что выставлять наружу, а что нет. Приватные свойства, закрытые лексические скоупы, захваченные через замыкание функции и свойства без постоянного имени, проверка конкретного типа вместо протокола или утиной типизации.
Не надо так.
Ну так все верно, чтобы копать траншею инженерное образование не нужно, проще бригаду таджиков нанять нежели одного Ивана с вышкой.
>буквально в двух словах, что же такое ООП?
Один из видом модульности в программировании.
Я гляжу нынешняя молодежь с трудом в ООП въезжает
Лол, это отсутствие инкапсуляции
Все IT и есть траншеи, за редким исключением (ОС, микроконтроллеры, машинное обучение, ПО для атомной и космической промышленности). И Иван в нем нахуй не нужен.
Хорошо, доставь пруф в виде общепринятого определения инкапсуляции из которого явно будет следовать, что соглашение об именовании не канает.
>Лол, это отсутствие инкапсуляции
Ну тогда нигде инкапсуляции нет, потому что практически везде ее можно обойти, если хочется.
>микроконтроллеры
>ПО для атомной и космической промышленности
В рахе там как раз иваны пидорасят для клоунов за доширак.
>В рахе там как раз иваны пидорасят для клоунов за доширак.
Кстати да.
В РФных истребителях и ракетах на PIC микроконтроллерах половина электроники сделана.
>на PIC микроконтроллерах половина электроники сделана
Ну там может большего и не нужно. Для радаров/оптики какие-то сложные алгоритмы нужны, а для остального можно и так.
>Ну там может большего и не нужно. Для радаров/оптики какие-то сложные алгоритмы нужны, а для остального можно и так.
Мякота в том, что оборонка построена на буржуйских микроконтроллерах.
>Мякота в том, что оборонка построена на буржуйских микроконтроллерах
Последние года вроде и наши начали что-то выпускать. Даже FPGA свои есть.
>Последние года вроде и наши начали что-то выпускать. Даже FPGA свои есть.
Там проблема не в том, что свои не могут выпускать.
А в тотальном бардаке.
Идиотизме.
Это под коррупцию не подходит даже.
Ну вот вспомнить вскрытие черного ящика сбитого турками истребителя. В /ra бугуртили 3 месяца подряд.
>А в
Руководство о том чтобы наладить производство цепь поставок ИТД даже и не думает.
Только как украсть бюджет, и продать старье 30 лет гниющее на складах по цене золота.
Спасибо, больше похоже на правду, но гораздо более непонятно.
Инкапсуляция - это не сокрытие. Это создание компонентов, детали реализации которых не важны для осуществления их взаимодействия.
> Общественное мнение склоняется к тому, что разработчику библиотеки виднее, что выставлять наружу, а что нет.
Выставлять кишки во внешний мир чревато, ни один разработчик библиотек не может, да и не будет гарантировать совместимость интерфейсов для каждого метода. Хочешь, ломай инкапсуляцию - однако, ты, хуй, делаешь это на свой страх, риск и ответственность.
Тогда как внутри библиотки открытые классы - это охуенно.
Просто не нужно ничего специально ограничивать, тогда не нужно будет ничего ломать. В 90% случаев, когда любители ООП используют инкапсуляцию - её не стоило бы использовать, а нужно было использовать просто списки, мэпы, etc. Библиотеки должны возвращать данные, а не объекты. В том же питоне так всё работает, и на нём можно много что сделать. Мне, как пользователю либы, лучше знать, для чего мне нужны данные и что я собираюсь с ними делать. Для совместимости есть протоколы.
Объекты - это тоже данные.
>Объекты - это тоже данные
Внутри которых данные, к которым разработчик ограничил доступ, хотя они тоже нужны.
> Библиотеки должны возвращать
Не понял, в чем принципиальная разница между возвращаемым объектом и «данными». Данные - те же объекты.
>Для совместимости есть протоколы.
Давай на примере, допустим ты автор библиотеки, что скачивает веселые картинки с котиками, в недрах либы такая реализация:
метод ПослатьРеквест(токен)
...
конец
Потом ты переписываешь, ну скажем так
метод ПослатьРеквест
токен = текущий_токен || Либа::Конфиг.тоген
...
конец
Теперь твой код, с использованием послать_реквест сломается, из-за передачи ненужного параметра, а для нормального пользователя ничего не меняется, он опирается на контракт: публичный метод - получить_моего_котика. Как решить коллизию с помощью протокола? Хранить оба метода и ad-hom полифиормизм, пожалуйста не предлагай - буду ссаться кипятком.
Поправьте, если ошибаюсь, но программирование это просто создание узоров из 0 и 1, а любые ограничения, которые за вас кто-то насоздавал, это априори полезная работа?
>Внутри которых данные, к которым разработчик ограничил доступ, хотя они тоже нужны.
Если эти данные нужны пользователю объекта, то этот разработчик должен быть разжалован нахуй в дворники.
Нахуя вообще набирать разработчиков, которые не обладают даром ясновидения и предсказания будущего?
Непротекающие абстракции могут создавать только экстрасенсы?
>Непротекающие абстракции могут создавать только экстрасенсы?
Результат любой "непротекающей абстракции" - монструозный монолитный фреймворк, из которого невозможно изолировать ни один кусок. Ничего другого абстракции в ООП делать не позволяют.
Проебался немного, коэффициенты нужно инвертировать для групп. Но это мелочь, суть в семантике.
Наверное, крайне неудобно сопровождать такие узоры из 0 и 1. По крайней мере на текущем развитии мозга.
Раз делают, значит удобнее, чем все остальное.
Это скорее результат оптимизации производительности. При использоавании непротекающих абстракций возникает потребность часто преобразовывать данные из одного типа в другой, а так же создавать кучу их копий. Без соответствующих оптимизирующих компиляторов это причиняет боль ожидания конца выполнения программы.
Что-то маловато срача, опять одни школьники ебут друг друга в мамку. Опять без батькиного пендаля ничего не можете.
Задача очень плохо сформулирована.
Смущает, что скидка в принципе 3 лишена смысла, так как выбор любых 3 продуктов активирует скидку 5 с тем же коэффициентом. А поскольку "каждый товар участвует только в одной скидке", то, очевидно, для последний трех скидок формулировка должна явно проговаривать "от суммы заказа за вычетом уже дисконтированных товаров", если это так, либо уточнение, что при наличии хотя бы одного дисконтированного товара общая скидка отменяется. Вообще предложение считать скидку "от суммы заказа" при явном указании того, что ряд товаров в этой скидке не участвует, отдает абсурдом.
Также стоило явно проговорить, что последние джве скидки перекрывают предыдущие две. Если понимать условие задачи "скидки применяются последовательно" буквально, то последние две скидки никогда не будут применены, так как их условие включает в себя условие предыдущей скидки. Следовательно, требуется уточнение: должна ли бОльшая скидка замещать меньшую.
В общем, у нас в конторе ПМы, ставящие задачи так небрежно, рискуют обнаружить распечатку таска в собственном анусе. Отличная демонстрация того, что в индустрии работают прежде всего хуевые проектировщики, а их ругань в адрес ООП или ФП обусловлена тем же самым, чем ругань плохого начальника на якобы непутевых подчиненных - желанием переложить ответственность с себя на некое обстоятельство непреодолимой силы, рационализировать свое поражение.
Вообще из прошлых тредов я заметил такое плохо скрываемое желание получить такой инструмент, который устранил бы необходимость проектирования софта. Отсюда вся эта болезненная страсть к лямбдам и прочей скорописи на туалетной бумажке в объектных языках, или вот это вот желание избегать инкапсуляции очень показательно - чел вообще не думает о том, что наращивание связности через уровень абстракции чревато катаклизмом; что ж, у него, видимо, все еще впереди.
Проблема плохого проектирования выдается за проблему методологии. В предыдущих двух тредах постоянно звучит неявная претензия: я вот тут что-то нахуярил на коленке без проектирования на этом вашем ООП, а оно чёт хуево взлетает, говно это, а не методология.
Задача очень плохо сформулирована.
Смущает, что скидка в принципе 3 лишена смысла, так как выбор любых 3 продуктов активирует скидку 5 с тем же коэффициентом. А поскольку "каждый товар участвует только в одной скидке", то, очевидно, для последний трех скидок формулировка должна явно проговаривать "от суммы заказа за вычетом уже дисконтированных товаров", если это так, либо уточнение, что при наличии хотя бы одного дисконтированного товара общая скидка отменяется. Вообще предложение считать скидку "от суммы заказа" при явном указании того, что ряд товаров в этой скидке не участвует, отдает абсурдом.
Также стоило явно проговорить, что последние джве скидки перекрывают предыдущие две. Если понимать условие задачи "скидки применяются последовательно" буквально, то последние две скидки никогда не будут применены, так как их условие включает в себя условие предыдущей скидки. Следовательно, требуется уточнение: должна ли бОльшая скидка замещать меньшую.
В общем, у нас в конторе ПМы, ставящие задачи так небрежно, рискуют обнаружить распечатку таска в собственном анусе. Отличная демонстрация того, что в индустрии работают прежде всего хуевые проектировщики, а их ругань в адрес ООП или ФП обусловлена тем же самым, чем ругань плохого начальника на якобы непутевых подчиненных - желанием переложить ответственность с себя на некое обстоятельство непреодолимой силы, рационализировать свое поражение.
Вообще из прошлых тредов я заметил такое плохо скрываемое желание получить такой инструмент, который устранил бы необходимость проектирования софта. Отсюда вся эта болезненная страсть к лямбдам и прочей скорописи на туалетной бумажке в объектных языках, или вот это вот желание избегать инкапсуляции очень показательно - чел вообще не думает о том, что наращивание связности через уровень абстракции чревато катаклизмом; что ж, у него, видимо, все еще впереди.
Проблема плохого проектирования выдается за проблему методологии. В предыдущих двух тредах постоянно звучит неявная претензия: я вот тут что-то нахуярил на коленке без проектирования на этом вашем ООП, а оно чёт хуево взлетает, говно это, а не методология.
>Проблема плохого проектирования выдается за проблему методологии.
Как выглядит процесс разработки софта при использовании проектирования? Проектируем, пилим, утыкаемся в недостатки спроектированной архитектуры, далее, либо ляпаем костыли, либо снова проектируем. Круг замкнулся.
Как выглядит нормальный процесс разработки софта? Пилим простой DSL под присмотром специалистов. Пилим софт на DSL, допиливаем DSL, пилим софт: круг замкнулся.
>Круг замкнулся
Это называется "итеративная разработка", и сам по себе такой подход может быть вполне успешен, так как сопособствует раннему выявлению ошибок в архитектуре, исправлять которые чем дальше, тем дороже. Конечно, он имеет и свои трейд-оффы по сравнению со всякими там V-models.
>Отличная демонстрация того, что в индустрии работают прежде всего хуевые проектировщики, а их ругань в адрес ООП или ФП обусловлена тем же самым, чем ругань плохого начальника на якобы непутевых подчиненных - желанием переложить ответственность с себя на некое обстоятельство непреодолимой силы, рационализировать свое поражение.
Только вот.
Ругают НЕ проектировщики и ПМы, а программисты.
Проектировщиков как раз все устраивает.
Им ООП как манна небесная.
Ты хотел сказать, что программист не должен заниматься проектированием? Это просто бомба.
Да и задачку с демонстрацией уровня развития сюда запостил, увы, не ПМ.
Вон выше пример, личинка программиста хуячит все в один метод и в ус не дует, какое проектирование, какое ооп - ты о чем, и так сойдет.
Зачем вы обсуждаете обычных наследственных дебилов, вам что - делать нечего?
>Зачем вы обсуждаете обычных наследственных дебилов, вам что - делать нечего?
>обычных наследственных дебилов
>наследственных
Заметь, мы ни на шаг не отклонились от основной темы треда.
Тот метод изи бьётся на несколько. Ждём твой вариант.
>Не нужны.
конечно не нужны, не используй
смысл существования этого треда?
>Мама тебя тесты не учила писать? Черный ящик требуется покрывать тестами (интеграционных на интерфейсы мало, тут рот не открывай) и ты начинаешь бороться с ООП, ломать инкапсуляцию, а изо рта у тебя течет пена.
А не надо ее ломать потому что. Никто не заставляет тебя вызывать защищенные методы из теста прямо, более того: любой разраб, пытающийся в нашей конторе провернуть подобное, немедленно получает по рукам от меня лично.
А разгадка проста: мамкины тестопейсатели не знают, что тесты должны фиксировать поведение интерфейса, а не реализацию. Нет разницы, как оно сформировано изнутри. Весь код защищенных методов так или иначе будет вызван при тестировании публичных и окажет влияние на их поведение, которое и фиксируется. Если это невозможно сделать - значит, код плохо декомпозирован и его надо отрефакторить. Далеко не любой код поддаются тестированию, это надо понимать сразу при разработке, чтобы потом не было мучительно больно.
Круто. Мы вам перезвоним.
Хз как потом такой код поддерживать.
правильно, так их
не пишите тестов, пусть клиент тестирует
> значит, код плохо декомпозирован и его надо отрефакторить
О чем и речь, инкапсулировать следует геттеры, которые не нужно тестировать (в рамках текущего класса), максимум, что с ними нужно сделать, так это изолировать (mocking/stubbing). Ты дедуля шаришь, хотя и повторяешься немного в пересказе идей, своими словами.
>не пишите тестов, пусть клиент тестирует
Тесты мало написать, их надо написать правильно.
ну зачем ты плодишь конкуренцию,
пусть вообще не пишут и гордятся этим
Так они ж потом ко мне приходят работать. В конторе страшный кадровый голод, а приходят одни дегенераты, такое ощущение, что прямиком из этого итт треда.
ну вот там вкатывальщиков и научишь за зп в кусок сала
И развитие этой идеи ведет к понятию открытых и дружелюбных классов, то есть таких классов, что инкакапсулируют геттеры, простенькие методы, и данные (состояния). Впрочем, это не значит, что _все_ классы обязаны быть дружелюбными.
>инкапсулировать следует геттеры
Ти вапще с этой плонети? Что такое "инкапсулировать геттеры"?
>которые не нужно тестировать
Еще как нужно. Во-первых, в них регулярно наблюдаются ошибки копипастного характера, во вторых, геттеры-сеттеры, как правило, реализуют дополнительную логику (проверка входящего значения, исключение при попытке доступа к неинициализированному свойству и т.д.)
>вкатывальщиков и научишь
В гробу я видал тратить время и нервы на этот скам. Пусть хотя бы часть работы над собой сделают сами.
>таких классов, что инкакапсулируют геттеры, простенькие методы, и данные (состояния)
Да дались вам эти геттеры. Геттер - это в принципе антипаттерн, их, конечно, не надо повсеместно выжигать каленым железом, но зачастую они сигнализируют о плохо просчитанной ответственности класса. Каждый геттер кто-то дергает снаружи, что увеличивает сопряженность, а этого надо стремиться избегать любой ценой.
Это не инкапсуляция, это принципы RAII/DI.
Т.н. инкапсуляция — это пространства имён всего лишь, есть в любом современном я/п.
>Т.н. инкапсуляция — это пространства имён всего лишь
Пиздец крепчал. Идея инкапсуляции состоит в структурном объединении данных с кодом, который их обрабатывает, а также в ограждении внешней части системы от сложности внутренней части подсистемы (это называется сокрытие и оно опционально). Пространства имен никоим образом не решают ни одну из этих задач.
>ограждении внешней части системы от сложности внутренней части подсистемы
Это называется абстрагирование, а не сокрытие.
>Что такое "инкапсулировать геттеры"?
Оформить приватный интерфейс, возвращающий какой-нибудь service object. Можно в конструкторе объявить переменную, и потом обращаться к ней напрямую - но это не так очевидно, что-ли. А я люблю быть тупым и предсказуемым.
>Еще как нужно.
А по-моему, нет, не нужно. Они тестируются отдельно. Если в текущем классе Encapsulated объект влияет на что-то, будь добр пили fixtures и тестируй текущие интерфейсы. Зависимость от внутренностей других объектов при тестировании следует сводить к минимуму.
Если геттер реализует дополнительную логику, кроме возврата объекта ок - можно, но тут такая дилемма - а не лучше ли перенести эту логику в статический метод (являющийся конструктором объекта) для класса данного объекта? Геттеры с логикой - это скорее редкость, нежели правило.
> Каждый геттер кто-то дергает снаружи, что увеличивает сопряженность, а этого надо стремиться избегать любой ценой.
Согласен, но «любой ценой» - звучит несколько категорично, нелюблю категоричность, программирование - это про торговлю и поиск меньшей из всех зол (в идеальном мирке).
>Я не семеню, правда, просто совсем ньюфаг, не знаю, что к чему, а с вашей помощью стану более развит в этой сфере.
Изначально речь шла о разделении программы по слоям и (если очень хочется) потокам.
Затем внутри каждого потока его состояние (т.н. "стейт") запрятали в объекты — получив
Затем научились эти объекты создавать и удалять по требованию, добавив принципы RAII и DI, так перешли от ранних языков типа Modula-2 к современным.
Кое-где объекты могут отправлять сообщения другим объектам и окнам с помощью одной и той же функции, "SendMessage()", но это встречается редко и большинству нинужно (а смысл этого тайного действа в том, что они разделены между потоками).
Это два разных вида «объектов», одни компоненты программы, контейнеры с кодом, а другие — списки, мэпы, etc, контейнеры для данных.
>в структурном объединении данных с кодом
Сколько я бороздил энторнеты, под этим словом понимали сокрытие данных от доступа извне.
Привязка к ним методов, чтобы получить к ним доступ только через эти методы — придумайте другое название, иначе вы в названиях и определениях запутаетесь.
В списках, мэпах итд можно и код хранить.
Тесты не помогают предотвращать ошибки, они помогают лишь обнаруживать их или создавать. Нужно делать формальную верификацию на зависимых типах.
Инкапсуляция - это черный ящик. Когда все, связанное с сущностью (классом), т.е. и данные, и алгоритмы для их обработки собираются в одном месте, внутри этого ящика. А наружу торчит интерфейс - извне взаимодействовать с объектом можно лишь через него.
Абстрагирование это более общая концепция, частным случаем которой является ООП. Модули в Turbo Pascal - тоже абстрагирование.
Нет, абстрагирование - это и есть, то что ты написал в предыдущем посте. А вот каким способом это достигается - модульностью, объектами, лямбдами - это уже другой вопрос. Грубо говоря, абстрагирование - это создание интерфейсов.
ООП это один из вариантов абстрагирования.
ООП в общепринятом понимании, пришедшим из Симулы, это инкапсуляция (суть модульность), наследование и полиморфизм (суть повторное использование кода). Нигде про абстрагирование речи нет.
>приватный интерфейс, возвращающий какой-нибудь service object
Ну ты очень хитрожопое название для этого явления придумал. Еще раз: если он приватный - его нужно тестировать только косвенно, через вызов публичных методов, которые внутри себя его дергают под нужным углом.
>А по-моему, нет, не нужно. Они тестируются отдельно.
Знатно поделил на ноль. Так нужно или не нужно, и отдельно от чего?
>не лучше ли перенести эту логику в статический метод
Ты ебанутый? Зачем пилить статический метод для работы с данными экземпляра? И при чем тут конструктор? Упаси б-же в конструкторе делать что-либо кроме проверки и присвоения пришедших на вход значений.
>Геттеры с логикой - это скорее редкость, нежели правило
Это скорее правило, чем редкость. Ленивая загрузка, ленивая инициализация, вот это все.
>звучит несколько категорично
Этот фактор чуть ли не единственный из всех напрямую влияет на сложность и устойчивость системы. Случаи, когда им можно торговать, можно по пальцам перечислить (быстрое прототипирование, одноразовые скрипты и прочие кейсы сильно ограниченного времени жизни системы).
>Сколько я бороздил энторнеты, под этим словом понимали сокрытие данных от доступа извне.
Специально залез в википузию - даже там в самом начале записано определение специально для бороздителей вроде тебя.
>полиморфизм (суть повторное использование кода)
Полиморфизм вообще не про это, еще в первых тредах писал. Полиморфизм - это в самом общем случае способность фунции обрабатывать значения разных типов, а в частном случае ООП - перекладывание ответственности за конкретную обработку данных на внешний объект посредством иерархии типов (чем образована эта иерархия - наследованием, миксинами, интерфейсами, утиными анусами - не суть, это уже детали).
Мне надо было уточнить тип полиморфизма, ты описал ad-hoc полиморфизм. Я имел ввиду параметрический полиморфизм.
наркоманы, вы бы так код хуярили как здесь пиздите
> Зачем пилить статический метод для работы с данными экземпляра? И при чем тут конструктор? Упаси б-же в конструкторе делать что-либо кроме проверки и присвоения пришедших на вход значений.
Я хотел донести простую мысль: сложный геттер передает вызов в фабричный метод, а писать тесты на код типа @переменная || вызвать исключение, это столь же отвратительно, как и тестировать что 2+2 равно четырем.
По остальному завтра, может быть, поболтаем.
>Ты хотел сказать, что программист не должен заниматься проектированием?
Если программист занимается проектированием, то это уже не программист.
Или ты хочешь сказать, что сварщик не должен заниматься проектированием?
Или электрик?
Или носитель кирпичей?
Или крановщик?
Да, программисту нужно принимать кое какие архитектурные решения, местечковые, но это и не предмет обсуждения.
Иногда ты сам себе и архитектор, и электрик. Но это опять таки, вне темы обсуждения.
Мы же говорим об индустрии в целом, а не о наколенных проэктиках.
А в индустрии так.
Кто-то где-то решил, что нужно использовать замыкания.
И ты хоть обосрись, но неприкасайся к for и прочим способами итерирования.
Только замыкания.
Больше замыканий богу замыканий.
Потому что так по уму, ООП лямбды ПМ воркфлоу ЕЙЧАРИНГ ТИМБИЛДИНГ круд МИТИНГ некогда объяснять делай замыкания.
Да ПМ - наверное не по наслышке знаком с программированием, и это, что, делает его внезапно очень вумным?
Прочитал книжечку про "правильный дизайн" и давай внедрять сии "знания" в жизнь.
Нужно начинать с того что 90% людей на планете идиоты, и 99.999% людей в IT не ушли интеллектом сильно дальше обезьян.
ПМы они там, или нет.
Разница между ПМом и рядовым макакеном в том, что ПМ не чувствует боль, от абстрактных фабрик хмл бобов. Теперь это проблема рядового макакена.
>Да и задачку с демонстрацией уровня развития сюда запостил, увы, не ПМ.
Не понимат о чем ты.
>википузию
Сам же и обозвал её некрасиво звучащим словом.
Там же у них «отличительная особенность русской семиструнной гитары — стальные струны» и спутники ГЛОНАСС вещяют на секретной военной частоте.
По делу если: в Смоллтоке не было ещё методов, были только сообщения, в Эрланге сокрытие данных сделано с помощью потоков и сообщений. Сокрытие данных — общий случай, доступ с помощью методов/интерфейсов — один из частных случаев (а википидоры... я скорее поверю анону с борд, чем им).
Что там оценивать, когда задача сформулирована неоднозначно, а ты этого даже не обнаружил в процессе реализации? Естественно, там говно по ссылке, не нужно даже заходить туда, чтобы это понять.
>сложный геттер передает вызов в фабричный метод
Это не единственное, что он делает.
>писать тесты отвратительно
Сидеть на дваче тоже, однако ж это тебе не мешает. Возможно, программирование - это попросту не твоё.
>Если программист занимается проектированием, то это уже не программист.
Если он им не занимается, то он макака, а не программист, потому как без умения самостоятельно выделять абстракции он никому не нужен.
>программисту нужно принимать кое какие архитектурные решения, местечковые, но это и не предмет обсуждения.
"Местечком" является как минимум весь вверенный программисту сегмент проекта, как максимум - вообще весь проект. У макак все иначе, но это и не предмет обсуждения.
>ТИМБИЛДИНГ
Устройся в нормальную контору и прекрати транслировать сюда свои личные катастрофы. Мы обсуждаем дизайн софта, а не традиции ООО "Залупа и сыновья".
>Не понимат о чем ты.
О том, что задачку СПРОЕКТИРОВАЛ некий программист или некто косплеящий оного, и спроектировал так, что даже беглый анализ показал кучу несуразностей. То есть некто, считающий себя программистом, неспособен даже логику сраных скидок описать без накладок - как же ему можно доверять пректирование программы?
>Если он им не занимается, то он макака, а не программист, потому как без умения самостоятельно выделять абстракции он никому не нужен.
Это уже демагогия.
>"Местечком" является как минимум весь вверенный программисту сегмент проекта, как максимум - вообще весь проект. У макак все иначе, но это и не предмет обсуждения.
Другими словами.
>Настоящий программист делает что хочет и пишет как вздумается.
>Макаки следуют паттернам и принятой в прожекте системе.
Это феноменальная глупость.
И если разобраться, простой психоз. Ты ищешь "козлов отпущения", пытаясь перенести свои собственные психические проблемы на мифических "макак", которые плохие, и все неверно понимают.
Если просто.
У тебя пригорело. И ты в стадии отрицания. Психоз это потому, что из стадии отрицания ты не выходишь.
>Устройся в нормальную контору и прекрати транслировать сюда свои личные катастрофы.
Ну вот, теперь МОЯ личность уже виновна во всех твоих проблемах.
>Мы обсуждаем
И ты настолько неуверен в себе, что говоришь от именин коллектива, которого кстати нет.
>дизайн софта, а не традиции ООО "Залупа и сыновья".
Тащемто, тред о традициях ООП
>О том, что задачку СПРОЕКТИРОВАЛ некий программист или некто косплеящий оного, и спроектировал так, что даже беглый анализ показал кучу несуразностей. То есть некто, считающий себя программистом, неспособен даже логику сраных скидок описать без накладок - как же ему можно доверять пректирование программы?
Наверное нельзя.
У меня нет инсайдов относительно личностных и профессиональных качеств проектировщика "задачки", о которой ты говоришь.
Возможно, он просто не хотел напрягаться.
В конце концов, картинкофорум предпологает общение с минимум усилий. Меньше чем свитер.
>Это уже демагогия
Сперва я подумал, что это ответ на один из моих тезисов, но, прочитав весь твой пост, понял, что это был его заголовок. Тонко, молодец.
>У тебя пригорело.
А вот тут толсто.
>картинкофорум предпологает общение с минимум усилий
Вот и не тужься зазря, грыжу заработаешь. А то для минимума усилий многовато букв генерируешь.
>Что там оценивать, когда задача сформулирована неоднозначно
Чего неоднозначного в задании "взять дохуялион выражений, и проверить их выполнение в определенном порядке"?
Некоторые из правил дали бы другой результат при другом порядке проверки? Некоторые из них не выполняются никогда? Какая в жопу разница.
Ты эксперт или школьник с синдромом отличника?
https://youtu.be/UoKlKx-3FcA
Сорян бротиш, я скриптогосподин и не умею скакать по десяти различным файлам для восприятия логики кода.
Мать твою ебал.
В чем разница между абстрактным классом и интерфейсом? И нахуй нужен последний? В документации просто сказано НУЖЕН НАРЯДУ С ДРУГИМИ. А даже мелкого примера нет.
не мешки ворочать
>Чего неоднозначного в задании
Я достаточно подробно расписал это вот здесь , повторяться для жопочтецов не вижу смысла.
>Ты эксперт или школьник с синдромом отличника?
Я просто умею внимательно читать таски и делать больно тем, кто пишет их недостаточно прозрачно.
Я обнаружил и реализовал так, как посчитал правильным. Если заказчик формулирует, как мудак - это его проблемы. Если что-то не нравится - пусть вносит корректировки в ТЗ, переделаю.
Чтобы было
Интерфейс - чистый контракт. В абстрактном классе, как правило, уже присутствует какая-то часть реализации.
>Я обнаружил и реализовал так, как посчитал правильным
Вот таких долбоебов в шею гоню нахуй сразу с работы, они очень дорого обходятся. Вместо того, чтобы сразу поставить в известность о проблеме, они там что-то хуем на клавиатуре настучат и еще носиком потом шмыгают - дескать, я художник, я так вижу. Убивал бы гадов.
Хотя скорее всего ты, конечно, ни хуя не обнаружил, а просто прочитал тяп-ляп и сделал тяп-ляп.
Он эволюционирует, а ты - нет.
Окей, вот у меня как раз была ситуация несколько дней назад: нужно было разработать достаточно сложный кусок по весьма расплывчатому тз. Клиент оффлайн был в течение недели. Что прикажешь делать, сидеть сложа ручки? А смысл? Придет, посмотрит, и либо внесет корректировки, либо нет.
>Что прикажешь делать
Завалить ебло.
>пук
Ясно.
>по весьма расплывчатому тз
Проблема в том, что вместо того, чтобы нормально проанализировать ТЗ в момент вручения и тут же дать обратную реакцию, сел стучать хуем по клавиатуре и слишком поздно обнаружил эту самую расплывчатость.
>оффлайн был в течение недели
Что мешало позвонить?
>Что прикажешь делать, сидеть сложа ручки?
Поставить задачу на холд и делать другие, если в пункте 1 из вышеприведенных ты обосрался, а пункт 2 по каким-то невероятным причинам невозможно осуществить.
Оно еще и обосралось.
Ты тоже нахуй иди.
>Проблема плохого проектирования выдается за проблему методологии.
Проблема плохого проектирования возникает из-за ебаного ООП, которое пихают абсолютно везде, где оно не нужно. Вместо того, чтобы проанализировать предметную область и выбрать правильный инструмент для решения конкретной задачи, архитекторы наверчивают объекты на объекты, ибо объекты сами не навертятся.
>Сидеть на дваче тоже, однако ж это тебе не мешает. Возможно, программирование - это попросту не твоё.
Пожалуй, сольюсь в диалоге и просто пошлю тебя нахуй с такими утверждениями.
Все время слышу эту мантру про "выбор правильного инструмента" и каждый раз проигрываю. Вот ты, например, расскажи случай из своей никчемной жизни, когда тебя заставили злые манагеры грызть объекты, а надо было что-то другое использовать. Ну же, удиви меня.
Это не программист должен выбирать, и не манагеры. А архитекторы, блять. Они должны довить на манагеров, а не наоборот. В моей никчемной работе в нашем маленьком стартапе, где мы сами себе архитекторы, я сам выбрал на чем писать бэкенд, хотя меня пытались заставить писать его на С++ (другие части проекта пишутся на нем, и была идея, чтобы библиотеки были у всех общими), но я всем пояснил, что это неправильно и почему это тупиковый путь.
Это ты выбрал платформу, а не методологию. На чем же ты пейсал свою часть на хаскеле, надеюсь?
На эрланге пишу.
А что за задача? Сетевой трафик, медиапотоки?
Потоки телеметрии.
Ну вот ты редчайший случай адеквата, значит. Значительно чаще корзинки жалуются, что им не дают шлепать круды на Кложе или на процедурках, в зависимости от полюса сдвига мозгов.
>А то для минимума усилий многовато букв генерируешь.
Ты видишь поблизости полицию?
>Ну вот ты редчайший случай адеквата, значит.
Нет.
Это репрезентативное большинство критики ООП.
>Значительно чаще корзинки жалуются
Это твои собственные фантазии и комплексы. Меньше в специальных олимпиадах участвуй.
>Проблема в том, что вместо того, чтобы нормально проанализировать ТЗ в момент вручения и тут же дать обратную реакцию,
Проблема в том, что ты акцентируешь внимание на второстепенных вещах. Что есть признак шизы кстати.
Переводя обсуждение в плоскость личности собеседников.
Ну какая разница насколько там правильно составлена задачка. Ты еще в школьных учебниках начни выискивать противоречия и несоответствия "зачем мне кому-то отдавать мои яблоки?"
акцентируешь внимание на второстепенных вещах. Что есть признак шизы
пошутил про шизу?
по поводу тз. нельзя прочитать и сразу увидеть не соответсвие. нужно запомнить, подумать, долго это.
а вообще, можно без набрасывания прототипа, спроектировать? я всегда стучу по кнопкам. это как изучать, читаешь и делаешь задачки. протоип, это как черновик.
>пошутил про шизу?
Нет.
Это один из признаков шизоидного расстройства.
>по поводу тз. нельзя прочитать и сразу увидеть не соответсвие. нужно запомнить, подумать, долго это.
Да.
Вообще, каждый программист доложен быть полно ознакомлен с техническим заданием и предметной областью. Если речь идет о создании качественного продукта.
К сожалению, ткнз ентерпрайз делает все с точностью наоборот. Чтобы ознакомить программиста, нужно чтобы он был в состоянии понимать, а это противоречит использованию низкоквалифицированных кадров.
Так или иначе, у нас тут речь о задачке уровня 1 курса университета.
>а вообще, можно без набрасывания прототипа, спроектировать?
Можно.
>я всегда стучу по кнопкам. это как изучать, читаешь и делаешь задачки. протоип, это как черновик.
Это ткнз "быстрая разработка".
Как правило, когда речь идет о сириус бизнесе, программисту ненужно ничего набрасывать.
Все уже спроектировано.
У программиста в руках определенная часть проекта, для которой у него уже есть 100 раз проверенное временем решением.
Ctrl+C ctrl+V, немного правок, и все готово.
>Как правило, когда речь идет о сириус бизнесе, программисту ненужно ничего набрасывать.
Справедливо для стандартного крудошлепства.
Почему вы еще не переходите на функциональное программирование? Это стильно, модно, молодежно.
>Я достаточно подробно расписал
Как шкальник придрался к деталям, не имеющим отношения к сути задачи.
Причем если подумать головой, то задание хоть и недостаточно формально описано, но понятно здоровому человеку.
Врочем, хуй знает, что полотнища говнокода дадут данному срачетреду.
Короче, рядом валялась линейка и я тоже решил измерить свой ооп-хуй: http://бр4.org/s/res/90.html#725
>/s/res/90.html#725
Не знаю про твой гомокод на гомоязыке, но ссылки ты вставляешь через жопу.
>бр4
Надо заменить.
Лол, а еше в последнем методе я обосрался аж два раза.
Ссылку нормальную запили, я нихуя не понял, чего на что нужно заменить.
Да там вообще все надо заменить. Мне пришлось по номеру треда и поста искать о чем ты.
Я был слеп но я прозрел. Есть лишь рекурсивная структура рантайма и контекст. Вся хуета с объектами это пляски вокруг переопределения контекста в хаосе пузырящейся памяти.
Тред #2:
Тред #1: