[ООП] Как использовать на практике?

А если серьезно, то из-за таких, как он, о нас, школьниках, так плохо думают. Позорище.

Начал изучать общие положения ООП.
Так и не понял, зачем они нужны?

рекомендую почитать Gamma design patterns

Спасибо, уже все понял, меня просветили

Хм. Ну я бы наверное оформил субкласс, чтобы можно было засовывать собственный кустомизированный Plotter везде, где требуется обычный.

Не, это не потребуется. Он будет рисовать только мой field, больше ничего.

или даже делать интерфейс для разных либ и подключать в плоттер уже их

Думаю, это имеет смысл.

GoF != design patterns ?

Это был не сарказм :)

изучил общие положения ООП(наследование, инкапсуляция, полиморфизм),

но так и не понял как использовать его на практике

/0

Инкапсуляция, допустим, к ООП никаким боком. А что неясно с полиморфизмом и наследованием?

Давай, сошлись на отцов-основателей с многотомными талмудами и задвинь разоблачительную речь. Только потом обязательно не забудь объяснить, чем это поможет ТСу понять ООП.

В CLOS, к примеру, «функции» не принадлежат «данным» - и ничего, ооп во все поля. Наверное, лучше было бы сказать, что ооп, в первую очередь, это сахар, который дает +100500 (килокалорий) к удобности наследования некоторых поведенческих свойств.

Ты бы еще хаскель вспомнил. ООП ООПу рознь.

раньше я торчал в Development'е на ЛОРе, и практически не заходил в другие разделы. нынче каждый второй пост (прежде всего - комментарии к нему) здесь делает меня разочаровываться в человечестве

Ты кстати это, «следи за собой, будь осторожен» - тоже в последнее время ничего дельного, кроме эмоциональных всплесков в developments, практически не оставляешь... особенно, если сравнить с годом 2008-м, к примеру

А если серьезно, то из-за таких, как он, о нас, школьниках, так плохо думают. Позорище.

По-моему еще рано озадачиваться ООП. В общем, забей лет до 18. Я вполне серьезно.

писать код надо, а ООП само вылезет

говнокод в итоге выйдет

архитектуру сначала обдумывают
потом ее заворачивают в прадигмы ООП
а потом уже каждый компомент архитектуры можно раздать на программистов-разработчиков которые и будут кодить

А давай ему ещё LoL посоветуем. Напишет свою объектную систему, глядишь и поймёт зачем она ему нужна.

Возможно ли такое вобще?

Элементарно. Определяешь класс, описывающий определённый плоттер:

(defclass plotter ()
    (перечень-опций-определяющих-рисовалку))

Класс для графика:

(defclass field ()
   (данные-графика))

Определяешь обобщённую функцию, рисующую этот график этим плоттером

(defgeneric plot (plotter field))

Затем создаёшь рисовалку, инициализируя нужными опциями, и график..

(defvar *plotter* (make-instance 'plotter :opt1 "A" :opt2 0.1 :opt3 "red"))

(defvar *field* (make-instance 'field ...))

(plot *plotter* *field*)

Не понимаю, почему plot - обобщённая функция, а не метод плоттера?

В остальном, примерно так себе всё и представляю. Будет время, забацаю, поглядим, насколько это удобнее чем то что есть сейчас.

Потому что

Определяешь обобщённую функцию, рисующую этот график этим плоттером

Сахар не важен. Важна суть.

А почему плот --- метод плоттера, а не метод графика данных?

Поведение рисовалки в равной степени зависит, как от того что, рисуют, так и от того, на чём рисуют. Так и зачем городить в программе лишние связи?

Позволю себе большую цитату из PCL:

Мультиметоды полезны в ситуациях, когда вы не знаете к какому классу определенное поведение должно относиться (в языках с передачей сообщений). Звук, который издает барабан, когда вы стучите по нему палочкой, является функцией барабана, или функцией палочки? Конечно, он принадлежит обоим предметам. Для моделирования такой ситуации в Common Lisp, вы просто определяете функцию beat, которая принимает два аргумента.

(defgeneric beat (drum stick)
  (:documentation
   "Produce a sound by hitting the given drum with the given stick."))

Затем, вы можете определять разные мультиметоды для реализации beat для комбинаций, которые вам нужны. Например:

(defmethod beat ((drum snare-drum) (stick wooden-drumstick)) ...)
(defmethod beat ((drum snare-drum) (stick brush)) ...)
(defmethod beat ((drum snare-drum) (stick soft-mallet)) ...)
(defmethod beat ((drum tom-tom) (stick wooden-drumstick)) ...)
(defmethod beat ((drum tom-tom) (stick brush)) ...)
(defmethod beat ((drum tom-tom) (stick soft-mallet)) ...)

Мультиметоды также спасают вас от требования чтобы один набор классов был тесно связан с другим набором. В нашем примере барабанов/палочек, не требуется чтобы класс, представляющий барабаны знал о различных классах, представляющих барабанные палочки, и наоборот. Мультиметоды связывают независимые классы для описания их совместного поведения, при этом не требуя никакого взаимодействия между самими классами.

Чтобы начать писать в ОО-стиле нужно сначала научиться проектировать в нем. Интересные примеры — GUI, имитационное моделирование, возможно, мультиагентное моделирование. В принципе те же акторы можно реализовать в виде объектов. А вообще, cast yoghurt.

Поведение рисовалки в равной степени зависит, как от того что, рисуют, так и от того, на чём рисуют. Так и зачем городить в программе лишние связи?

Дело в том что рисовалка, которая умеет рисовать всё что угодно, знает как и на чём, уже есть в библиотеке matplotlib. Мне наоборот нужно привязать рисовалку именно к моему типу данных. Т.е. надоело писать:

axis=matplotlib.pylab.gca()
axis.contour(field.grid.lons, field.grid.lats, field.data[time,lev,:,:], levels=my_clevs, cmap=my_colormap, ...)
axis.set_title(...)
axis.xaxis.set_formatter(...)
axis.yaxis.set_formatter(...)
и т.д.

Хочется всё это делать одной короткой командой. Сейчас этим занимаются методы Field, что захламляет класс. Была идея вынести всё в отдельный класс Plotter, привязанный к Field, который знает как его рисовать. Если это дурной тон в ООП, и грамотнее использовать обобщённую функцию field и рисовалки, тогда я не вижу смысла создавать ещё одну рисовалку вдобавок к стандартной.

простую жизненную систему(в упрощенном виде)

игра «Жизнь» отлично подходит

Ты смысла слов не понимаешь? Или тролишь ? :)

Видимо, это из-за того, что ты никого не слушал, и зажмурившись нырнул в кодинг. Это «говно» позволяет сэкономить огромный объем работы, поскольку дает возможность быстро, без написания многих тысяч строк кода, понять, как будет функционировать твоя система; на раннем этапе выявить и скорректировать изъяны.

Та нихера. Максимум - это нарисовать быстро что-то на доске соседу-программисту.

Нет, не равно, существует куча производных Например, паттерны асинхронного программирования, не менее важные

Согласен, но это отправная точка разжеванного материала

код open-source проектов

Мне кажется можно взять любой известный проект на python и позалипать. Что-нибудь полезное должно отложиться.

Ты смысла слов не понимаешь?

Понимаю, ты имеешь ввиду сделать, как положено по методичке, программу-автозаправку, кафе и пр. Я предлагаю лучше игра «Жизнь» достаточна проста, можно использовать ООП, плюсом будет математический смысл игры.

Или тролишь ?

Ни в коем разе. Почем ты так думаешь?

Ты тогда, наверное, и вместо str(объект) собираешься писать объект.__str__()? Для Ъ.
;-)

В CLOS, к примеру, «функции» не принадлежат «данным» - и ничего, ооп во все поля.

И это прекрасно. Вообще, методы принадлежащие объектам — это какой-то бред вселенского масштаба. Почему они так долго в мейнстриме — большая загадка для меня.

Наверное, лучше было бы сказать, что ооп, в первую очередь, это сахар, который дает +100500 (килокалорий) к удобности наследования некоторых поведенческих свойств.

Плохо формализуемая эвристика это. Эдакая житейская парадигма, которую каждый понимает по-своему.

Ты бы еще хаскель вспомнил. ООП ООПу рознь.

Почему бы и нет?

Вообще, методы принадлежащие объектам — это какой-то бред вселенского масштаба. Почему они так долго в мейнстриме — большая загадка для меня.

Инкапсуляция же.

Я хочу, чтобы Кнут, когда увидит мой код, пустил слезу умиления и помолодел лет на 20 от радости.

В CLOS, к примеру, «функции» не принадлежат «данным»

Не принадлежат, но относятся поскольку саязаны.

Напишет свою объектную систему, глядишь и поймёт зачем она ему нужна

Ви будете смеяться, но таки да.

Я знаю.

С тем же успехом можно сказать: «В CLOS обекты принадлежат функциям».

Не ну если хочется сказать какую-нибудь фигню то конечно. Но лучше не надо.

Правильно. Поэтому говорить: «В CLOS функции принадлежат объектам» не нужно.

Заметь я отвечал на это

В CLOS, к примеру, «функции» не принадлежат «данным

В CLOS методы (ваши"фунции») определены на классах («данных»). Даже если этот класс T:). В этом смысле говорить о том что они не принадлежат данным еще более некоректно чем о том что они им принадлежат:) Другой вопрос что метод в CLOS может быть определен на нескольких классах в отличии с++/java (я знаю про возможные извращения, но это не то) и в этом смысле «принадлежать» (в переносном смысле) сразу нескольким классам.

Словоблудие какое-то. Делать из заключения «обобщённая функция принимает объекты классов a, b и c» вывод «обобщённая функция принадлежит классам a, b и c» --- это я не знаю кем надо быть.

Не было гвоздя - «брось новое ПодковоГвоздьНеНайденИсключение(„гвоздей нет!“)

Не было подковы - „ЛошадеДоктор.получитьМестнуюКопию().получитьЛошадеДиспетчер().давайделай()

Лошадь захромала - СкаковойКлуб.получитьСсписокОповещенияПодписчиковНаездников().получитьРассылателя().вперед(новое СообщениеРассылка(Конюшня.получитьНулевойЛошадеОбразец()))

Ну и тут возникает вопрос: всякий ли полиморфизм является признаком объектно-ориентированного подхода. Очевидно, что не всякий.

Т.е. ты _можешь_ используя обобщенные функций писать код в парадигме ООП, но ты _можешь_ и не писать. Как раз потому, что данный подход не создаёт по дефолту обязательной привязки «тип данных -> методы», эту привязку программист может у себя в голове эмулировать, если хочет.

Я изучил общие положения ООП(наследование, инкапсуляция, полиморфизм), но так и не понял как использовать его на практике.

Никак. Это как Кобол — кода написано до фига, но штука практически дохлая.

Рулят в индустрии интерфейсы и дженерики.

Какие ужосы вы говорите.

SICP советовали? Ловсанчег уже прибегал со своим «ко-ко-ко только в CLOS и MOP настоящее ООП ко-ко-ко»?

Инкапсуляция не требует, чтобы методы принадлежали объектам.

У тебя просто голова пока не достаточно загажена ООП — не думает в этих терминах, отчаянно сопротивляется.

ничего дельного, кроме эмоциональных всплесков в developments, практически не оставляешь

я прекрасно это знаю. каждый раз думаю: а не написать ли чего по существу? и каждый раз понимаю, что единственной реакцией будет что-то вроде обсуждения в этом тредике. обсуждение, в котором каждый будет доказывать какой он умный, и на вышеуказанное существо всем будет совершенно положить. оно мне надо?

в 2008 здесь было куда больше приятных собеседников. где абсурд? где лестер? где л-о-р? где гаа? где бегемот? глюкодела забанили, маклауда забанили, р и ресет почти не пишут, даже сектоиду надоело. анонимусы - и те вывелись. вот и я тоже

Есть такое.