c> Принципы декомпозиции должны преподаваться в школах. Декомпозиция это такая же базовая вещь, как таблица умножения... Я не говорю об основах алгоритмики. Я говорю об ОО проектировании. Это совсем другое.
А нахрен это ОО сдалось? Если учить — то SICP, чтобы показать, что ОО-проектирование — всего лишь один из способов решать проблемы. Не всегда самый удачный
Здравствуйте, Mamut, Вы писали:
c>> Принципы декомпозиции должны преподаваться в школах. Декомпозиция это такая же базовая вещь, как таблица умножения... Я не говорю об основах алгоритмики. Я говорю об ОО проектировании. Это совсем другое.
M>А нахрен это ОО сдалось?
Мамут, Вы программист? Почему тогда задаете такие глупые вопросы?
M>Если учить — то SICP, чтобы показать, что ОО-проектирование — всего лишь один из способов решать проблемы. Не всегда самый удачный
Но в большинстве случаев самый удачный именно потому его надо изучать максимально тщательно.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, vdimas, Вы писали:
V>>А распиши, плиз, кол-во часов (или минут) на каждый из упомянутых тобой паттернов. C>Мне за это заплатят?
Не обязательно тщательно, достаточно навскидку для десятка перечисленных. Поинт в том, что ты сам увидишь достаточность факультативного или самостоятельного изучения подобного материала.
V>>И что вообще за постановка вопроса... С каких это пор надо сразу давать ответы задач, вместо обучения навыкам их C>Каких еще ответов? Вы вообще понимаете о чем идет речь? C>Речь идет о приемах/техниках ОО проектирования, а не о решении каких-то там задач.
Мдеее... Типа, кроме ГОФовских паттернов других способов решения задач быть не может. Насчет "ответов" могу привести аналогию с теми же теоремами из математики: студендов именно учат доказывать теоремы, а не просто запоминать их формулировки. Вот ты настаиваешь исключительно на втором, а это вредительство, будучи применённым к процессу _обучения_.
C>Вот, например, один из самых известных и широкоприменяемых паттернов (точнее целое семейство паттернов на базе этой концепции) http://en.wikipedia.org/wiki/Model_view_controller
Молиться на MVC по мне — признак ламерства. Хотя бы потому, что, во-первых, документ-вью для многих сценариев тоже хорош и по-ныне, во-вторых, даже это не важно. Более общее название этих паттернов: "каждый должен заниматься своим делом". И вот этот более общий подход куда как полезнее, т.к. работает даже для задач, где нет GUI.
Ты просто не понимаешь, откуда столько фокуса на этот несчастный MVC и прочие презентеры, модели и т.д. Дело в том, что исторически все популярные ср-ва разработки (бери Дельфи или дизайнер WinForms в VS или еще раньше дизайнеры VB) поддерживают лишь метод проектирования GUI и обслуживающего кода, под условным названием "всё в кучу". Хорошо хоть в WinForms хоть как-то обобщили биндинг, что стало возможным из этой грязи вытянуть обособить хотя бы данные (произвольные, а не только от провайдеров, аналогичных провайдерам доступа к БД, как это было в Дельфи и дизайнерах VB). Тем не менее, используя CompositeUI AppBlock, который является неплохим базисом для реализации паттерна MVC/сотоварищи, практически все надо делать и связывать ручками. Итак, на одной чаше весов много работы руками, на другой — прекрасная поддержка визуальных дизайнеров. Понятное дело, что на первую чашу весов дополнительно необходимо положить хоть что-то, например устроить шум и возню с агитацией за паттерны MVC.
Я лично не собираюсь отказываться от экономии времени (используя дизайнеры), поэтому активно использую компромиссный подход, который можно назвать service-view, в идеологию которого спокойно лезет как doc-view, так и MVC и иже с ним (ибо service — это "черный ящик" с т.з. view). К чему я это? Обязательно ли делать view так же через абстрактные интерфейсы? Натасканные на паттерны ламеры в этом вопросе будут следовать букве паттернов, а не условиям конкретной задачи, тратя лишние ресурсы времени и не понимая простой задачи этих паттернов: убрать логику приложения из классов GUI. Собсно, почему я и отношусь недоверчиво к "шумихе" вокруг паттернов, которая зачастую противопоставляется здравому смыслу.
V>>решения? (и напомню опять же про неуниверсальность подобного "знания") C>По ссылке выше посмотрите на перечень "Implementation". Потом вспомните про все разнообразие веб фреймворков, построенных на базе одной из разновидностей данного патерна, вспомните про WPF prism, который базируется на разновидносте этого паттерна, называемой Model-ViewModel-View.
Еще раз крупными буквами: есть целые области из IT где конкретно это семейство паттернов как собачке стоп-сигнал.
C>Транспортная задача (а так же конечно же методы ее решения) широко преподается на IT факультетах всех ВУЗов мира. В том числе, к примеру, в Стэндфорте. Вы об этом не знали? Будете знать.
Ок, сколько часов эту задачу преподавали тебе? формулировка "преподавать задачу" — та еще...
Насколько я помню, мы по ней прошлись в контексте симлекс-методов, которые являются куда как более общим инструментом (а значит более полезным). Пользуясь твоей формулировкой можно сказать, что задачи раскроя тоже широко преподаются на IT факультетах... В общем, наверно не понимаешь, что именно тебе хотят сказать... а говорилось, что акценты ставишь не на том. В ВУЗах надо учить _методам_ решения задач. Заранее согласен лишь с тем, что пока не придумали лучшего способа закрепления теории, чем через практическое решение задач, но от этого конкретные решенные в процессе практики задачи все равно не становятся важнее применённых при их решении методов.
Здравствуйте, criosray, Вы писали:
V>>Даже по сравнению с линейным программированием (чуть ли не первая изучаемая прикладная мат. область в ВУЗе) "изучение" паттернов представляется полной ерундой в плане сложности. C>А разве полезность изучения чего-то определяется сложностью?
Полезность включения в программу ВУЗ-а — несомненно. Не ты первый "изобрел" еще в студенчестве большую часть паттернов из GOF, это лишь означает, что подобный материал заведомо легко изучим самостоятельно. Тем более, что среди этого семейства есть спорные паттерны, наподобие интерпретатора или визитора, которые требуют куда как более глубокой подачи.
Лично я не против, чтобы паттернам посвятили несколько _практических_ занятий. Но изучать на лекциях — увольте.
V>>К тому же, большинство паттернов из GOF вовсе не универсальны, а применимы лишь к языкам, с устройством полиморфизма, C>Ну это логично, разве нет? Ведь паттерны называются "Паттерны ООП". Где вы видели ООП без полиморфизма/инкасуляции/наследования?
Полиморфизм-то разный бывает. При наличии утиного полиморфизма большинство паттернов упрощается до неузнаваемости или даже отпадает за ненадобностью. А в агентной среде — так того хуже.
C>Не забудьте добавить python, ruby, VB и т.д, и т.п.
Не забыл и озвучил, что там происходит.
C>Не понял... При чем тут XML и джависты. XML просто удобный формат для представления иерархической структуры в текстовом виде. Всего-то.
А что тут не понять? Фетишем можно сделать любую полезную вещь, если использовать не по назначению.
Здравствуйте, criosray, Вы писали:
M>>Если учить — то SICP, чтобы показать, что ОО-проектирование — всего лишь один из способов решать проблемы. Не всегда самый удачный C>Но в большинстве случаев самый удачный именно потому его надо изучать максимально тщательно.
В пресловутом "большинстве случаев" объектное представление лучше всего ложится на человеческие представления о задаче. Беда в том, что эти самые представления в том же "большинстве случаев", как бы это сказать помягче, слишком идеализированы. То есть — не правильны, не отражают всей полноты задачи и всего комплекта ограничений и последствий. Получается каша и нервное расстройство. Хотя не буду спорить, что иной раз наивные представления срабатывают вполне приемлемо.
Например, как это и парадоксально, но тот же LSP противоречит простейшему субъективному "взгляду" на проблему. Собственно, живой пример — это пресловутые IoC-контейнеры, которые просто едут напролом супротив LSP: одна только непредсказуемость набора типов, загруженных в IoC уже многого стоит.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, criosray, Вы писали:
V>>наподобие реализованного в ObjectPascal/Java/C++/C#. C>Замечательно. Это покрывает 99% языков, применяемых на практике в современном мире. Не забудьте добавить python, ruby, VB и т.д, и т.п.
питон и руби не надо, там свои существенно другие паттерны.
Здравствуйте, criosray, Вы писали:
c> c>> Принципы декомпозиции должны преподаваться в школах. Декомпозиция это такая же базовая вещь, как таблица умножения... Я не говорю об основах алгоритмики. Я говорю об ОО проектировании. Это совсем другое.
c> M>А нахрен это ОО сдалось?
c> Мамут, Вы программист? Почему тогда задаете такие глупые вопросы?
Именно поэтому и задаю
c> M>Если учить — то SICP, чтобы показать, что ОО-проектирование — всего лишь один из способов решать проблемы. Не всегда самый удачный
c> Но в большинстве случаев самый удачный именно потому его надо изучать максимально тщательно.
Не надо его изучать максимально тщательно. ОО вообще довольно плохо ложится на большую (ударение — по вкусу) часть нашего мира.
c>> Но в большинстве случаев самый удачный именно потому его надо изучать максимально тщательно.
M>Не надо его изучать максимально тщательно. ОО вообще довольно плохо ложится
Вы вкурсе, что 99% (если не все 100%) приложений, которыми Вы пользуетесь написаны на ОО языках, ОО средствами?
M>на большую (ударение — по вкусу) часть нашего мира.
Прекрасно ложится.
ГВ>Например, как это и парадоксально, но тот же LSP противоречит простейшему субъективному "взгляду" на проблему. Собственно, живой пример — это пресловутые IoC-контейнеры, которые просто едут напролом супротив LSP: одна только непредсказуемость набора типов, загруженных в IoC уже многого стоит.
А можно на пальцах объяснить каким боком LSP относится к IoC контейнерам? Лучше с примером кода.
Принцип LSP накладывает ограничения на типы, в то время как IoC контейнеры работают с экземплярами. Это как сравнивать тёплое и мягкое.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, Mamut, Вы писали:
c>>> Но в большинстве случаев самый удачный именно потому его надо изучать максимально тщательно.
M>>Не надо его изучать максимально тщательно. ОО вообще довольно плохо ложится C>Вы вкурсе, что 99% (если не все 100%) приложений, которыми Вы пользуетесь написаны на ОО языках, ОО средствами?
Откуда дровишки?
Или мы считаем за ОО все где есть форма, кнопка или cout << ... ?
Здравствуйте, criosray, Вы писали:
c> c>> Но в большинстве случаев самый удачный именно потому его надо изучать максимально тщательно.
c> M>Не надо его изучать максимально тщательно. ОО вообще довольно плохо ложится
c> Вы вкурсе, что 99% (если не все 100%) приложений, которыми Вы пользуетесь написаны на ОО языках, ОО средствами?
И? Это значит только что, ООП пришлось на эпоху бурного развития компьютерной индустрии — ничего больше.
c> M>на большую (ударение — по вкусу) часть нашего мира.
c> Прекрасно ложится.
Советю почитать Execution in the Kingdom of Nouns. ООП — это всего лишь один из способов выражения своих мысле и идей. Зачем на нем зацикливаться —
Потом приходит такой вот на всю голову ООП-нутый и два слова на jQuery связат не может, патамушта там функции и нету ОО
V>>>наподобие реализованного в ObjectPascal/Java/C++/C#. C>>Замечательно. Это покрывает 99% языков, применяемых на практике в современном мире. Не забудьте добавить python, ruby, VB и т.д, и т.п.
FR>питон и руби не надо, там свои существенно другие паттерны.
Ага, другие. Особенно MVC в RoR, Django, Pylon, PureMVC и десятках других...
Здравствуйте, Mamut, Вы писали:
c>> c>> Но в большинстве случаев самый удачный именно потому его надо изучать максимально тщательно.
c>> M>Не надо его изучать максимально тщательно. ОО вообще довольно плохо ложится
c>> Вы вкурсе, что 99% (если не все 100%) приложений, которыми Вы пользуетесь написаны на ОО языках, ОО средствами?
M>И? Это значит только что, ООП пришлось на эпоху бурного развития компьютерной индустрии — ничего больше.
ООП пока нету достойной альтернативы для исключительного большинства, я подчеркиваю, большинства задач. Все остальное — демагогия.
Вот Вы на чем пишете?
c>> M>на большую (ударение — по вкусу) часть нашего мира.
c>> Прекрасно ложится.
M>Советю почитать
Спасибо, но на беллетристику время не трачу. M>Execution in the Kingdom of Nouns. ООП — это всего лишь один из способов выражения своих мысле и идей.
ООП это не способ выражения мыслей и идей. Это парадигма программирования. Да, одна из многих. Но и самая универсальная пока не придумали чего-то более универсального.
M>Зачем на нем зацикливаться —
Никто не предлагает на чем-то зацикливаться. Не передергивайте.
M>Потом приходит такой вот на всю голову ООП-нутый и два слова на jQuery связат не может, патамушта там функции и нету ОО
В jQuery нету ОО?
$(document).ready(function(){
$("a").click(function(event){
alert("Thanks for visiting!");
});
});
document — объект
ready() — метод объекта document
Javascript — ОО язык с той разницей, что вместо наследования классов применяется динамической расширение объектов — прототипирование, которое является разновидностью наследования.
Инкапсуляция, наследование, полиморфизм — все ОО составляющие есть в javascript.
Здравствуйте, samius, Вы писали:
c>>>> Но в большинстве случаев самый удачный именно потому его надо изучать максимально тщательно.
M>>>Не надо его изучать максимально тщательно. ОО вообще довольно плохо ложится C>>Вы вкурсе, что 99% (если не все 100%) приложений, которыми Вы пользуетесь написаны на ОО языках, ОО средствами? S>Откуда дровишки? S>Или мы считаем за ОО все где есть форма, кнопка или cout << ... ?
Здравствуйте, criosray, Вы писали:
C>>>Вы вкурсе, что 99% (если не все 100%) приложений, которыми Вы пользуетесь написаны на ОО языках, ОО средствами? S>>Откуда дровишки?
так откуда данные про 99%?
S>>Или мы считаем за ОО все где есть форма, кнопка или cout << ... ?
C>Инкапсуляция, наследование, полиморфизм.
Здравствуйте, samius, Вы писали:
S>>>Или мы считаем за ОО все где есть форма, кнопка или cout << ... ?
C>>Инкапсуляция, наследование, полиморфизм.
S>99% программ используют их?
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, samius, Вы писали:
S>>>>Или мы считаем за ОО все где есть форма, кнопка или cout << ... ?
C>>>Инкапсуляция, наследование, полиморфизм.
S>>99% программ используют их?
C>Конечно.
Пруфлинк?
Я бы даже не взялся утверждать, что 99% программ написаны на ООП ориентированных языках. А уж то что на ООП ориентированных языках все пишут ООП — вообще мистика. В лучшем случае половина.
В остальной половине использование ООП ограничивается конструкцией
Здравствуйте, samius, Вы писали:
S>>>>>Или мы считаем за ОО все где есть форма, кнопка или cout << ... ?
C>>>>Инкапсуляция, наследование, полиморфизм.
S>>>99% программ используют их?
C>>Конечно.
S>Пруфлинк?
S>Я бы даже не взялся утверждать, что 99% программ написаны на ООП ориентированных языках.
А я и не говорил про 99% ВСЕХ программ. S>А уж то что на ООП ориентированных языках все пишут ООП — вообще мистика. В лучшем случае половина. S>В остальной половине использование ООП ограничивается конструкцией S>
Здравствуйте, criosray, Вы писали:
C>ООП пока нету достойной альтернативы для исключительного большинства, я подчеркиваю, большинства задач. Все остальное — демагогия.
C>Вот Вы на чем пишете?
Вот я пишу на Си++. Пытаясь эмулировать мультиметоды, типы классов. Используя активно STL, заворачивая в класс лишь для тех, кто будет использовать это извне, так как им удобнее так, чем использовать STL-style.
Каков будет вердикт?
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, samius, Вы писали:
C>>>>>Инкапсуляция, наследование, полиморфизм.
S>>>>99% программ используют их?
C>>>Конечно.
S>>Пруфлинк?
S>>Я бы даже не взялся утверждать, что 99% программ написаны на ООП ориентированных языках. C>А я и не говорил про 99% ВСЕХ программ.
Точно, только про те, которые использует Mamut
S>>А уж то что на ООП ориентированных языках все пишут ООП — вообще мистика. В лучшем случае половина. S>>В остальной половине использование ООП ограничивается конструкцией S>>
