Исходное сообщение
"Выход Mono 3.0, открытой реализации платформы .Net " Отправлено Xasd, 23-Окт-12 18:00
> ахах, неосилятор ООП. Кто же вам сказал, что разработка архитектуры - простое дело? настолько сложное что приходится быть ясновидящем-экстрасенсом? """написал кодер дерево и увидел, что это хорошо.. и отнаследовал от него всё""" (C) http://ibash.org.ru/quote.php?id=15589 ну невозможно написать ООП-программу (библиотеку) именно таким образом чтобы была возможно её дальнейшего плавного улучшения. всегда ООП-программа (библиотека) оказывается в конечном счёте хреново-спроектарованной, и приходится её координально ПЕРЕпроектировать. либо НЕ_перепроектировать, а костыльно извращаться, чтобы внедрить улучшение "дешевыми" трудозатратами. другими словами ООП-код НЕ является расширяемым. и может являеться хорошо спроектированным ТОЛЬКО на текущей момент времени. > И как показывает опыт, сопровождать грамотно спроектированную систему на ООП на порядки проще, чем пытаться менять что-то в коде, как вы говорите - структуры+функции нет. нет. я не спорю что ТЕОРЕТИЧЕСКИ ооп является может быть и что-то хорошее. но вот именно практическая реализация ООП в языках прогрограммирования C++-подобной-форме -- это явный тупик. да, мне например нравится как ООП реализованно в ЯП Go. и говоря про ООП именно в контексте ЯП Go -- я скажу -- да ООП это хорошо.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> ахах, неосилятор ООП. Кто же вам сказал, что разработка архитектуры - простое дело? > настолько сложное что приходится быть ясновидящем-экстрасенсом? > """написал кодер дерево и увидел, что это хорошо.. и отнаследовал от него > всё""" (C) http://ibash.org.ru/quote.php?id=15589 > ну невозможно написать ООП-программу (библиотеку) именно таким образом чтобы была возможно > её дальнейшего плавного улучшения. > всегда ООП-программа (библиотека) оказывается в конечном счёте хреново-спроектарованной, > и приходится её координально ПЕРЕпроектировать. либо НЕ_перепроектировать, а костыльно > извращаться, чтобы внедрить улучшение "дешевыми" трудозатратами. > другими словами ООП-код НЕ является расширяемым. и может являеться хорошо спроектированным > ТОЛЬКО на текущей момент времени. >> И как показывает опыт, сопровождать грамотно спроектированную систему на ООП на порядки проще, чем пытаться менять что-то в коде, как вы говорите - структуры+функции > нет. нет. я не спорю что ТЕОРЕТИЧЕСКИ ооп является может быть и > что-то хорошее. > но вот именно практическая реализация ООП в языках прогрограммирования C++-подобной-форме > -- это явный тупик. > да, мне например нравится как ООП реализованно в ЯП Go. и говоря > про ООП именно в контексте ЯП Go -- я скажу -- > да ООП это хорошо.
	Введите код, изображенный на картинке: