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

обиделся

прокомментировал. ты всегда такой тупой, или это персональное представление?

отвратное качество учебной литературы

если ты не заметил, повторю: задачу имитационного моделирования популяций я считаю прекрасным учебным примером на понимание ООП

другой модуль никак не может быть написан на С++, по причинам указанным в шапке темы. Он написан на С. Я не буду делать его в виде библиотеки, т.к. мне нужно, чтобы моей программой могли пользоваться из консоли. Проблемы в том, что мне рано или поздно придется создавать свои объекты и использовать их. Как правильно?

class Trololo ():
  def settext (self, text):
    self.text  =  text
  def begin_trolling (self):
    print (self.text)

a  = Trololo()
a.settext ("Гном используют только слабаки")
a.begin_trolling ()

или

class Trololo ():
  def settext (self, text):
    self.text  =  text
  def begin_trolling (self):
    print (self.text)
  def run (self, text):
    settext (text)
    begin_trolling ()

a  = Trololo()
a.run ("Гном используют только слабаки")

Немного бредово, но идея такова: писать с использованием процедурного стиля и использовать в нем объекты или вызвать один обьект с методом run()?

ты всегда такой тупой, или это персональное представление?

Вот видишь, ты лишь подтверждаешь моё предположение. А что ты в бочку-то лезешь? Зацепило? Проблемы с самооценкой? Ничем не могу помочь.

Зацепило? Проблемы с самооценкой?

да. сижу рыдаю

Ничем не могу помочь

:'(

смотри, отхватите оба банхаммером. поцелуйтесь и помиритесь.

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

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

Может быть, кто-нибудь посоветует статьи, книги

Внезапно, SICP.

Не, за такое тут не банят.

он же не против рыбок выступал, а против ооп на уровне:

животное->собачьи->лисица и методом бегать

или фигура -> квадрат -> пря…, т.е. фигура -> прямоугольник -> ква…, т.е. … примером виртуальных методов на основе show/hide и простенького наследования.

у меня есть подозрение, что задача о «рыбках» немного другого уровня.

Программирование — это непрерывный процесс, в котором чередуются фазы

Спасибо, кэп.

Ты всё время говоришь о второй фазе

Потому что именно с этого конца нужно браться за ООП.

Не взлетит. ты никуда дальше бумажно-теоретической диаграммы классов не уедешь.

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

Во!

s/против ооп/против объяснения ооп/

Это зависит от задачи. В питоне вообще можно делать хоть так, хоть так - надо делать так, как удобней. С т.з. инкапсуляции первый вариант предпочтительней, но второй вариант может требовать меньше кода (если процедура одна и та эже для сов разных классов). Но можно вес эти разные классы отнаследовать от общего предка с таким методом, и тогда получим первый вариант и такое же кол-во кода.

Питон для изучения ООП ИМНО очень хорош.

другой модуль никак не может быть написан на С++, по причинам указанным в шапке темы. Он написан на С. Я не буду делать его в виде библиотеки, т.к. мне нужно, чтобы моей программой могли пользоваться из консоли

С-модули к питону цепляются так же просто (если не проще). ИМНО правильней делать одну либо, питоновскую обертку для консоли и питоновскую обертку для гуев. Просто на питоне парсить аргументы ком. строки лично мне куда приятнее;-)

ИМНО правильней делать одну либо

одну либУ

он же не против рыбок выступал, а против

неумение выражать мысли не является ни оправданием, ни поводом для гордости

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

неумение выражать мысли не является ни оправданием, ни поводом для гордости

ну не знаю.. я понял.

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

нас на таких примерах и учили, правда тут всё сильно зависит от подачи информации и можно с успехом не понять суть. Я вот не уверен, что адекватно понимаю всё до конца.

Потому что именно с этого конца нужно браться за ООП.

У тебя феерическая какая-то каша в голове. За проектирование вменяемой архитектуры надо браться в начале любого проекта, вне зависимости от использумых парадигм. При чем тут ООП вообще? До Смолтолка и Симулы программы на деревьях росли что ли?

Что, кстати, ничуть не отменяет того, что архитектуру почти наверняка придётся перекраивать в ходе работы. Вон даже у господа бога с первого раза не вышло, пришлось мессию посылать на рефакторинг. А куда уж нам, скромным, до него.

Неумение читать ими тем более не является. // Ваш Кэп.

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

Ну это только инкапсуляция.

Даа, вы тут щас насоветуете ТСу.

Я, кстати, тоже только изучаю ООП. Читаю сейчас этого Буча. Что с ним не так?

нас на таких примерах и учили, правда тут всё сильно зависит от подачи информации

ООП - это всего лишь набор эвристик :) «Roman numerals of computing» (c)

Какую задачу себе ставишь? Как в общих чертах её решить в процедурном стиле, и как - в объектном? Напиши, а мы уж ченить тебе подскажем, куда копать и что читать.

lshw, например. В коде используется, как я заметил, только один обьект, который является деревом элементов (компьютер->разветвление на винт, видеокарту, etc,). Это дерево выводится в консоль после завершения сбора информации.

Исходники Gtk помогут осознать нужность ООП, имхо, конечно :)

Ты мог бы написать:

Исходники Gtk помогут осознать ненужность Си, имхо, конечно :)

и сделать хороший вброс.

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

Не, лучше так:

Исходники Gtk помогут осознать ненужность Gtk, имхо, конечно :)

Но это тоже будет отход от темы ;)

\тянет руку

Можно я спрошу! Есть

class Field(object):
    data # 4х-мерный массив
    grid  # сетка
    time # массив datetime
    def plot1d():
        нарисовать одномерный график
    def plot2d():
        нарисовать двумерный график
    def plot_map():
        нарисовать карту
    def мого_разных_других_методов():

Смысл - иметь удобный инструмент для просмотра данных на сетке и построения графиков различных срезов в интерактивном режиме. Сейчас работает так:

field.plot_map()

для простого графика с параметрами по умолчанию. Если надо что-то изменить:

field.map_opts={куча опций для карты, проекция и т.д.}
field.copts={куча опций для контура}
field.cbar_opts={куча опций для colorbar()}
field.plot_map()
ax=pylab.gca()
ax.дорисовать_всё_что_надо()

Неудобно как-то. Хочется рисовать красивый график с минимумом усилий. Иметь хорошие опции по-умолчанию, но с возможностью менять. Вот уже 2 недели не могу сообразить, как бы так организовать

class Plotter:

так, чтобы

p=Plotter(опции)
p(field)

и фигак тебе сразу одномерный, двумерный график или карта годная для публикации. Возможно ли такое вобще?

только один обьект, который является деревом элементов

Ну в общем-то логично. А в чем вопрос?

ООП — всего лишь удобная обёртка над обычной процедурщиной.

Такого фейла ещё не видела природа :D

У меня разрыв шаблона. Обьектов должно быть побольше, а функций поменьше, нет? Так какого черта?

Почитай «Соврменное проектирование на С++» Андрея Александреску

Это книжка о шаблонном задротсвте, а вовсе не о применении ООП для разработки ПО.

Всё верно, Field должен хранить данные, а Plotter — рисовать. Plotter-ов может быть много разных.

Иметь хорошие опции по-умолчанию, но с возможностью менять.

Если у тебя хорошесть «хороших опций» зависит от особенностей данных, то наверное стоит завести отдельный «анализатор данных, предоставляющий наилучшие опции для данного набора».

Обьектов должно быть побольше

Объектов должно быть столько, сколько нужно. Узел тут представляет абстракцию «устройство». А вот почему автор не сделал субклассов, для меня загадка. Или сделал? Я не смотрел особо внимательно код.

Вообще тут бы Ruby или питон идеально подошел, не пришлось бы так сильно мучиться.

а функций поменьше, нет?

Функций как раз должно быть побольше. Если функция не вмещается на экранную страницу, обычно стоит задуматься. Бывают конечно и исключения, но на то они и исключения.

Я делал (и делаю). Правда под командную строку в соновном как обертку для гнуплота, но так тоже можно.

*Просветление близко* То есть я должен для удобства создать несколько обьектов в качестве абстракции и продолжать писать в процедурном стиле, используя их?

создать несколько обьектов в качестве абстракции

писать в процедурном стиле, используя их?

Бля..

Если у тебя хорошесть «хороших опций» зависит от особенностей данных, то наверное стоит завести отдельный «анализатор данных, предоставляющий наилучшие опции для данного набора».

Ага, зависит. Например, по осям может быть время, широта, долгота, уровень, соответственно форматирование разное.

Про отдельный анализатор подумаю, спасибо за намёк.

вобще запомнил одно очень хорошее (тривиальное) правило, через которое нужно прогонять каждую полученную при анализе абстракицию «независимое должно быть независимым». Она может быть очень хорошим критерием проверки адекватоности текущей модели, правда до абсурда доводить тоже не надо.

То есть я должен для удобства создать несколько обьектов в качестве абстракции и продолжать писать в процедурном стиле, используя их?

Это, наверное, не Ъ-ООП, но вполне работает.

А мне надо, чтобы Ъ.

У тебя феерическая какая-то каша в голове. За проектирование вменяемой архитектуры надо браться в начале любого проекта, вне зависимости от использумых парадигм. При чем тут ООП вообще?

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

То есть я должен для удобства создать несколько обьектов в качестве абстракции и продолжать писать в процедурном стиле, используя их?

Ну лично мне ты ничего не должен. :)

Как бы сделал я. Я бы использовал тот же набор абстракций, что используется при инициализации устройств ядром: устройства, шины, драйвера. С той только разницей, что «драйвер» не управляет устройством, а умеет перечислять его характеристики.

device — абстракция, предоставляющее аппаратное и логическое устройство. Размещается на шине (За исключением корневого устройства).

bus — device, умеющий перечислять устройства, являющиеся своими дочерними элементами. (Хм, кажется это не нужно делать отдельным субклассом, а чисто логическим понятием.)

controller — объект, знающий как обращаться с устройством заданного типа.

device имеет два набора характеристик. Первый набор — это то, что знает об устройстве его шина. Второй набор — это данные, которые может сообщить об устройстве соответствующий controller. Т.е. первый набор это то, что об устройстве знает controller его шины, а второй — что знает его собственный controller.

При старте программы инициализируется набор контроллеров. Создаётся корневое устройство. Далее для каждого устройства происходит следующее:

Какой controller может работать с данным device? Нашли нужный, прицепили к устройству.
У устройства есть дочерние узлы? Получили список узлов, для каждого рекурсивно запустили этот же алгоритм.

В результате мы имеем проинициализированное дерево устройств.

Дальше инициализируем обьект Emitter, которому скармливаем это дерево, и он выводит его в stdout. Субклассов у Emitter-а может быть много разных: под человекочитабельный текст, под xml, под json, под черта с рогами...

А, ну и писал бы я всё это на Ruby.

*Просветление наступило*

Дальше инициализируем обьект Emitter, которому скармливаем это дерево, и он выводит его в stdout. Субклассов у Emitter-а может быть много разных: под человекочитабельный текст, под xml, под json, под черта с рогами...

Interpreter же

Всё верно, Field должен хранить данные, а Plotter — рисовать.

О! Ещё вопрос.

В библиотеке matplotlib есть класс, который делает то что мне нужно, рисует. Но он ничего не знает про параметры по умолчанию, которые мне нужны. Как правильнее: выводить из него подкласс, или инкапсулировать в мой Plotter?

И да, ради интереса, как продвигается образовательный процесс товарища dpkg-i? Я слышал, что он человек одаренный, адекватный, подающий надежды.

И да, ради интереса, как продвигается образовательный процесс товарища dpkg-i? Я слышал, что он человек одаренный, адекватный, подающий надежды.

Жжошь.

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

В библиотеке matplotlib есть класс, который делает то что мне нужно, рисует. Но он ничего не знает про параметры по умолчанию, которые мне нужны. Как правильнее: выводить из него подкласс, или инкапсулировать в мой Plotter?

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