Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 81
зато можно сделать не просто хлеборезку, а
Нож, который будет резать все, что ему дадут. Это и есть создание инструментов вместо грубого ручного труда каждый раз
Просто нож — это уже устарело. Надо уже нож со сменными насадками (для хлеба, для мяса,...)- более современно и универсально. Правда, еще надо будет функцию дописать — «смена_насадки».
DI как механизм для насадок в самый раз :)
Очень удобно нарезать хлеб, создавая у него метод нарезки через фабрику резалок! Лучше это делать в конструкторе.
var bread = new Bread();
bread.cutter = Factory.cutter( bread );
bread.cutter.cut()
Нож со сменными насадками тоже устарело.
Зачем мне
Нож, которым можно резать все, что дадут, если мне нужно нарезать хлеб? (Конечно, если вы не хотите, чтобы вашу хлеборезку можно было потом легко переделать в жатку зерноуборочного комбайна или, например, сделать из нее оружие против зомби)
А как вы себе представляете нарезку хлеба без ножа? Ниткой? Или так?
Вы выполните поставленную задачу, и не нужно будет писать отдельную функцию «нарезать»
куски множество_кусков = [количество_кусков];
for ( int счетчик = 0; счетчик < количество_кусков; ++счетчик )
{
множество_кусков[счетчик] = хлеб->мякиш / количество_кусков;
}Вы выполните поставленную задачу, и не нужно будет писать отдельную функцию «нарезать»
Я имел в виду не совсем это. Я совсем не предлагал резать хлеб ниткой или кредитной картой вместо ножа.
Вот предположим, что мне нужно нарезать хлеб. Просто нарезать хлеб, и ничего больше.
Для этого я хочу взять нож, отрезать хлеб, и забыть навсегда о хлебе и ножах.
Как другой вариант, мне предлагают использовать (или даже сделать самому) ФабрикуРежущихИнструментов, чтобы создать УниверсальныйМегаНож, которым можно резать что угодно. Для УниверсальногоМегаНожа мне нужно сделать ЛезвиеДляХлеба (лезвия съемные, на все случаи жизни, не забывайте). При этом мне нужно знать, какое именно Лезвие я хочу сделать, ведь ФабрикаРежущихИнструментов делает любые лезвия, и мне нужно настроить ее так, чтобы она сделала то лезвие, который идеально мне подойдет. Раобраться в том, какие вообще лезвия я могу произвести, выбрать из них то, которое мне подходит больше всего, и наконец изготовить.
После этого я, довольный собой, устанавливаю ЛезвиеДляХлеба в УниверсальныйМегаНож, режу хлеб, и… забываю навсегда о хлебе и ножах?
Конечно, ФабрикуРежущихИнструментов можно потом использовать для других целей. Да и УниверсальныйМегаНож, наверное тоже. Но я хотел сказать, что здесь важно знать меру. Иначе может получится, что мы сделали ФабрикуРежущихИнструментов в расчете на то, что сможем каждый раз делать подходящие инструменты, а потом оказалось, что кроме хлеба и резать-то нечего.
Вот предположим, что мне нужно нарезать хлеб. Просто нарезать хлеб, и ничего больше.
Для этого я хочу взять нож, отрезать хлеб, и забыть навсегда о хлебе и ножах.
Как другой вариант, мне предлагают использовать (или даже сделать самому) ФабрикуРежущихИнструментов, чтобы создать УниверсальныйМегаНож, которым можно резать что угодно. Для УниверсальногоМегаНожа мне нужно сделать ЛезвиеДляХлеба (лезвия съемные, на все случаи жизни, не забывайте). При этом мне нужно знать, какое именно Лезвие я хочу сделать, ведь ФабрикаРежущихИнструментов делает любые лезвия, и мне нужно настроить ее так, чтобы она сделала то лезвие, который идеально мне подойдет. Раобраться в том, какие вообще лезвия я могу произвести, выбрать из них то, которое мне подходит больше всего, и наконец изготовить.
После этого я, довольный собой, устанавливаю ЛезвиеДляХлеба в УниверсальныйМегаНож, режу хлеб, и… забываю навсегда о хлебе и ножах?
Конечно, ФабрикуРежущихИнструментов можно потом использовать для других целей. Да и УниверсальныйМегаНож, наверное тоже. Но я хотел сказать, что здесь важно знать меру. Иначе может получится, что мы сделали ФабрикуРежущихИнструментов в расчете на то, что сможем каждый раз делать подходящие инструменты, а потом оказалось, что кроме хлеба и резать-то нечего.
Именно поэтому выгодно брать не Нож, а Фабрику Режущих Инструментов, которая сможет создавать хлеборезки, оружие против зомби и комбайны.
Ну Вы же сами прекрасно понимаете, что первый вариант работает только на тривиальных задачах? А кроме того даже сейчас никто не запрещает нарезать хлеб функцией. Кроме того, хлеборезка может резать не только хлеб но и батоны и колбасу и всё остальное что наследуется от класса «мягкая небольшая еда».
Если ядро Linux — это тривиальная задача, то я с вами соглашусь =)
У линукса есть преимущество — он покрыл всё железо и работает. Но неприятных моментов в нём такое количество, что только ой. Чего стоит например, возможность любому драйверу звуковой карты обрушить сервер любой сложности.
А зачем нужен драйвер звуковой карты на сервере? :)
Use kernel preemption, Luke!
Простите, что? Возможность вытеснять часть кода ядра скедулером? Как это поможет от кривого драйвера?
«There are two main benefits to this method in monolithic and hybrid kernels, and answer one of the main criticisms of monolithic kernels from microkernel advocates, which is that;
1) A device driver can enter an infinite loop or other unrecoverable state, crashing the whole system
2)Some drivers and system calls on monolithic kernels are slow to execute, and can't return control of the processor to the scheduler or other program until they complete execution.»
1) A device driver can enter an infinite loop or other unrecoverable state, crashing the whole system
2)Some drivers and system calls on monolithic kernels are slow to execute, and can't return control of the processor to the scheduler or other program until they complete execution.»
Как это спасёт от банального oops? Записал в памяти не туда — panic, прочитал не оттуда — panic, ушёл в дедлок в нижней части прерывания — panic.
Расширим список: разлил админ кофе на сервер — oops, случилось наводнение — panic, упала атомная бомба рядом — panicpanicpanic.
1) В стойку нельзя разлить кофе :)
2) Случилось наводнение — а зал на высоте
3) В атомную бомбу я верю меньше, чем в кривой драйвер HID и неадекватную реакцию ядра на втыкание странной клавиатуры.
2) Случилось наводнение — а зал на высоте
3) В атомную бомбу я верю меньше, чем в кривой драйвер HID и неадекватную реакцию ядра на втыкание странной клавиатуры.
В нём так же есть возможность не собирать ненужные драйвера и не загружать собранные, вы же знаете.
И вы действительно на RHEL'е будете собирать СВОЁ ядро вместо штатного от RH? Ну-ну.
Во-первых это «неприятный момент» не линукса, а вашей модели использования дистрибутива.
Во-вторых, воспользуйтесь таки /etc/modprobe.d/blacklist.conf или как он в RHEL называется.
В-третьих, не вижу большой проблемы собрать своё ядро, при наличии src.rpm. Время от времени я так и делаю, правда для федоры.
Во-вторых, воспользуйтесь таки /etc/modprobe.d/blacklist.conf или как он в RHEL называется.
В-третьих, не вижу большой проблемы собрать своё ядро, при наличии src.rpm. Время от времени я так и делаю, правда для федоры.
Надеюсь, вы понимаете разницу между федорой и RHEL'ом? Насчёт blacklist — блеклистить всё — особое развлечение админа.
Кроме того, какой из драйверов вы собираетесь блеклистить? USB-SATA? USB-Firewire? Их же тысячи, а ошибка может быть в банальном USB-HID для мышки.
Проблема тут в другом — в том, что второстепенный драйвер второстепенного устройства может уронить mission-critical задачу.
Кроме того, какой из драйверов вы собираетесь блеклистить? USB-SATA? USB-Firewire? Их же тысячи, а ошибка может быть в банальном USB-HID для мышки.
Проблема тут в другом — в том, что второстепенный драйвер второстепенного устройства может уронить mission-critical задачу.
Насчёт blacklist — блеклистить всё — особое развлечение админа.
find + sed — это скорее обычное развлечение.
Кроме того, какой из драйверов вы собираетесь блеклистить?
Вы могли бы блеклистить все драйвера которым вы не доверяете.
Проблема тут в другом — в том, что второстепенный драйвер второстепенного устройства может уронить mission-critical задачу.
У вас были такие случаи на практике? Что же вы предпринимали в качестве контрмер?
Первый вариант прекрасно работает в языках с функциональной парадигмой, в которой благодаря этому толпа навороченных паттернов типа фабрик и прочего тупо становится ненужной
Содержание исходного поста передано неполно.
Дальше идет:
1. Резалка — интерфейс к хлеборезке (или ножу);
2. Фабрика резалок;
3. IoC контейнер, служащий для поиска фабрики;
4. Средство конфигурации IoC контейнера на основе xml-файла;
5. Специализированный редактор конфигурационных файлов;
6. Средство для автоматической генерации специализированных редакторов на основе спецификации на промежуточном языке;
7. Препроцессор промежуточного языка с поддержкой модульности.
Дальше идет:
1. Резалка — интерфейс к хлеборезке (или ножу);
2. Фабрика резалок;
3. IoC контейнер, служащий для поиска фабрики;
4. Средство конфигурации IoC контейнера на основе xml-файла;
5. Специализированный редактор конфигурационных файлов;
6. Средство для автоматической генерации специализированных редакторов на основе спецификации на промежуточном языке;
7. Препроцессор промежуточного языка с поддержкой модульности.
Вы еще забыли про паттерн костыль чтобы все это дело после небольших изменений как-то продолжило работать :)
Достаточно. Всё Java-фрэймворки уже перешли на аннотации вместо xml-конфигураций. Пункты 4,5,6,7 можно исключить. Уж не знаю как там у вас в дотнете.
>>new Хлеборезка()
это круто)
это круто)
Пища пища=new Хлеб(Хлеб.тип.Белый);
Резалки резалка = new пища.получитьРезалку().class();
резалка.резать(пища);
Кто глубже?
Резалки резалка = new пища.получитьРезалку().class();
резалка.резать(пища);
Кто глубже?
Забыл обновить, опередили
Получи велосипеды!
www.youtube.com/watch?v=tZuUNMwWhOU
www.youtube.com/watch?v=tZuUNMwWhOU
Напомнило метафору «земля.Копайся()» из поста Применимость DDD и последующую дискуссию в комментах.
И тем не менее если надо сделать много работы, которую кто то уже делал, то фреймворки помогают. Фрейворки экономят очень мнгоо времени, когда работы много и она более менее стандартна. Я видел самописные ORM. Если бы их создатели использовали Hibernate или что то подобное, они бы сэкономили много усилий.
А когда я начал изпользовать Spring, у меня появились возможности, которых бы не было иначе, я бы просто не додумался.
такое печатление, что автор делает выводы о полезности фреймворков на основе того, насколько они полезн6ы для написания Hello World
А когда я начал изпользовать Spring, у меня появились возможности, которых бы не было иначе, я бы просто не додумался.
такое печатление, что автор делает выводы о полезности фреймворков на основе того, насколько они полезн6ы для написания Hello World
> Хлеборезка хлеборезка = new Хлеборезка();
Насколько я знаю в яваскриптах можно и так:
или даже так:
Насколько я знаю в яваскриптах можно и так:
Рукомойник рукомойник = new Хлеборезка();или даже так:
Хлеборезка хлеборезка = new Рукомойник();
А чего источник не указали?
www.johndcook.com/blog/2012/03/18/sliced-bread/
www.johndcook.com/blog/2012/03/18/sliced-bread/
Аналогии неправильные. Когда я слышу «фреймворки не нужны», это значит, что человек либо не умеет ими пользоваться, либо просто взял не тот инструмент для решения задачи и ругается.
Проводя аналогии, например IC и DI — это стандартные розетки и провода для хлеборезки. То есть до них все делали свою хлеборезку со своим собственным дизелем, своим типом двигателя и своим напряжением питания (а кто-то вообще на бензине), а потом догадались сделать розетку на 220В и 50 Гц и пошл-поехало. А теперь вот приходят люди и говорят: мне не нужна розетка на 220В, я свой дизель-генератор лучше соберу. Ну хозяин-барин, конечно.
Другой вопрос, что ява-фреймоврки излишне утяжелены и усложнены, но это уже не мои проблемы. Также, люди любят делать излишнюю расширяемость: например, нарежут все на кучу абстрактных классов и фабрик с наследоваием, вместо того, чтобы написать if/else. У нас в PHP такой проблемы нет: хочешь, пиши фреймворки с XML-конфигами и DI, хочешь пиши через функции и глобальные переменные.
Проводя аналогии, например IC и DI — это стандартные розетки и провода для хлеборезки. То есть до них все делали свою хлеборезку со своим собственным дизелем, своим типом двигателя и своим напряжением питания (а кто-то вообще на бензине), а потом догадались сделать розетку на 220В и 50 Гц и пошл-поехало. А теперь вот приходят люди и говорят: мне не нужна розетка на 220В, я свой дизель-генератор лучше соберу. Ну хозяин-барин, конечно.
Другой вопрос, что ява-фреймоврки излишне утяжелены и усложнены, но это уже не мои проблемы. Также, люди любят делать излишнюю расширяемость: например, нарежут все на кучу абстрактных классов и фабрик с наследоваием, вместо того, чтобы написать if/else. У нас в PHP такой проблемы нет: хочешь, пиши фреймворки с XML-конфигами и DI, хочешь пиши через функции и глобальные переменные.
Такой код нужно читать вслух и с выражением. Чего стоит только
global_нарезанный.push(кусок);
Сконфигурировать проще второй, поскольку его файл конфигурации еще не превратился в программу на мета-языке.
А забирать в другой проект… я лучше уволюсь.
А забирать в другой проект… я лучше уволюсь.
Ни тот ни другой
На какой сам сядешь, на какой мать посадишь?
Код на русском выглядит так знаком по 1С…
Процедура ОбработкаВнешнегоСобытия(Кто,Что,Зачем)
Если Кто="LRC_Modem" Тогда
Если Что="LRC_Modem" Тогда
Сообщить(Зачем);
КонецЕсли;
КонецЕсли;
КонецПроцедуры //ОбработкаВнешнегоСобытия
Изврат по фреймворковски:
fact = new FactoryCreatorFactory()
conf = new BladeConfigurator()
fact.add(conf)
conf.setMaterial(new Ferrum())
realBladeFactory = fact.buildFactory()
realBladeFactory.setLength(400)
realBladeFactory.setWeight(30)
realBladeFactory.addFacet(new BladeFacet('teeth')) // for more usable bread slicing
blade = realBladeFactory.buildRealBlade()
blade.sharpen()
blade.wash()
bread = realWorldSingleton::getInstance().getStorageCollection().getFoodStorage().getBread()
bread.sliceYouSelfBy(blade)
//profit :)
Можно гыгыкать сколько угодно, но хлеб всё-таки сам себя без привлечения других сущностей не нарежет. Если вас устраивает хлеб, наломанный голыми руками — то пожалуйста. Но самое интересное, что руки тоже кому-то принадлжат.
Так что — так себе аналогия. ООП не так уж глупо, как его хотят выставить.
Так что — так себе аналогия. ООП не так уж глупо, как его хотят выставить.
Вспомнилось: в колхозе «Рассвет» был сделан первый в мире комбайн по уборке грибов!
Теперь водителю осталось только найти и гриб и оп… остальное дело техники.
Теперь водителю осталось только найти и гриб и оп… остальное дело техники.
Пойду поем
У меня так
$cutted = Bread::Instance() -> getSlices(n);
$cutted = Bread::Instance() -> useBlade(«razor») -> getSlices(n);
ну и тд.
$cutted = Bread::Instance() -> getSlices(n);
$cutted = Bread::Instance() -> useBlade(«razor») -> getSlices(n);
ну и тд.
Современный подход к ООП — это ещё не самое страшное: всегда можно создать специальный язык программирования для нарезания хлеба. И это я не про DSL на Lisp, а про настоящий — со своими синтаксисом, компилятором и стандартной библиотекой. Тогда решить задачу нарезки хлеба будет очень просто:
Но нужно будет установить 100 МБ софта для компиляции этого кода, а также подождать годик-другой, пока стабилизируется инструментарий, исправятся баги и производительность достигнет приемлемого уровня.
А потом кто-нибудь напишет на нём фреймворк...
sliced_bread := Bread new sliceНо нужно будет установить 100 МБ софта для компиляции этого кода, а также подождать годик-другой, пока стабилизируется инструментарий, исправятся баги и производительность достигнет приемлемого уровня.
Шутки шутками… но бедным заказчикам приходится терпеть последствия вот такого (все выше предложенное) полета фантазии разработчиков… а ведь заказчику просто хотелось 'покушать хлеба'.
Я к тому что не стоит забывать собственно ту самую главную цель, ради чего затевается разработка чего-либо… спускаясь вниз по цепочки модулей и плагинов, подклассов и фреймворков не забывать о первоочередной цели. Иногда действительно может быть достаточно просто 'нарезать_хлеб(хлеб)'.
Я к тому что не стоит забывать собственно ту самую главную цель, ради чего затевается разработка чего-либо… спускаясь вниз по цепочки модулей и плагинов, подклассов и фреймворков не забывать о первоочередной цели. Иногда действительно может быть достаточно просто 'нарезать_хлеб(хлеб)'.
А ведь еще раньше, все было еще лучше.
(нарезать хлеб)
(нарезать хлеб колбаса сыр овощи)
(смешать (нарезать овощи сыр) масло)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Программа для нарезки хлеба