|
|
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
Нашел статью, в которой описывается разница между объектно-ориентированным, процедурным и "хакерским" подходами на примере одной задачи. Объектно-ориентированный подход явно уступает остальным по объему кода, в т.ч. "пустого" boilerplate кода. Т.е. он заведомо хуже. Так какие доводы можно привести в его пользу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2006, 22:33:32 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
Статья http://csis.pace.edu/%7Ebergin/patterns/ppoop.html собственно. Ссылку забыл вставить :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2006, 22:47:07 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
бред никаких доводов не нужно кому нужно тот сам поймёт / прочитает / разбереца / etc тебе в раздел флейма ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2006, 22:54:49 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
Времена, когда люди боролись за лишний байт памяти прошли (относится только к прикладному программингу). ИМХО страдать такой фигней сейчас не нужно, лучше сосредоточиться на других вещах, например архитектура. Не стоит обходить такие вещи как удобочитаемость, рано ли поздно придется заниматься сопровождением, добавлять функционал. Более того, в наше время весь софт пишется в сжатые сроки. ООП позволяет делать это быстрее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2006, 23:00:56 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
Ruslan.IsbarovБолее того, в наше время весь софт пишется в сжатые сроки. ООП позволяет делать это быстрее.Это в какие? Всегда интересовало. Вот например TheBat! ты за сколько времени напишешь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2006, 23:11:18 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
какбытькакжить Ruslan.IsbarovБолее того, в наше время весь софт пишется в сжатые сроки. ООП позволяет делать это быстрее.Это в какие? Всегда интересовало. Вот например TheBat! ты за сколько времени напишешь? Неважно за сколько я его напишу. Важно сколько начальство поставит. Я уверен, разработчики TheBat! не маялись фигней дабы сделать вид что работают... Вот тебе встречный вопрос: как думаешь, сколько проектов в наше время укладываются в сроки поставленные менеджерами проектов (или лицами занимающимися оценкой рисков и сроков)? По статистике, в процентах. P.S. Неважно какой проект, краткосрочный, среднесрочный или долгосрочный, времени всегда мало. Лишний день факапа - убытки для компании, подбитая репутация в лице заказчиков и прочие неприятности. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2006, 23:22:17 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
Подписываюсь под каждым словом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2006, 23:24:42 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
Кстати, приведу пример из области системного программирования. Вот замечательная OpenSource операционная система реального времени http://ecos.sourceware.org/ (либо http://sources.redhat.com/ecos/ ) (Embedded Configurable Operating System), разрабатываемая компанией Cygwin (входит в RedHat). В этой системе только HAL (Hardware Abstraction Level) написан на языках низкого уровня (Assembler'ы) (HAL пишется для конкретного процессора и периферии, содержащейся в нем). Все остальное - планировщик, графическая оболочка, драйверы файловых систем и прочее-прочее пишется на C++, с использованием ОО подхода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2006, 23:40:47 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
Ruslan.Isbarovкак думаешь, сколько проектов в наше время укладываются в сроки поставленные менеджерами проектов (или лицами занимающимися оценкой рисков и сроков)? - я думаю, нисколько :) Что во многом связано с низкой культурой заказчиков, которые после утверждения ТЗ норовят внести поправки, но при этом что бы все было сделано в те же сроки и без доплаты. Кроме того если сразу сказать заказчику сколько времени потребуется на проект он скорее всего откажется в пользу других исполнителей которые пообещают золотые горы, а в итоге сорвут сроки и сделают криво работающую поделку. Так что менеджерам часто приходится заведомо врать заказчику, или в более мягкой форме, скрывать от него часть правды, иначе первоначальная сделка просто не состоится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2006, 23:50:11 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
KachalovЛадно, это уже оффтоп для форума "Работа". Все таки мне кажется что ОО подход более уместен при разработке "повторно используемых библиотек", чем при написании чего-то что "нужно сегодня, а завтра нужно будет новое" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2006, 23:56:42 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
какбытькакжить какой у вас опыт работы программистом? Если бы вы написали хотя бы одну действительно большую и сложную систему, вы бы так не говорили. Возьмите того же Буча и почитайте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2006, 23:58:12 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
Kachalov Ruslan.Isbarovкак думаешь, сколько проектов в наше время укладываются в сроки поставленные менеджерами проектов (или лицами занимающимися оценкой рисков и сроков)? - я думаю, нисколько :) Точно. 0%... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.12.2006, 23:59:37 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
какбытькакжить KachalovЛадно, это уже оффтоп для форума "Работа". Все таки мне кажется что ОО подход более уместен при разработке "повторно используемых библиотек", чем при написании чего-то что "нужно сегодня, а завтра нужно будет новое" И ты здесь пропагандируешь "процедурно-ориентированный" подход к разработке? А ты не задумывался что то, что ты пишешь "сегодня", с таким подходом напишешь только к "завтра", а как ты сам сказал "...а завтра нужно будет новое". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2006, 00:14:35 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
какбытькакжить У вас вот уже спросили. А что вы написали в разработке чего участвовали, расскажите, пожалуйста. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2006, 00:14:53 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
какбытькакжитьОбъектно-ориентированный подход явно уступает остальным по объему кода, в т.ч. "пустого" boilerplate кода. Т.е. он заведомо хуже. - "пустой" код образуется при недостаточном моделировании задачи. Хорошая модель позволяет избежать "лишних" методов в новом коде, кроме того стоит критически относится к сторонним библиотекам, которые могут содержать избыточный для Вашей задачи код. какбытькакжить мне кажется что ОО подход более уместен при разработке "повторно используемых библиотек", чем при написании чего-то что "нужно сегодня, а завтра нужно будет новое" - ООП это способ мышления, заметно превосходящий по гибкости и удобству "процедурное" и "пошаговое" мышление (программирование). Если Вы мыслите исходя из данных сомнений в необходимости ООП просто не может быть, если Вы мыслите действиями, то наверное ООП Вам кажется излишне сложным. Это два разных взгляда на жизнь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2006, 00:33:57 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
креатив по сцылце не релевантен поскольку заведомо OS-dependent, что с оопом нараскоряку ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2006, 09:28:14 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
Kachalov - "пустой" код образуется при недостаточном моделировании задачи. моделирование - зло ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2006, 09:29:21 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
" какбытькакжить Все таки мне кажется что ОО подход более уместен при разработке "повторно используемых библиотек", чем при написании чего-то что "нужно сегодня, а завтра нужно будет новое " Ну что - то есть в этом, когда объекты моделируешь прикладной ориентации. А так как рыночная стихия заставляет бизнес выживать и адаптироваться и при этом воспроизводиться то... программисты без работы на останутся... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2006, 09:39:03 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
Угу, так же как президенты. Вопрос сколько и на каких основаниях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2006, 10:16:23 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
Читал статью. Забавно. Никаких выводов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2006, 11:20:46 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
Kachalov - ООП это способ мышления, заметно превосходящий по гибкости и удобству "процедурное" и "пошаговое" мышление (программирование). Если Вы мыслите исходя из данных сомнений в необходимости ООП просто не может быть, если Вы мыслите действиями, то наверное ООП Вам кажется излишне сложным. Это два разных взгляда на жизнь. Как я ни люблю ООП, но комбинация ООП + статическая типизация (при всех плюсах) приводит к появлению "лишних" строчек кода, которые иногда существенно увеличивают время на внесение изменений. Тут нужно сразу внести пояснения, иначе меня скушают. 1. На высоком уровне, когда обсуждаются отношения между объектами выделенными из предметной области ООП, действительно, можно назвать средством обладающим достаточной гибкостью. Избыточность синтаксических конструкций связаных с описанием объектов здесь не играет никакой роли. 2. Но "Дьявол в деталях" (с). На одних объектах из предметной области далеко не уедешь. Появляются "синтетические" классы: классы-утилиты, промежуточные интерфейсы для обеспечения дополнительной гибкости, фактори, паттерны визитор, темлейт метод и т.п. Казалось бы где грабли, ведь синтетические классы тоже решают задачи к которым можно применить ООА? А они есть. Преимущество использования декомпозиции данных (оно же ООА) существует только пока "данные" достаточно стабильны (существенно стабильнее, чем связанное с ними поведение). Так вот, данные предметной области стабильны и поэтому классы предметной области тоже стабильны, а синтетические классы не стабильны, т.к. исользуются для описания _поведения_, которое _нестабильно_. К чему это приводит? Либо к полному игнорированию ООП на уровне методов классов (включается процедурное программирование со всеми его плюсами и минусами), либо, при последовательном подходе, к разрастанию количества мини-классов, на которых становится заметен оверхед связанный с необходимостью их описания. Н-р, код из второго сообщения. Что вижу - то пою: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. Процедурная декомпозиция: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. Ясно стало видно дублирование кода для выявления типа OS, которое трудно устранить не имея возможности получить ссылку на метод. Используем для этого полиморфизм: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. Смотрим и видим, что класс PrintOS содержит утилитные методы, которым нужно найти другое место, чтобы они могли быть повторно использованы где-то ещё. Синтезируем объект "известные операционные системы": Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. Смотрим и снова видим, что что-то не так. А именно метод process. Он делает то, что нужно классу PrintOS, а как же быть другим пользователям OSes? Можно дописывать методы в интерфейс OS и реализовывать их, но это нарушает OSP. Поэтому появляется визитор: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. Лечге стало? Стало. Но остаётся дублирование и трудно добавлять новые типы оs. Фиксим: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. Избавляемся от мусора ввиде статиков: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. Итого из простого метода получены синтетические сущности: OS - операционная система @Os.Type - аннотация упрощающая создание visitor'ов OSes - произвольный набор операционных систем и методы работы с ними AbstractOSContainer - базовый класс для конкретного набора OS (с автоматической подгрузкой типов операционных систем) OSConainer - конкретный набор OS (их может быть несколько для разных задач) Однако изменение в тз на исходный метод может сразу сделать все эти классы бесполезными (если им не успели найти применения ещё где-нибудь) или существенно большей переработки, чем потребовалось для простого варианта. Какой вывод? ООП не является достаточно гибким способом мышления. Нет времени сейчас, кто хочет может дописать как тоже самое будет выглядеть на лиспе, чтобы убедиться, что есть способ "лучше" :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2006, 15:22:12 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
NotGonnaGetUs Однако изменение в тз на исходный метод может сразу сделать все эти классы бесполезными (если им не успели найти применения ещё где-нибудь) или существенно большей переработки, чем потребовалось для простого варианта. Какой вывод? ООП не является достаточно гибким способом мышления. - вот я и говорю ООП - другой способ мышления :) Вы исходном примере с которого Вы начали всю мутату нет данных вообще. ООП исходит из данных. Программист с ООП мышлением в Вашем искуственном примере первым делом бы завел поле: Код: plaintext 1. Если заказчик системы занимается продажей товаров, то сущность "товар" никуда не денется из ТЗ как бы ни изголялся заказчик и какие бы действия над ними не делал. Данные не куда не пропадут из программы, тогда как действия над ними можно менять, в этом и заключается мощь и гибкость ООП. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2006, 17:22:49 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
авторто сущность "товар" никуда не денется из ТЗ как бы ни изголялся заказчик и какие бы действия над ними не делал запросто. Заказчик продавал диски с пиратскими играми и фильмами а сейчас (в свете последних событий) это стало пустая болванка+услуга по записи скачанного из инета файла неизвестного содержания. И не надо про другое мышление. Мышление одинаковое всегда должно быть, здравое. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2006, 17:57:06 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
Реально большой проэкт (по-моему) без ООП не напишешь, а если напишешь то он будет как минимум в раза два больше (кода). ООП - сила. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2006, 19:50:31 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
1024запросто. Заказчик продавал диски с пиратскими играми и фильмами а сейчас (в свете последних событий) это стало пустая болванка+услуга по записи скачанного из инета файла неизвестного содержания. GameDisc -> Disc -> Object VideoDisc -> Disc -> Object - если при написании кода программист исходил из общего случая (класс Disc), то его код не потерял актуальности и большую часть кода удастся использовать повторно или модифицировать программу без существенных трудозатрат. А программист который смотрит в будущее создал бы такую структуру классов: GameDisc -> Disc -> Ware -> Object ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2006, 19:58:13 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
ррмяфА что вы написали в разработке чего участвовали, расскажите, пожалуйста.... не волшебник, я только учусь© Потому и спрашиваю GameDisc -> Disc -> Ware -> Object GameDisc -> Disc -> Ware -> Object Будильник -> Часы -> Ware -> Object Секундомер -> Часы -> Ware -> Object Женские трусы -> Трусы -> Ware -> Object Мужские трусы -> Трусы -> Ware -> Object ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2006, 20:52:28 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
AlexeyShponarskyРеально большой проэкт (по-моему) без ООП не напишешь, а если напишешь то он будет как минимум в раза два больше (кода). ООП - сила. Увы, сейчас все технологии реализованы с применением ОО подхода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2006, 21:53:50 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
Всё просто, как пареная репа ! Хотите "РУБить капу$ту" на пике самых передовых технологий - используйте ООП . А кто там - приверженец процедурального или еще бог-знает какого программирования - нервно курит в сторонке. Ибо нефиг. Хакеры говорите? Ха! Ха! А вот давайте поймаем одного живого хакера и спросим его - Чел! Ты юзаешь ООП или как? Тогда всё вопросы исчезнут ИМХО. C уважением Lord Mayton ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.12.2006, 22:20:43 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
срочно переименуйте топик в mayton А вот давайте поймаем одного живого хакера ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2006, 00:04:56 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
Написать можно всё и при помощи процедурного и при помощи ООП подхода, вопрос во времени, сложности и количестве кода... При процедурном подходе все три параметра будут на порядок больше. Это проверено на практике миллионов программистов, которые работали до нас. ООП разрабатывался не с бадуна, а когда это стало необходимостью, иначе мы до сих пор бы обсуждали процедуры, функции и т.д. и ни каких ООП языков не было бы впринципе. Простой пример - релизуйте хоть более-менее сложный алгоритм при помощи процедурного и ООП подхода и всё станет на свои места. Например - реализация решения ЗЛП в общем случае - задача может иметь сколько угодно переменных и сколько угодно ограничений. Можно попробовать писать на С и С++, например. Мне кажется, что только на более-менее сложных задачах можно увидеть как ООП обгоняет процедурный подход по всем мыслимым критериям. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2006, 11:01:01 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
KachalovПрограммист с ООП мышлением в Вашем искуственном примере первым делом бы завел поле: Код: plaintext 1. О, давайте вы, как программист с ООП мышлением, покажите где будет заведено это поле, какие методы с ним будут работать и т.д. Плз. Kachalov Если заказчик системы занимается продажей товаров, то сущность "товар" никуда не денется из ТЗ как бы ни изголялся заказчик и какие бы действия над ними не делал. Данные не куда не пропадут из программы, тогда как действия над ними можно менять, в этом и заключается мощь и гибкость ООП. Попробуйте читать то, что я пишу. Сущности ака "товар" вытекают из анализа предметной области и никуда не могут исчезнуть, пока не изменится сама предметная область, что бывает достаточно редко. Однако операции с "товаром" могут то исчезать, то появляться. Код реализующий эти операции будет либо насквозь процедруным, либо будут вводиться вспомогательные объекты (т.н. синтетические объекты, которых полным полно во всех общеизвестных паттернах) позволяющие избавиться от дублирования кода, изменить направление зависимостей, увеличить сцепление и т.д. и т.п. В первом случае имеем дело не с ООП, а с миксом ООП + процедурщина - без функциональных типов (т.е. в java) этого не достаточно, чтобы писать "хороший" код. Во втором случае, объекты могут появляться и исчезать так же часто как будет измененяться поведение "стабильных" объектов. Т.е. вместо гибкости, можно получить необходимость писать лишний код. Самый лучший вариант ООП + функциональное программирование так, как это сделано в nemerle. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2006, 12:51:10 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
NotGonnaGetUs О, давайте вы, как программист с ООП мышлением, покажите где будет заведено это поле, какие методы с ним будут работать и т.д. - фигней заниматься не хочется. NotGonnaGetUs Однако операции с "товаром" могут то исчезать, то появляться. Код реализующий эти операции будет либо насквозь процедруным, либо будут вводиться вспомогательные объекты (т.н. синтетические объекты, которых полным полно во всех общеизвестных паттернах) позволяющие избавиться от дублирования кода, изменить направление зависимостей, увеличить сцепление и т.д. и т.п. - не забывайте про полиморфизм, который поможет адаптировать методы под изменение задачи (при условии что предметная область не изменилась и классы, описывающие сущности, были составлены разумно, скорее всего переопределению подвергнется малое число методов, а в сущностных классах в идеале вообще ничего трогать не придется) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2006, 14:40:44 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
Kachalov- фигней заниматься не хочется. А вы займитесь, и увидите, что фигней окажутся слова про "мышление". Тем более, что тут любое решение простая пара строчек кода. Kachalov - не забывайте про полиморфизм, который поможет адаптировать методы под изменение задачи Какже я его забуду, он мне по ночам только не снится :) Полиморфизм не бесплатная штука. Любое использование полиморфизма приводит к появлению нового класса наследника, а цепочки наследований приводят к коду изменять, который в некоторых случаях существенно труднее, чем "лапшу" из if-else. Если вам всё кажется таким солнечным, сделайте то, что я прошу. Не одному мне, думаю, будет интересно увидеть "ООП в действии". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2006, 15:21:00 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
2Kachalov автор- фигней заниматься не хочется. для фигни на скл.ру есть ПТ. А тут извольте обосновывать. Дофига вас таких, сопливых. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.12.2006, 21:40:52 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
NotGonnaGetUs А вы займитесь, и увидите, что фигней окажутся слова про "мышление". Тем более, что тут любое решение простая пара строчек кода. - по просьбам "телезрителей" попытался описать проблему из примера NotGonnaGetUs с "моей" точки зрения, т. е. опираясь на данные (то самое ООП мышление). Боюсь решение никого кроме меня не удовлетворит, т. к. получилось "слишком" просто :) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. - возможно не уловил суть проблемы в изложении NotGonnaGetUs, ели что поясните какие проблемы могут возникнуть при использовании предложенного кода ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2006, 00:12:56 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
10242Kachalov автор- фигней заниматься не хочется. для фигни на скл.ру есть ПТ. А тут извольте обосновывать. Дофига вас таких, сопливых. - персонально для 1024 - Сергей Сергеевич ведите себя сдержаней, вы вроде взрослый человек, а ведете себя как подросток в период полового созревания. Не хватало еще нам с Вами прилюдно соплями меряться :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2006, 00:20:03 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
Kachalov- возможно не уловил суть проблемы в изложении NotGonnaGetUs, ели что поясните какие проблемы могут возникнуть при использовании предложенного кода 1. a. Сообщения, которые выводятся на экран должны совпадать с теми, что присутствуют в исходном коде. В общем случае эти сообщения произвольные, т.к. мнения о том, что good или bad у разных людей разные. Т.е. универсального toString() сделать нельзя. b. Алгоритм определения типа OS в вашем варианте не работает, т.к. ни одна из версий windows не идентифицируется как osName == "windows". Если учесть это, что ваш варинт будет таким: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 2. Проблемы: а. Нет возможности расширить класс OS поведением специфичным для конкретной операционной системы. Н-р, для windows имеет смысл метод "получить реестр", а для unix или unknown - нет. Т.е. в нём недостаточно гибкости. b. Добавление нового типа OS потребует изменения в коде класса OS. Нарушение OCP. Общий вывод: требуется рефакторинг "замена переменной типа наследованием или стратегией" (либо наследуем Unix -> OS, либо добавляем в OS поле Type и реализуем Type <- Unix). с. Класс OS содержит методы c низкой степенью сцепления. Попытки добавления новых методов для работы с OS только усугубят ситуацию. Н-р, есть две группы методов (findByName, isWindows и isLinix) и (getName, getMessage) явно решающих не связные друг с другом задачи. Поэтому нужно выделить первую группу методов в класс OSFactory. d. Класс OS обладает информацией о всех своих "подтипах". Это проблема, т.к. постоянно появляются новые версии OS, что приведёт к необходимости изменений в классе OS. Если бы набор OS был фиксирован раз и на всегда, то можно было бы обойтись использованием простого enum'a. e. Метод getMessage находится не на своём "месте". Пожелания всех желающих засунуть в (полу)библиотечный класс не выйдет. Нужен механизм позволяющий каждому клиенту расширять поведение класса не прибегая к его модификации (опять OCP). ... Продолжая копаться можно найти ещё кучу различных "поводов" для изменений, каждое из которых будет разрешать _потенциальные_ проблемы, но, вместе с тем, всё больше и больше усложнять общее решение. И все эти усложнения могут легко пойти лесом, из-за внезапно появившихся у заказчика новых требований совсем "чуть-чуть" меняющих поведение объектов, но почему-то таким способом, который "не ложится" на имеющийся код. Т.е. стабильность классов оказывается достаточно условной, о чём я и пытаюсь сказать. Поэтому меня очень радует подход Фаулера и других идеологов хp: останавливаться на самом простом решении из возможных, но при этом оставлять возможности для будущих рефакторингов, чтобы как только решение не сможет удовлетворить изменившимся требованиям, его можно было легко привести к более совершенному виду (заменить параметр типа на стратегию или наследование и т.д.). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2006, 13:22:47 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
NotGonnaGetUs Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Опечатка :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2006, 13:26:17 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
NotGonnaGetUsОднако операции с "товаром" могут то исчезать, то появляться. Какие такие операции? Мне просто интересно может я чего нить не понимаю ... есть товар, у него есть набор свойств ключ=значение, есть артикул, вес, количество, цена, описание и тд(данные). Товар может рассказать о себе (методы). Если например имеется ввиду что у товара должна быть например галка "в прайс" то это может быть уже объект прайс. вообще я согласен с NotGonnaGetUs. Есть некая граница до которой функциональное программирование удобно и после которой неудобно. Надо делать так чтобы это было максимально эффективно (стоимость работы на полученный результат). Иногда можно сделать "круто" только когда это круто будет работать все клиенты уйдут к конкурентам. Как говорится без фанатизма надо. Возьмем к примеру тот же товар если торгуете в розницу то поле цена просто делается полем деньги, а вот если торгуем оптом тогда лучше сделать объект цена потому что там уже есть мелкий опт, крупный опт, дилер, спекулянт и дт. Вообще бизнес процесс зачастую не меняется так быстро чтобы невозможно было напрограммировать то что нужно. Да действительно нужно программировать, но за это кажется программистам деньги и платят :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2006, 13:33:10 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
про фаулера +1 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2006, 13:35:15 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
vfabr NotGonnaGetUs Сущности ака "товар" вытекают из анализа предметной области и никуда не могут исчезнуть, пока не изменится сама предметная область, что бывает достаточно редко. NotGonnaGetUsОднако операции с "товаром" могут то исчезать, то появляться. Какие такие операции? Мне просто интересно может я чего нить не понимаю ... "товар" используется в качестве примера, а затем синонима для обозначения классов выведенных непосредственно при анализе предметной области. Операции == действия над объектами/данными. Н-р, вчера нужно было напечатать в консоль, что "This is a UNIX box and therefore good.", а сегодня версию OS и тип файловой системы. Объект один и тот же - "OS", а представить его ввиде классов/данных можно очень по разному (и сильно потом жалеть). Тут же уместно вспомнить известный пример про написания класса "стол". И в очередной раз убедиться, что ООП очень хорошо подходит для решения _конкретной_ задачи, и не очень подходит для создания решений для _семейств_ задач, особенно если в постановке задачи начинают фигурировать "естественные" понятия, которые бывает очень проблематично представить ввиде фиксированного набора свойств, а значит и отобразить в класс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 07.12.2006, 14:18:51 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
Вот еще один пример сопоставления OOP vs NOOP. Я тоже заметил давно, что OOP очень сильно смахивает на способ записи процедур и функций в классы, т.е. эдакое модуляризированное процедурное программирование. Мне вот интересно, а если у класса из примера в статье не 2 состояния male|female, а 15 или 30, что, 30 классов-наследников писать? А если иерархий наследования не одна а 3-4? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2006, 11:52:37 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
какбытькакжитьЯ тоже заметил давно, что OOP очень сильно смахивает на способ записи процедур и функций в классы, т.е. эдакое модуляризированное процедурное программирование. А я давно заметил, что написание программ очень смахивает на работу с MS Word, т.е. эдакое набирание буковок на клавиатуре. Правда, мы с тобой "зрим в корень", а все остальные ничего в этой жизни не понимают? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2006, 12:36:05 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
какбытькакжить Вот еще один пример сопоставления OOP vs NOOP. Я тоже заметил давно, что OOP очень сильно смахивает на способ записи процедур и функций в классы, т.е. эдакое модуляризированное процедурное программирование. Мне вот интересно, а если у класса из примера в статье не 2 состояния male|female, а 15 или 30, что, 30 классов-наследников писать? А если иерархий наследования не одна а 3-4? В качестве варианта советую почитать какую-нибудь книгу по шаблоном проектирования или вообще по ооп. а потом уж этот подход критковать, если не нравится. Проблемы с порождением большого числа классов обычно вполне решаемы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2006, 12:57:10 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
ув. Наснипаиметь, ваших огромных постов мой убитый оопом моск ниасиливает - но чую голимая крамола. Озвучте пожалуйста тезис в полторы строки, чтоб его можно было предметно оспорить заранее сапсибо вот одна из попыток воспринятия мегапрог (см.выш): ущербные оопные куски писал явный провокатор задавщийся мелочной целью построить себе имя на попрании досточтимы Основ. но и на него найтётся хитрый болт: берём его креативы, компилим C++ компилятором, дизасемблируем - получаем процедурный код беспрецендентный по своей невообразимой вычурности. дальше делаем выводы что дейкстра и вирт должны отправиться в ад прямиком минуя чистилище. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2006, 13:07:49 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
exppув. Наснипаиметь, ваших огромных постов мой убитый оопом моск ниасиливает - но чую голимая крамола. Озвучте пожалуйста тезис в полторы строки, чтоб его можно было предметно оспорить заранее сапсибо А вы почитайте это сообщение . Там есть п.1 и п.2. Если согласны с п.1., то переходим к п.2 про проблемы (не знаю как можно не согласиться с п.1.) Если в пунктах a/b/c/d/e что-то не понятно, то зацитируйте и задайте вопрос об этом. Или можете повторить опыт Kachalov'a и показать нам, что ваш моск советует сделать с исходным кодом (тем, где всего один метод main), чтобы он стал "чиста" объекто ориентированным, а не процедурным. Что вам за тезис нужен - не понял. Если хочется с чем-нибудь по спорить, то вот вам несколько: 1. Если злоупотреблять ООП, т.е. порождать классы при декомпозиции поведния объектов выведенных из предметной области, изменения в коде будет делать так же сложно, как если бы весь код был насквозь процедурным. 2. ООП со статической типизацией (и без вывода типов) приводит к большему количеству кода (в строчках) и к более сложным решениям (количество объектов и связей между ними), чем ООП с динамической типизацией. 3. Хороший ООЯ должен сочетать не ООП + процедурное программирование, а ООП + функциональное программирование. 4. Останавливаться нужно на самом простом решении из возможных, но при этом оставлять возможности для будущих рефакторингов (чтобы при необходимости можно было легко получить более "правильное" решение). 5. "Естественные" понятия, которые проблематично описать фиксированным набором "свойств", представить "универсальным" классом практически невозможно. Конкретное задачи потребуют разные классы. Откуда следует вывод, что применимость ООП достаточно ограничена и рассматривать его как "мышление" можно только с натяжкой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2006, 13:30:40 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
NotGonnaGetUs А вы почитайте это .. слишкам многа букаф нужен descision table pattern а не class Os. ловим Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. NotGonnaGetUs 1. Если злоупотреблять ООП ... а если херакнуть молотком по пальцу ... не злоупотребляйте им. <<хороших>> молотков не бывает. NotGonnaGetUs 2. ООП со статической типизацией (и без вывода типов) приводит к большему количеству кода (в строчках) и к более сложным решениям (количество объектов и связей между ними), чем ООП с динамической типизацией. просматривая подобные объёмы кода я как правило вспоминаю "обезъяну с гранатой". динамические языки верный способ отстрела собственных ног. NotGonnaGetUs 3. Хороший ООЯ должен сочетать не ООП + процедурное программирование, а ООП + функциональное программирование. вот и сочетайте. функциональные фишки лекго впендюриваются в нормальные языки. вам что с чем надо скрестить? NotGonnaGetUs 4. Останавливаться нужно на самом простом решении ... я бы постеснялся так боянить NotGonnaGetUs 5. "Естественные" понятия, ... а об этом немного позже ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2006, 15:54:47 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
exppслишкам многа букаф Ну вы сосредоточтесь, попросите кого-нибудь помочь вам разобраться. А то мне придётся повторять тоже самое, будет опять много буковок, а т.к. для вас это сложно, то получится замкнутый круг. expp ловим Код: plaintext 1. 2. 3. 4. 5. Полную имплементацию плз (вместе с инициализаций descisionTable и т.п.), чтобы между нами не вышло не понимания. А пока могу констатировать только то, что таблица выбора - это паттерн процедурного/структурного программирования и прикрученный к map'е класс OsDesc* просто лишний. Достаточно иметь проинициализированный map. Сравниваем: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. Практически никаких _потенциальных_ проблем исходного решения ваше решение не решает и добавляет новые. Так при изменении условий проверок, н-р, с (osName.equals("Windows NT") || ...) на (osName.toLowerCase().startWith("win")) таблицу придётся целиком выкинуть. expp а если херакнуть молотком по пальцу ... не злоупотребляйте им. <<хороших>> молотков не бывает. Тоже любите боянить? :) Говоря "не злоупотребляйте", вы соглашаетесь с невозможность применять объекто-ориентированный подход на всех этапах написания кода. А это равнозначно признанию в том, что данный подход не является универсальным и достаточно полным. Если это так, то ни о каком оо-мышлении говорить нельзя. А вы, кажется, с этим не хотите соглашаться? ) expp NotGonnaGetUs 2. ООП со статической типизацией (и без вывода типов) приводит к большему количеству кода (в строчках) и к более сложным решениям (количество объектов и связей между ними), чем ООП с динамической типизацией. просматривая подобные объёмы кода я как правило вспоминаю "обезъяну с гранатой". динамические языки верный способ отстрела собственных ног. И тем не менее факт на лицо: кода получается меньше :) В ОО языки с динамической типизацией почти все gof паттерны вырождаются до тривиальных конструкций, которые стыдно называть паттернами. В языках поддерживающих замыкания в нескольких строчках можно сосредоточить количество логики, представление которой через классы в статически типизированном языке превратилось бы в пару экранов кода. expp вот и сочетайте. функциональные фишки лекго впендюриваются в нормальные языки. вам что с чем надо скрестить? *впендюриваются* легко, но пользоваться этим потом не возможно. Особенно в java, где нет никакой поддержки этих фокусов со стороны стандартных библиотек и языковых конструкций. В С# c это всё есть, но всё равно не очень удобно (сужу по полугоду использования функциональных фич в этом языке :)). Поэтому ваш совет не совсем к месту. Что с чем и как скрещивать иллюстрирует язык nemerle. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2006, 17:11:12 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
в том то и прикол что если мысль есть то занимает она две строки от силы... мой код вы поняли более чем верно. NotGonnaGetUsА пока могу констатировать только то, что таблица выбора - это паттерн процедурного/структурного программирования и прикрученный к map'е ООП вообще паттерн процедурного/структурного программирования. NotGonnaGetUsГоворя "не злоупотребляйте", вы соглашаетесь с невозможность ... да ни в жисть - уметь надо и всё NotGonnaGetUsИ тем не менее факт на лицо: кода получается меньше :) ассемблер вот язык достойный лаконичного мужа. Лапшу из if ов я просто не навижу авторов её предаю разнузданному геноциду NotGonnaGetUs*впендюриваются* легко, но пользоваться этим потом не возможно. вы пробовали ? лично я использовал Drools. впечатления нормальные NotGonnaGetUsnemerle. с возрастом это проходит ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2006, 18:16:12 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
exppв том то и прикол что если мысль есть то занимает она две строки от силы... мой код вы поняли более чем верно. Прикол в том, что такая таблица приведёт к существенно большему дублированию кода, чем несколько в if-else, если нам потребуется в каком-то месте вывести чуть другие сообщения. Так же точно потребуется вносить много изменений в уже написанные код, если нужно будет получать не строку в зависимости от типа ОС, а какую-то специфичную для данной ОС информацию. И т.д. и т.п. (много буков) Если попытаться честно расписать ваше решение и избавить его от описанных недостатков получится ровно тоже большое количество классов и таже сложность. И вы это похоже прекрасно понимаете :) Тогда я не понимаю к чему были ваши слова "голимая крамола". expp NotGonnaGetUsА пока могу констатировать только то, что таблица выбора - это паттерн процедурного/структурного программирования и прикрученный к map'е ООП вообще паттерн процедурного/структурного программирования. И чего? Вместо полиморфизма будет использовать опять таблицы, а вместо классов структуры или массивы с дикриминаторами? И зачем? expp да ни в жисть - уметь надо и всё Трухлявый бояян. Умеете - покажите. Не умеете - не говорите. Я показал к какому коду может привести следовании оо принципам. Вы назвали это "ущербными оопными кусками", если я правильно понял. Если "умеете" продемонстрируйте как сделать отличные "оопные куски". Пока вы этого не сделали. expp NotGonnaGetUsИ тем не менее факт на лицо: кода получается меньше :) ассемблер вот язык достойный лаконичного мужа. Разве на ассемблере получается коротко? Мы вроде как не размер бинарников сравниваем... expp Лапшу из if ов я просто не навижу авторов её предаю разнузданному геноциду Геноцид заключается в том, что авторов заставляют переписывать всё на таблицы? :) expp вы пробовали ? лично я использовал Drools. впечатления нормальные Drools/Groovy/etc это не java. Это другие языки. Писать тела методов java классов на них не получится. expp NotGonnaGetUsnemerle. с возрастом это проходит Что именно? Желание иметь лямбды, паттерн матчинг, вывод типов и прочии конструкции позволяющие писать более лаконичный код, в частности, лишённый структурного дублирования ? ) Добавте пару буковок для расшифровки, я их осилю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2006, 19:24:28 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
exppс возрастом это проходит Интересно, почему "это" не прошло у разработчиков c# 3.0 и java 7? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2006, 19:27:47 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
NotGonnaGetUsПрикол в том, что такая таблица приведёт к существенно большему дублированию кода, чем несколько в if-else, если нам потребуется в каком-то месте вывести чуть другие сообщения. ниправда: первая версия таблица забивается в коде в static инициализаторе. вторая версия выносится в конф.файло. Ни один из вариантов не валялся рядом с мляцкими ифэлсами. NotGonnaGetUsТак же точно потребуется вносить много изменений в уже написанные код, если нужно будет получать не строку в зависимости от типа ОС, а какую-то специфичную для данной ОС информацию. это изменения "в ширину", наращивание функциональности, новый релиз. ифэлсы "конечно же" остаются неизменными при таких изменениях? NotGonnaGetUsЕсли попытаться честно расписать ваше решение и избавить его от описанных недостатков получится ровно тоже большое количество классов и таже сложность. останется один HashMap. ну максимум descisioner и table. NotGonnaGetUsИ чего? Вместо полиморфизма будет использовать опять таблицы, а вместо классов структуры или массивы с дикриминаторами? И зачем? а низачем. это было написано для того чтобы показать насосанность из пальца вашего утверждения про то что descision table это на самом деле паттерн стыренный оопниками. есть ваша якобы задача и есть descision table и они наиболее друг другу подходят. и отсюда ничего не следует. она так решается и всё а кем и на чём - неважно в догонку такие шаблоны Domain Specific Language, Little Language NotGonnaGetUsГеноцид заключается в том, что авторов заставляют переписывать всё на таблицы? :) Нет заставить переписать на таблицы - это знак милосердия. Я просто беру пол ведра ржавых гвоздей и .... NotGonnaGetUs Drools/Groovy/etc это не java. Это другие языки. Писать тела методов java классов на них не получится. не надо тела классов писать на drools. мне приятно что на жабе есть подобная херь и если меня сильно прижмёт я смогу легко её использовать ничего не теряя от явы. NotGonnaGetUsЧто именно? Желание иметь лямбды, паттерн матчинг, вывод типов и прочии конструкции позволяющие писать более лаконичный код, в частности, лишённый структурного дублирования ? выкобениватья на немерлях. пройдёт. как и у польских аспирантов. получится очередной похеренный .NET O/S проект. Про jdk 7 слышал... поморщился и подумал про PR. пусть лобают. но недай бог какаяннить зараза в моём проекте closure заюзает - я думаю смогу популярно объяснить что именовать методы и классы возможно и вполне по силам. про делегаты - ваще молчу о чём дискусия то? если про subj - то я "за" немедленное выжигание калёным железом быдлокодерства в любых проявлениях. и "за" смачный оопный дизайн . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2006, 20:30:51 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
Ребята, пукать в лужу не надоело друг перед другом? Неужели нет более достойных тем (тем более в Java) для обсуждения, кроме как вариантов написания идиотской программки для даунов? Аж читать гнусно... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2006, 20:50:52 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
так трындеть не мешки ворочать. Если показать нечего то можно кучу историй нарасказывать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2006, 21:47:40 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
exppПро jdk 7 слышал... поморщился и подумал про PR. пусть лобают. но недай бог какаяннить зараза в моём проекте closure заюзает - я думаю смогу популярно объяснить что именовать методы и классы возможно и вполне по силам. Это почему это closures - плохо? А как же Groovy? Спецально новый язык изобретают для JVM, где поддерживаются closures, curring, agile программирование и scripting. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2006, 21:05:42 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
exppниправда: первая версия таблица забивается в коде в static инициализаторе. вторая версия выносится в конф.файло. Код в студию. Мне не понятно о чём вы. expp NGGU Практически никаких _потенциальных_ проблем исходного решения ваше решение не решает и добавляет новые. Так при изменении условий проверок, н-р, с (osName.equals("Windows NT") || ...) на (osName.toLowerCase().startWith("win")) таблицу придётся целиком выкинуть. NotGonnaGetUsТак же точно потребуется вносить много изменений в уже написанные код, если нужно будет получать не строку в зависимости от типа ОС, а какую-то специфичную для данной ОС информацию. это изменения "в ширину", наращивание функциональности, новый релиз. ифэлсы "конечно же" остаются неизменными при таких изменениях? Я уже писал, таблицы порой даже проигрывают if/else, т.к. они фиксируют алгоритм сравнения. Необходимость избавления от этой фиксации приведёт к необходимости реализации различного рода интерпретаторов (те самые дсл и кастрированные языки), а это существенно большее усложнение решения, чем использование полиморфизма для избавления от ветвлений. Можете меня переубедить. Для этого достаточно привести-таки целиком ваш вариант с табличками и показать как он изменится при изменении одного из правил проверки с equlas на startWith. expp NotGonnaGetUsЕсли попытаться честно расписать ваше решение и избавить его от описанных недостатков получится ровно тоже большое количество классов и таже сложность. останется один HashMap. ну максимум descisioner и table. ПОКАЖИТЕ. Зачем произносить лишние слова? expp это было написано для того чтобы показать насосанность из пальца вашего утверждения про то что descision table это на самом деле паттерн стыренный оопниками. Повторюсь, в тайной надежде, что вы просто не внимательно до этого читали. Использование "таблицы выбора" оставит процедруный код процедурным. В ООЯзыке этот "паттерн" вшит, называется "полиморфизм". Использование классов и полиморфизма вместо дискриминатора и таблицы лучше тем, что - вызывать метод быстрее, чем бегать по мапе, - не нужно каждый раз изобретать велосипед и заставлять разбираться в нём своих коллег, - из-за плюсов статической типизации (н-р, Map<string, string> adress2name и Map<string, string> name2department не попадут в один метод) - ... expp выкобениватья на немерлях. пройдёт. как и у польских аспирантов. получится очередной похеренный .NET O/S проект. Что значит "выкобениватья на немерлях"? Приверженцы функциональных языков тоже только "выкобениваются"? :) Есть пример DLINQ от МS. Языки like nemerle уже реальность. expp Про jdk 7 слышал... поморщился и подумал про PR. пусть лобают. но недай бог какаяннить зараза в моём проекте closure заюзает - я думаю смогу популярно объяснить что именовать методы и классы возможно и вполне по силам. про делегаты - ваще молчу Объясните здесь. expp о чём дискусия то? если про subj - то я "за" немедленное выжигание калёным железом быдлокодерства в любых проявлениях. и "за" смачный оопный дизайн . Давайте повспоминаем о чём дискусия... Вы не смогли понять буковок и попросили очень коротких, а потому обязательно спорных, тезисов, которые вы смогли бы оспорить и назвали гавном моё ооп :). Я их вам дал (мне не жалко) и заодно предложил показать ваш вариант ОО решения для поставленной задачи. Вы как-то вяло стали спорить с тезисами и привели микс из класса и таблицы выбора в качестве оо решения. Далее я писал о том, что этот микс к ООП не имеет никакого отношения и ничем не лучше, чем набор if/else, а вы писали, что у меня "всё пройдёт", что вы "умеете готовить ООП", но так никому и не показали как и что-то там про насосасывание из пальца добавили... Резюмируя: Я не знаю о чём вы ведёте дискусию и что хотите сказать (кроме того, что к if/else у вас не любовь). Я же пытался и пытаюсь узнать, как "правильно готовить ООП" и почему у меня оно на ваш (или чей угодно ещё) взгляд "галимое"(с) :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2006, 15:33:04 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
alexx726Ребята, пукать в лужу не надоело друг перед другом? Неужели нет более достойных тем (тем более в Java) для обсуждения, кроме как вариантов написания идиотской программки для даунов? Аж читать гнусно... Хочешь пообсуждать написание программки "не для даунов"? А как ты думаешь, если в таком простом варианте находится столько разных позиций и "странных" убеждений у людей, в сложном случае их станет меньше? :) Будет только хуже. Почитай только, что о хибернейт с соседних топиках писалось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2006, 15:36:24 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
це кот Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. можно я map у из файла грузить не буду а то работать нада ... NotGonnaGetUs Я уже писал, таблицы порой даже проигрывают if/else, т.к. они фиксируют алгоритм сравнения. не а. мапы рулят. нужен алгоритм сравнения пишем IEqulizer - и фаны closure показывают всю свою мощь NotGonnaGetUs Необходимость избавления от этой фиксации приведёт к необходимости реализации различного рода интерпретаторов (те самые дсл и кастрированные языки), а это существенно большее усложнение решения, чем использование полиморфизма для избавления от ветвлений. для клинических случаев дсл и кастро языки или plug-in class (каждый раз что то новое придумываю - воистину не исчерпаемая затача таксономии ОСов). дсл и кастро языки уже есть бери и юзай если надо. не надо приплетать сюда полиморфизм чтобы показать, что он "не вывозит" NotGonnaGetUs В ООЯзыке этот "паттерн" вшит, называется "полиморфизм". вы открываете мне глаза, значит я дурак всю жизнь конфиги своих прог (которые не достойны отдельных файлов, и поэтому) держал в статик мапах, а надо было кучей классов делать ... а потом ещё фабрику примострячивать для их создания - стопудовый отстрел своих ног. NotGonnaGetUsЧто значит "выкобениватья на немерлях"? это значит злобать на них helloworld не убившись от стену, восклицать : "буть прокляты годы на с# (жабе и т.п.)" NotGonnaGetUsЕсть пример DLINQ от МS. Языки like nemerle уже реальность. smalltalk, lisp, oberon, OODB, ai тоже реальность про jdk7 я конечно рад closure и delegateам в ущербном жабаязыке, но думаю никогда их использовать не буду т.к. они явлются излишней мутью, необходимой только их авторам а вобще уже сожалею, что ввязался . alexx726, 1024 - без б. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2006, 19:13:45 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
NotGonnaGetUs 5. "Естественные" понятия, которые проблематично описать фиксированным набором "свойств", представить "универсальным" классом практически невозможно. Конкретное задачи потребуют разные классы. Откуда следует вывод, что применимость ООП достаточно ограничена и рассматривать его как "мышление" можно только с натяжкой. Дык... мил-человек... разве ООП инструмент для решения абстрактных задач? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2006, 12:44:17 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
teb Дык... мил-человек... разве ООП инструмент для решения абстрактных задач? И в основном - именно абстрактных. Живой пример: - бизнес приложения, мало ООП-абельны на практике (в сравнении откровенных бредовых Java EE ORM и прочих MVC с какими дедушками вроде Cobol, ABAP и PL/SQL) - системные средства (ОС Unix) - аналогично, даже С++ идет строго лесом и степью - RDBMS - пишутся в массе, аналогично, на голом C - RAD (Delphi, VB) с чистым (правильным) ООП - аналогично, имеют мало общего (в конечных приложениях) - JSP, JSF, Struts, ASP - назвать именно ООП средствами... можно, но базовый их концепт - вовсе не в ООП - большинство современных API - аналогично, с классами, абтракциями, инкапсуляциями и прочими декомпозициями... имеют лишь воображаемое общее). ---- Может ООП и его дальнешие фреймворк-agile развития - это был просто "вирус в воспалённых головах", когда в принципе вполне успешную модель абстрактных компонентно-инструментальных средств (AWT, SWT, J2EE, VCL, WinForms) вдруг начали с "общего перепугу" натягивать на те области, которые к ООП изначально отношение не имеют (вовсе) ? В смысле - не имеют целесообразности и реальной необходимости в ООП? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2006, 14:31:24 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
grexhide вдруг начали с "общего перепугу" натягивать Так "натягивать" - это не ООП. Вот NotGonnaGetUs этим как раз и занялся в своём примере. Мне так каэтся. В его примере правильно - это как раз банальное наследование, а он начал вместо конкретизации городить абстракцию, которая задачей не требуется. И получилось плохо. Чему удивляться? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2006, 15:00:52 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
teb grexhide вдруг начали с "общего перепугу" натягивать Так "натягивать" - это не ООП. Вот NotGonnaGetUs этим как раз и занялся в своём примере. Мне так каэтся. В его примере правильно - это как раз банальное наследование, а он начал вместо конкретизации городить абстракцию, которая задачей не требуется. И получилось плохо. Чему удивляться?Я все таки всё ещё не понимаю, вот объясните, полиморфизм хорош, когда нужно описать поведение (создать классы) для 5-10 ОС. А если этих вариантов (поведений) 50-100? Что, 100 классов наследовать? А как в одиночку с этим справиться, может проще как советует expp, налабать таблицу выбора? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.12.2006, 22:30:25 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
какбытькакжить А если этих вариантов (поведений) 50-100? Что, 100 классов наследовать? А как в одиночку с этим справиться, может проще как советует expp, налабать таблицу выбора? А в чём проблема? Если использумая разработчиком технология - ООП, то да - 100 классов и пусть полиморфизм сам разбирается, он для того и придуман. А если нет - то можно и таблицу, но тогда это не ООП и ругать его нечего. Я так думаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2006, 07:31:54 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
да прекратить дальнейшие ооспекуляции, хотелось бы акцентировать внимание общественности на том что суть оопа это не три известных мега-слова (которые являются критериями объ.ориент-ности языка). Суть же выражается оо-коаном "Tell Don't Ask", ну и более точно выражается в правильном распределении ответсвенности. ООП это не нарожать кучу классов!!! ну вот где то так ... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2006, 11:11:47 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
exppце кот Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. можно я map у из файла грузить не буду а то работать нада ... 1. new OsDescisioner(); - это опечтка? 2. Я предлагал изменить правило сравнения только для windows (т.е. для unix - equals, для windows - startWith), ваш вариант поэтому не подходит. 3. В примере были более сложные условия выбора. У вас оно выглядело бы так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. Когда понадобится в другом месте использовать аналогичный выбор, то получится ещё большое дублирование: Код: plaintext 1. 2. 3. 4. 5. 6. 7. Учитывая, что эти фрагменты будут писать разные люди, какова вероятность, что все такие куски кода будут изменяться одновременно и корректно? Да никакой. И почему статический мап, в который можно внести изменения из любого фрагмента кода лучше, чем класс, содержащий туже функциональность? Нет никаких объяснений, кроме фанатичной преданности "мапе". 4. Грузить из файла? Зачем?! expp NotGonnaGetUs Я уже писал, таблицы порой даже проигрывают if/else, т.к. они фиксируют алгоритм сравнения. не а. мапы рулят. нужен алгоритм сравнения пишем IEqulizer - и фаны closure показывают всю свою мощь Т.е. каждая запись в мапе содержит проинициализированный IEqulizer и строку результат? А зачем тогда тут map, если это чистой воды list (сторку-результат легко забросить через параметр в IEqulizer) ? А вообще, да... Мапы рулят. Зачем нам классы, статическая типзация, полиморфизм, инкапсуляция и т.д. и т.п., если любой объект можно промоделировать map'ой? Моделировать средствами ООЯзыков паттерны процедурных языков - это круто... expp NotGonnaGetUs Необходимость избавления от этой фиксации приведёт к необходимости реализации различного рода интерпретаторов (те самые дсл и кастрированные языки), а это существенно большее усложнение решения, чем использование полиморфизма для избавления от ветвлений. для клинических случаев дсл и кастро языки или plug-in class (каждый раз что то новое придумываю - воистину не исчерпаемая затача таксономии ОСов). дсл и кастро языки уже есть бери и юзай если надо. не надо приплетать сюда полиморфизм чтобы показать, что он "не вывозит" А я опять скажу "дсл и кастрированные языки это существенно большее усложнение решения, чем использование полиморфизма". Анекдот в том, что все эти dsl-и, плагины и десишин мапы приводят к коду обладающими всеми недостатками динамически типизированных языков и практически никаким плюсам. expp NotGonnaGetUs В ООЯзыке этот "паттерн" вшит, называется "полиморфизм". вы открываете мне глаза, значит я дурак всю жизнь конфиги своих прог (которые не достойны отдельных файлов, и поэтому) держал в статик мапах, а надо было кучей классов делать ... а потом ещё фабрику примострячивать для их создания - стопудовый отстрел своих ног. Мы не "конфиг" пишем. А в целом вы правы. Зря статик мапы держали. Вместо: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Куда лучше написать по-человечески, вынеся все проверки из runtime в compile time: Код: plaintext 1. 2. 3. 4. 5. 6. 7. expp NotGonnaGetUsЧто значит "выкобениватья на немерлях"? это значит злобать на них helloworld не убившись от стену, восклицать : "буть прокляты годы на с# (жабе и т.п.)" ... smalltalk, lisp, oberon, OODB, ai тоже реальность Я не испытываю никакой радости от возможно написать helloword вне class {void main{}}. Что меня радует так это: - кратность нотации без потери статической типизации, - вывод типов (фактически возможность локально применять duck typing), - возможность делать больше проверок при компиляции средствами языка (таже валидация sql), - паттерн матчинг и record'ы, для того чтобы забыть о проблемах с if-ами и возвращением множественных значений, - оптимизация хвостового вызова (долой неукюжие for'ы для раскрутки стека) expp NotGonnaGetUsЕсть пример DLINQ от МS. Языки like nemerle уже реальность. про jdk7 я конечно рад closure и delegateам в ущербном жабаязыке, но думаю никогда их использовать не буду т.к. они явлются излишней мутью, необходимой только их авторам Смеха ради, почитайте как используются ущербные лямбды в DLINQ'е. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2006, 13:13:29 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
teb Дык... мил-человек... разве ООП инструмент для решения абстрактных задач? Друк! Декларируется, что ООП не просто инструмент для решения задач, а инструмент, которым можно создавать решения годные для повторного использования. Однако для того, чтобы это стало реальностью, недостаточно сесть и начать "писать классы". Нужно учиться, нужно понимать откуда ростут ноги у "волшебных" возможностей ООП. Конечно, можно отказаться этой возможности и других, и страгать на ООЯ в стиле "plain c", но тогда к чему все эти слова о "распределении обязанностей", гибкости решений и т.п.? teb grexhide вдруг начали с "общего перепугу" натягивать Так "натягивать" - это не ООП. Вот NotGonnaGetUs этим как раз и занялся в своём примере. Мне так каэтся. В его примере правильно - это как раз банальное наследование, а он начал вместо конкретизации городить абстракцию, которая задачей не требуется. И получилось плохо. Чему удивляться? Солнышко! Ну покажи, наконец-то, дурачку как правильно классы писать. Приведи решение, аргументируй почему оно гибче/лучше того, что приводил я. Покажи как оно будет меняться при возможных изменениях тербований. И все станут счастливы. Зачем сидеть и просто так "удивляться"?! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2006, 13:25:51 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
какбытькакжитьА если этих вариантов (поведений) 50-100? Что, 100 классов наследовать? А как в одиночку с этим справиться, может проще как советует expp, налабать таблицу выбора? А ты просто попробуй, поделишься потом впечатлениями :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2006, 13:27:57 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
NotGonnaGetUs1. new OsDescisioner(); - это опечтка? да. создаём конкретный EqualsOsDescisioner, StartWithOsDescisioner. NotGonnaGetUs2. Я предлагал изменить правило сравнения только для windows (т.е. для unix - equals, для windows - startWith), ваш вариант поэтому не подходит. такое изощрение лечиться wildcardами или сразу regexpами NotGonnaGetUs 3. В примере были более сложные условия выбора. У вас оно выглядело бы так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. И почему статический мап, в который можно внести изменения из любого фрагмента кода лучше, чем класс, содержащий туже функциональность? Нет никаких объяснений, кроме фанатичной преданности "мапе". Collections.unmodifableMap и воьще поставить с default доступом NotGonnaGetUs4. Грузить из файла? Зачем?! а вот это помоему действительно нужный функционал - конфигурировать прогу неперекомпиляя её. во всяком случае очень много людей думают так же NotGonnaGetUs Т.е. каждая запись в мапе содержит проинициализированный IEqulizer и строку результат? нет каждая DescistionTable имеет свой IEqulizer. NotGonnaGetUs А зачем тогда тут map, если это чистой воды list (сторку-результат легко забросить через параметр в IEqulizer) ? да. при извратской логике доступ по ключу не нужен - просто список пар. NotGonnaGetUs А вообще, да... Мапы рулят. Зачем нам классы, статическая типзация, полиморфизм, инкапсуляция и т.д. и т.п., если любой объект можно промоделировать map'ой? Моделировать средствами ООЯзыков паттерны процедурных языков - это круто... пишу буквами побольше ни нужен тут этот рукав (полиморфизм) NotGonnaGetUs А я опять скажу "дсл и кастрированные языки это существенно большее усложнение решения, чем использование полиморфизма". Анекдот в том, что все эти dsl-и, плагины и десишин мапы приводят к коду обладающими всеми недостатками динамически типизированных языков и практически никаким плюсам. анекдот очень смешной. полиморфизм штука статическая. задача проще решать как динамическую. NotGonnaGetUs Мы не "конфиг" пишем. повторюсь. это и есть конфиг, нах. NotGonnaGetUsА в целом вы правы. я всегда прав... NotGonnaGetUsЗря статик мапы держали. Вместо: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Куда лучше написать по-человечески, вынеся все проверки из runtime в compile time: Код: plaintext 1. 2. 3. 4. 5. 6. 7. какая то странная прога её для виндов перекомпилять нада???? решение вроде принимается исходя из значения runtime ? NotGonnaGetUs Я не испытываю никакой радости от возможно написать helloword вне class {void main{}}. Что меня радует так это: - кратность нотации без потери статической типизации, - вывод типов (фактически возможность локально применять duck typing), - возможность делать больше проверок при компиляции средствами языка (таже валидация sql), - паттерн матчинг и record'ы, для того чтобы забыть о проблемах с if-ами и возвращением множественных значений, - оптимизация хвостового вызова (долой неукюжие for'ы для раскрутки стека) круто, рад за вас.... нахер всё это. дайте жабу да будет свет!!! NotGonnaGetUsСмеха ради, почитайте как используются ущербные лямбды в DLINQ'е. всё бросил и пошёл читать ... буду как приду ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2006, 14:52:46 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
expp NotGonnaGetUs2. Я предлагал изменить правило сравнения только для windows (т.е. для unix - equals, для windows - startWith), ваш вариант поэтому не подходит. такое изощрение лечиться wildcardами или сразу regexpами Такое изощрение лечить не надо. Нужно лечить того, кто для определения типа ОS по имени предалагает вместо класса содержащего простой метод (вроде s.equals("Linux") || s.equals("SunOS")) что-то параметризовывать и интерпретировать (да ещё с регэкспами). expp NotGonnaGetUs Т.е. появляется дублирование. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. Осталось привести код, как избавиться от дублирования в случае с "anotherDscTable"... чтобы понять всё удобство использования map вместо полиморфизма. expp Collections.unmodifableMap и воьще поставить с default доступом Круто... expp NotGonnaGetUs4. Грузить из файла? Зачем?! а вот это помоему действительно нужный функционал - конфигурировать прогу неперекомпиляя её. во всяком случае очень много людей думают так же Внешняя конфигурация усложняет код, далеко не всегда такое усложнение оправданно. expp NotGonnaGetUs Т.е. каждая запись в мапе содержит проинициализированный IEqulizer и строку результат? нет каждая DescistionTable имеет свой IEqulizer. Я привёл пример, когда одним equlizer'ом не обойтись. Только не надо опять об регэкспах. expp NotGonnaGetUs А зачем тогда тут map, если это чистой воды list (сторку-результат легко забросить через параметр в IEqulizer) ? да. при извратской логике доступ по ключу не нужен - просто список пар. "Извратской" и трудно реализуемой данная логика становится только при использовании вашего решения. В приводившихся выше вариантах это совсем не проблема. expp NotGonnaGetUs А вообще, да... Мапы рулят. Зачем нам классы, статическая типзация, полиморфизм, инкапсуляция и т.д. и т.п., если любой объект можно промоделировать map'ой? Моделировать средствами ООЯзыков паттерны процедурных языков - это круто... пишу буквами побольше ни нужен тут этот рукав (полиморфизм) Ну так обоснуйте... expp NotGonnaGetUs А я опять скажу "дсл и кастрированные языки это существенно большее усложнение решения, чем использование полиморфизма". Анекдот в том, что все эти dsl-и, плагины и десишин мапы приводят к коду обладающими всеми недостатками динамически типизированных языков и практически никаким плюсам. анекдот очень смешной. полиморфизм штука статическая. задача проще решать как динамическую. Что-то не пойму в каком смысле вы используете слова статическая/динамическая. Полиморфизм - шутка "динамическая", т.к. вызов метода происходит на основе рантайм информации, и к статической/динамической типизации отношения не имеет. Почему вам проще связать таблицу с интерпретируемым языком вместо того, чтобы написать один класс - не знаю. А ещё говорили, что код на динамичеки типизируемых языках "отстрел ног"... expp NotGonnaGetUs Мы не "конфиг" пишем. повторюсь. это и есть конфиг, нах. Неа. Это не конфиг. Это вывод сообщения в зависимости от типа ос/цвета шерсти кролика/чего угодно другого. Не забывайте, что начали мы с замены гирлянды if/else на что-то нибудь более подходящее. Каждый if/else будем выводить в файл? А если вместо печати строки нужно подстричь газон/сходить под кустик? Эти действия тоже в файл пойдут? Вы упорно продолжаете пытаться показать, что частное решение, уместное в процедурных языках (где нет полиморфизма), может быть успешно примененно в ООЯзыках. Его применить-то можно, но успешно нет. Полиморфизм решает подовляющее количество подобных задач существенно проще. Выносить логику в файлы конфигурации в данном случае не оправданно абсолютно. expp NotGonnaGetUsЗря статик мапы держали. Вместо: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Куда лучше написать по-человечески, вынеся все проверки из runtime в compile time: Код: plaintext 1. 2. 3. 4. 5. 6. 7. какая то странная прога её для виндов перекомпилять нада???? решение вроде принимается исходя из значения runtime ? Слава богу. А то, я уж грешным делом подумал, что вы всё и всегда кладёте в статик мапы. Тогда проясните: Вы создавали на каждое проперти по статик мапе? Или у вас была статик мапа с единственным проперти, которое само по себе было мапа? При любом раскладе не могу понять почему interface, содержащий набор getter'ов, классы реализации для разных OS и фактори метод (для получения подходящей реализации интерфейса) будут хуже для конфигурирования приложения, чем десишин мап, через который можно выбрать мап, в котором лежат какие-то пары значений (и для ключей которых наверняка заведены константы)... expp NotGonnaGetUs Я не испытываю никакой радости от возможно написать helloword вне class {void main{}}. Что меня радует так это: - кратность нотации без потери статической типизации, - вывод типов (фактически возможность локально применять duck typing), - возможность делать больше проверок при компиляции средствами языка (таже валидация sql), - паттерн матчинг и record'ы, для того чтобы забыть о проблемах с if-ами и возвращением множественных значений, - оптимизация хвостового вызова (долой неукюжие for'ы для раскрутки стека) круто, рад за вас.... нахер всё это. дайте жабу да будет свет!!! Нахер? Всё? Точно? :) Вот и поговорили. expp NotGonnaGetUsСмеха ради, почитайте как используются ущербные лямбды в DLINQ'е. всё бросил и пошёл читать ... буду как приду %) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2006, 16:00:17 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
NotGonnaGetUs Извините за офтопик... а почему nemerle а не groovy? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2006, 16:38:05 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
------>>> как избавиться от дублирования в случае с "anotherDscTable"... надо на неё посмотреть чем она another ... в крайнем случае putAll() ------>>> Внешняя конфигурация усложняет код, далеко не всегда такое усложнение оправданно. угу. вот сложность то - дёрнуть Property ортодоксальный полиморфизм ограничен статическим набором типов (я знаю что и в жабе можно во время работы создавть классы, а в динамических язывак ваще ...). но придерживаюсь именно статического набора классов. ну а "вызов метода происходит на основе рантайм " ----->>>Почему вам проще связать таблицу с ... Ну сложилось так. просто и всё ----->>>Каждый if/else будем выводить в файл? А если вместо печати строки нужно подстричь газон/сходить под кустик? Эти действия тоже в файл пойдут? В ФАЙЛЕ ПИШЕМ МАПУ ось1=решение ос2=решение ос*=решение_с_wildcardой, что не понятно??? ----->>>Вы упорно продолжаете пытаться показать, что частное решение, уместное в процедурных языках (где нет полиморфизма), может быть успешно примененно в ООЯзыках.Его применить-то можно, но успешно нет. Полиморфизм решает подовляющее количество подобных задач существенно проще. ДА НЕ ЭТИ ЗАДАЧИ ОН РЕШАЕТ!!! это просто подходящее решение этой задачи - на любом языке. ----->>>Выносить логику в файлы конфигурации в данном случае не оправданно абсолютно. нафига тогда её туда выносят??? ----->>>Вы создавали на каждое проперти по статик мапе? Или у вас была статик мапа с единственным проперти, которое само по себе было мапа? убился ап текст ... ещё раз. Есть Descisioner c интерфейсом которого и работает клиент - даёт ему значение из системного окружения, берёт от него решение. Больше его ничего не волнует. Самая простая реализация Descisionerа использует статичну мапу, другая грузит таблицу из файла. Этим достигается разделение кода и данных к сожалению иногда выходят новые ОСы , и примерно после того как ваша прога с лапшой откомпилирована и установлена. Что проще перехреначить лапшу, впендюрить новый класс или добавить строчку в конфиг. То же самое справедливо и для чуваков на суппорте - тех у кого есть исходники, даже им по моему проще в мапу внести новую пару вот и потрепались ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2006, 16:54:47 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
expp------>>> как избавиться от дублирования в случае с "anotherDscTable"... надо на неё посмотреть чем она another ... в крайнем случае putAll() Как чем another... Там решения другие принимаются в зависимости от типа ос. putAll куда писать? expp ------>>> Внешняя конфигурация усложняет код, далеко не всегда такое усложнение оправданно. угу. вот сложность то - дёрнуть Property ----->>>Каждый if/else будем выводить в файл? А если вместо печати строки нужно подстричь газон/сходить под кустик? Эти действия тоже в файл пойдут? В ФАЙЛЕ ПИШЕМ МАПУ ось1=решение ос2=решение ос*=решение_с_wildcardой, что не понятно??? ----->>>Выносить логику в файлы конфигурации в данном случае не оправданно абсолютно. нафига тогда её туда выносят??? Есчо рас. Мы изначально говорили о лапше if/else. Вы всё сводите к задаче конфигурации. Смотрим на два фрагмента кода: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Как тут обойтись десишин мапами с любый хитрости икволайзерами? Как инициализировать мапы и при этом не дублировать код? Да, и зачем всё это сохранять в файл? expp ----->>>Почему вам проще связать таблицу с ... Ну сложилось так. просто и всё Т.е. просто "вредная" привычка? 6) expp ----->>>Вы упорно продолжаете пытаться показать, что частное решение, уместное в процедурных языках (где нет полиморфизма), может быть успешно примененно в ООЯзыках.Его применить-то можно, но успешно нет. Полиморфизм решает подовляющее количество подобных задач существенно проще. ДА НЕ ЭТИ ЗАДАЧИ ОН РЕШАЕТ!!! это просто подходящее решение этой задачи - на любом языке. Огласите "задачу", а то мне кажется вы говорите о чём-то "своём". expp ----->>>Вы создавали на каждое проперти по статик мапе? Или у вас была статик мапа с единственным проперти, которое само по себе было мапа? убился ап текст ... ещё раз. Есть Descisioner c интерфейсом которого и работает клиент - даёт ему значение из системного окружения, берёт от него решение. Больше его ничего не волнует. Самая простая реализация Descisionerа использует статичну мапу, другая грузит таблицу из файла. Этим достигается разделение кода и данных к сожалению иногда выходят новые ОСы , и примерно после того как ваша прога с лапшой откомпилирована и установлена. Что проще перехреначить лапшу, впендюрить новый класс или добавить строчку в конфиг. То же самое справедливо и для чуваков на суппорте - тех у кого есть исходники, даже им по моему проще в мапу внести новую пару Ок, ещё раз. Поговорим о конфигурации приложения. В зависимости от типа ос (o1, o2, o3) могут настриваться несколько параметров (p1, p2, p2). Как это сделать при помощи мап? Вижу один вариант: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. Как это сделать по-человечески: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Нужно вынести конфигурацию за пределы приложения? Вместо "регэкспов" прописываем в конфиг файла имена классов o1p/o2p/etc, среди которых будет искаться подходящая реализация (читает конфиг фактори). В отличии от map, в этих реализациях могут быть не только строки текста, но и код, который без всякой перекомпиляции будет готов к выполнению. Где я не прав, говоря, что полиморфизм тут более чем уместен? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2006, 17:33:18 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
NotGonnaGetUsСмотрим на два фрагмента кода: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Во избежание не понимания: Это два блока 100% аналогичных друг другу if/else, различающихся только выбором действия. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2006, 17:39:54 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
пы-лять ... чо за склонность к изврату. задача стояла так. Принять решение в виде строки исходя из строкового свойства окружения. Т.е. у оса был один параметр а не много как в последних креативах ... я говорю 1. как быдлокодера меня не скребёт сама логика принятия решения. я делаю дырку для припендюривания разных логик и забываю оп этом. 2. быдлокодера налепившего ифов придётся порешить при попытке в них разобриться или существенно прорефакторить каркас - например переделать решение в <код, строка> 3. быдлокодера налепившего для каждого case'а класс нужно сдать в html дизайнеры где он сможет раскрыться в css говно вопрос и трёп закончен ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.12.2006, 18:18:00 |
|
||
|
Объектно-ориентированный vs хакерский подход к программированию
|
|||
|---|---|---|---|
|
#18+
exppпы-лять ... чо за склонность к изврату. задача стояла так. Принять решение в виде строки исходя из строкового свойства окружения. Т.е. у оса был один параметр а не много как в последних креативах ... Не надо истерии. Задача состояла в другом: показать как может выглядять решение в ОО-стиле и чем оно будет лучше/хуже решения в "процедурном" стиле. Очевидные этапы решения: 1. Определение типа ОS по имени 2. Выбор действия в зависимости от типа OS. 3. Выделение и изоляция алгоритма определения типа OS (обеспечение точки расширения) if/else при водит к ребусу, в котором все эти действия соединены воедино. Маp - ещё больше запутывает решение, т.к. приводит к большому количеству "если" разрешаемых только в runtime (в отличии от легко верифицируемого набора if/else). А когда дело доходит до дублирования структуры if/else, map'ы, в общем случае, оказываются ещё хуже (я приводил примеры (anotherMap, etc)). Ясное (как день) описание каждого из этапов в ОО-нотации почему-то приводит вас в ужас. expp я говорю 1. как быдлокодера меня не скребёт сама логика принятия решения. я делаю дырку для припендюривания разных логик и забываю оп этом. А кому-то потом приходится вспоминать и ругаться матом автора дырки, потому что логики приходится именно "впендюривать" :) expp 2. быдлокодера налепившего ифов придётся порешить при попытке в них разобриться или существенно прорефакторить каркас - например переделать решение в <код, строка> Вы всё-таки определитесь: все if'ы заменять на мапы и выносить ветки в конфигурационные файлы, или только те, где действительно производится конфигурация приложения? :) expp 3. быдлокодера налепившего для каждого case'а класс нужно сдать в html дизайнеры где он сможет раскрыться в css А налепившего на каждый case' по десишн мап куда надо сдать? В perl-программисты? :) exppговно вопрос и трёп закончен Если бы вы не трепались, а проявили больше конструктива, то вопрос не стал бы гавном :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2006, 11:40:21 |
|
||
|
|

start [/forum/topic.php?all=1&fid=59&tid=2147097]: |
0ms |
get settings: |
17ms |
get forum list: |
17ms |
check forum access: |
6ms |
check topic access: |
6ms |
track hit: |
59ms |
get topic data: |
18ms |
get forum data: |
4ms |
get page messages: |
132ms |
get tp. blocked users: |
2ms |
| others: | 320ms |
| total: | 581ms |

| 0 / 0 |
