Вы шикарно ставите задачи… Что такое мешки с сахаром? Это записи в базе или объекты в памяти.
Если объекты в памяти, то должен быть очевидно список. Соответственно должен быть итератор. На итераторе реализуете, например, стандартные map/reduce и делаете выборки и аггрегации. Почитайте еще раз внимательно с карандашом и бумажкой паттерны проектирования банды четырех. Там всё разжёвано…
Хотя задача которую вы описываете, это обычно работа базы данных…
На счет вашего примера, просто определите сущности которыми вы оперируете в этой задаче и метод реализации на ООП почти сразу станет очевидным… Что такое, например, у вас «аггрегированные данные»? Какие общие свойства нужные вам у всех этих «аггрегированных данных»?
Исходя из темы статьи и реплики amarao про «клиентов чьи задачи хорошо ложатся на ООП», я полагал, что речь идёт о классе задач для которых актуальны понятия проектирование, паттерны проектирования и функциональная декомпозиция. И полагал, что меня поймут.
Вы привели какую-то, типа, задачу про элементарный тип чисел. Потом, правда, ваши коллеги «уточнили», что числа на самом деле сложные, а то и вообще матрицы… В общем настоящих программистов видно сразу по постановке задачи…
А дальше оказывается, что речь идет не о «ложится/не ложится». а о «лучше/хуже». В общем, мне нечего вам сказать. Классика хабра… )))
То, что есть классы задач, для которых другие парадигмы лучше и эффективней это самоочевидно. Иначе бы эти парадигмы вообще не появились на свет…
Давайте еще обсудим задачу помещения 32-битного значения в регистр процессора…
Расскажите мне про архитектуру приложения, решающую эту задачу, про функциональную декомпозицию, и паттерны проектирования, которые вы собираетесь применить при решении этой задачи.
Детский сад какой-то… Статью-то читали?
Операции над элементарными типами реализуются компилятором/интерпретатором. ООП тут вообще не нужен. На счет структур а ля комплексные числа, если вы не в курсе, есть масса языков где на классах можно определять операции. В том числе и сложение. Там ничего плохого не наблюдается. Примеров приводить не буду, вряд ли вам это интересно…
Судя по вашей активной поддержке плюсами-минусами на банальной теме, вы обычный хабро-тролль. Извините, не сразу понял…
Хм… Вы заставляете меня сомневаться в ваших компетенции. Что такое ООП в вашем понимании? Как в вашем понимании соотносится ООП и система элементарных типов языка?
В смысле? Если я пойму первое, то станет очевидно и второе. И наоборот.
Если верить автору, то это оба этих множества задач дополняют друг друга до множества всех задач…
Такой вариант рассматривался, но… Приводов у нас было всего два. Основной и резервный на случай выхода из строя основного. Конкретная модель привода не помню уже, но на тот момент такие приводы уже не производились. Так что решили, это не вариант…
Ленты имеет смысл держать только тем, у кого уже большой архив на лентах. Проблема с ними в том, что если привод вдруг сдох или просто перестал читать ленты, то все начинаются реальные проблемы.
История из жизни: Банк, бакапы опердня на лентах. В один прекрасный день вдруг понадобилось вытащить данные двухгодичной давности. Выяснилось, что лента не читается. По какой-то причине сместилась головка. Причем сбилась около года назад. Свежие ленты читаются, старые нет. Головку поправили. Теперь старые ленты читаются, новые нет… Геморроя было неимоверное количество, учитывая что сервис по ремонту приводов в Москве, а банк в Сибири. После этого предпочли перелить все бакапы на винты…
А можно подробней про версию железа UniFi и версию контроллера? Мы у себя в коворкинге активно использует Unifi, нас проблем с хендовером не было. перекосы по трафику устранили шейпингом. У нас это работало вполне приемлемо…
Что такое «справедливое распределение времени»?
Судя по плану, речь идет о коворкинге WorkStation. Был там этим летом, не сказал бы, что там WiFi работает идеально.
Мне ничего не мешало и проблем у меня не было. У меня в конечном счете сложились нормальные отношения с ИБ. Я помогал им решать их проблемы, а они не мешали мне выполнять мою работу. Все люди, независимо от профессиональной принадлежности…
Горячие линии, угнетаемый работник?! Что это? 0_о
Это вообще-то было в середине 90-х прошлого века. Да и угнетать меня было проблематично, я уже тогда отлично знал, что такое «жить по уставу» или, как теперь модно говорить, итальянская забастовка. Достаточно начать скурпулезно выполнять инструкции отдела ИБ и через некоторое время они и руководство сами начинали выть… ))
Служба безопасности на любом мало-мальски крупном предприятии это вотчина конторских пенсионеров. Причем слово «информационная» в ИБ для них пустой звук. Цель всех инструкций и актов как раз и заключается в снятии ответственности со службы безопасности. Они запрещают всё, и если вдруг что-то таки случится, то «они предупреждали». Ну и наказывать нарушителей — это самая приятная их обязанность…
На своей первой работе сталкиваясь с таким подоходом со стороны СБ, я тоже психовал по началу. Потом успокоился. Просто делал свою работу и всё… Обычно на практике у них просто не хватает квалификации, чтобы понять что делают айтишники. Поэтому особых проблем с ними не возникает…
Конечно бывает попадаются особо ретивые. Тогда хоть увольняйся, жизни не будет. Но подобная ретивость у этой братии обычно не от большого ума…
Для ембеддчика осваивать интернетовский back-end — это пожалуй всё же перебор… С таким же успехом можно советовать спецам по bigdata покодить ADC, PWM на MIPS-ядрах.
Максимум принципы организации api для сетевого взаимодействия. Голова ведь не резиновая и люди работают чтобы жить, а не наоборот…
0_о а перехват зачем? всё что вам нужно — это запихнуть число и вернуть его обратно… Утечки памяти, IMHO, лучше отслеживать нагрузочным тестированием, а не юнит-тестами…
eof() вообще практически ничего не добавил бы. Он бы тупо инлайнился в коде… По стоимости это ничем не отличается от сравнения результата двух int'ов, который пришлось бы делать в варианте без eof()…
Именно три функции вместо двух… Это типовое решение. Никакой необходимости изобретать велосипед нет.
Вы ни как не сможете заставить программиста использовать правильно ваше api.
Если объекты в памяти, то должен быть очевидно список. Соответственно должен быть итератор. На итераторе реализуете, например, стандартные map/reduce и делаете выборки и аггрегации. Почитайте еще раз внимательно с карандашом и бумажкой паттерны проектирования банды четырех. Там всё разжёвано…
Хотя задача которую вы описываете, это обычно работа базы данных…
Вы привели какую-то, типа, задачу про элементарный тип чисел. Потом, правда, ваши коллеги «уточнили», что числа на самом деле сложные, а то и вообще матрицы… В общем настоящих программистов видно сразу по постановке задачи…
А дальше оказывается, что речь идет не о «ложится/не ложится». а о «лучше/хуже». В общем, мне нечего вам сказать. Классика хабра… )))
То, что есть классы задач, для которых другие парадигмы лучше и эффективней это самоочевидно. Иначе бы эти парадигмы вообще не появились на свет…
Расскажите мне про архитектуру приложения, решающую эту задачу, про функциональную декомпозицию, и паттерны проектирования, которые вы собираетесь применить при решении этой задачи.
Детский сад какой-то… Статью-то читали?
Судя по вашей активной поддержке плюсами-минусами на банальной теме, вы обычный хабро-тролль. Извините, не сразу понял…
Если верить автору, то это оба этих множества задач дополняют друг друга до множества всех задач…
История из жизни: Банк, бакапы опердня на лентах. В один прекрасный день вдруг понадобилось вытащить данные двухгодичной давности. Выяснилось, что лента не читается. По какой-то причине сместилась головка. Причем сбилась около года назад. Свежие ленты читаются, старые нет. Головку поправили. Теперь старые ленты читаются, новые нет… Геморроя было неимоверное количество, учитывая что сервис по ремонту приводов в Москве, а банк в Сибири. После этого предпочли перелить все бакапы на винты…
Что такое «справедливое распределение времени»?
Судя по плану, речь идет о коворкинге WorkStation. Был там этим летом, не сказал бы, что там WiFi работает идеально.
Горячие линии, угнетаемый работник?! Что это? 0_о
Это вообще-то было в середине 90-х прошлого века. Да и угнетать меня было проблематично, я уже тогда отлично знал, что такое «жить по уставу» или, как теперь модно говорить, итальянская забастовка. Достаточно начать скурпулезно выполнять инструкции отдела ИБ и через некоторое время они и руководство сами начинали выть… ))
На своей первой работе сталкиваясь с таким подоходом со стороны СБ, я тоже психовал по началу. Потом успокоился. Просто делал свою работу и всё… Обычно на практике у них просто не хватает квалификации, чтобы понять что делают айтишники. Поэтому особых проблем с ними не возникает…
Конечно бывает попадаются особо ретивые. Тогда хоть увольняйся, жизни не будет. Но подобная ретивость у этой братии обычно не от большого ума…
Максимум принципы организации api для сетевого взаимодействия. Голова ведь не резиновая и люди работают чтобы жить, а не наоборот…
Вот именно. И тогда все эти костыли для тестирования становятся не нужны…
Вы ни как не сможете заставить программиста использовать правильно ваше api.