Ищу ментора(ов) по ООП (проектированию архитектуры и реализации)

Ни разу не занимался подобным, опыта нет, но хочу его получить. Создал такую тему Помощь в рефакторинге кода здесь и еще на паре форумов - везде скромное молчание, единственный дельный совет дали на ЛОРе - ссылку на книгу банды четырех и совет начать с проектирования АПИ. Книгу уже читаю, пытаюсь осознать, но мешает отсутствие общих представлений типа чем абстрактные классы отличаются от интерфейсов и т.п. Уже думаю начать не с рефакторинга существующего проекта, а с набора упражнений типа создания модульного приложения с разными ГУЯми - консольным, на Swing или другой графической библиотеке, вэб и т.п. и общим универсальным бэкендом (хоть дублирующим запрос в качестве ответа) через декоратор/мост/фасад или как это там называется. Свои мысли по поводу структуры и архитектуры появляются, но они эволюционируют с течением времени, и не знаю на чем остановиться.

В общем, ищу опытного наставника(ов). Может отсутствие реакции на мои предыдущие сообщения вызвано тем, что мой вопрос был направлен абстрактно в воздух, а надо обращаться конкретно и персонально (типа отнаследоваться от абстрактного базового класса )? Shamil1, что скажете?

0

Shamil1,
Вы пытаетесь экстраполировать мантры быдло-ООП на всю концепцию, тем самым дискредетируя идею. То что Вы говорите, вообще противоречит идее полиморфизма. Точно также можно сказать, что кнопка не должна знать, как ей отрисоваться, а между тем, именно потому что она это знает сама, мы абстрагированны от конкретной отрисовки, мы можем сказать просто "кнопка отрисуйся", а кнопка сама знает как ей отрисоваться. Это позволяет абстрагироваться от того, какой конкретно кнопке мы отсылаем сообщение "Draw". Ваши мантры противоречат самой сути ООП

Строго говоря, кнопка не знает сама, но знает, к ому обратиться, чтобы ее отрисовали

Добавлено через 27 минут
Shamil1,

Вот, кстати, наткнулся на цитату, которая как раз очень релевантна тому, что тут обсуждается, в частности, Вашей неверной трактовки абстрагирования в контексте ООП. Источник, к сожалению сдох, но вот ссылка на цитату из источника:

http://www.dekorte.com/blog_archive/index.html

In all other languages we've considered [Fortran, Algol60, Lisp, APL, Cobol, Pascal], a program consists of passive data-objects on the one hand and the executable program that manipulates these passive objects on the other. Object-oriented programs replace this bipartite structure with a homogeneous one: they consist of a set of data systems, each of which is capable of operating on itself.

0

Сообщение от asmquest Вы пытаетесь экстраполировать мантры быдло-ООП на всю концепцию, тем самым дискредетируя идею.

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

Сообщение от asmquest То что Вы говорите, вообще противоречит идее полиморфизма.

В коде мы вызываем метод Save() абстрактного класса AnimalSaver. Во время исполнения у нас вызывается метод класса HamsterSaver. Что тут противоречит? Классический пример полиморфизма.

Сообщение от asmquest Точно также можно сказать, что кнопка не должна знать, как ей отрисоваться, а между тем, именно потому что она это знает сама, мы абстрагированны от конкретной отрисовки, мы можем сказать просто "кнопка отрисуйся", а кнопка сама знает как ей отрисоваться.

Этот подход ("умная запись") оправдывает себя только в некоторых случаях (например, для GUI). В подавляющем большинстве случаев этот подход не оправдан. Никому не нужна Накладная, которая умеет сохранять себя в любое хранилище (SQL DB, xml file, in-memory DB,...) и отрисовывать себя в любом интерфейсе (web page, widows, linux,...).

Добавлено через 3 минуты

Сообщение от asmquest Строго говоря, кнопка не знает сама, но знает, к ому обратиться, чтобы ее отрисовали

Поменяли своё мнение?
Это ведь как раз про мой пример: Animal не знает, как себя сохранить, но он знает, к кому обратиться (AnimalSaver), чтобы его сохранили.

0

Сообщение от Shamil1 Поменяли своё мнение? Это ведь как раз про мой пример: Animal не знает, как себя сохранить, но он знает, к кому обратиться (AnimalSaver), чтобы его сохранили.

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

0

Сообщение от Shamil1 Например, у нас есть абстрактный (базовый) класс Animal. Животным не нужно знать, как они сохраняются. Поэтому для их сохранения добавляем уровень абстракции, отвечающий за сохранение AnimalSaver с методами Validate() и Save() . Чтобы не дублировать этот код Validate(), если вдруг мы захотим сохранять в другое место, добавляем уровень абстракции AnimalSaverToPersistentStore с методом Save(). Наша текущая реализация сохраняет в БД. Внутри Save() вызываются Update() или Insert(). Чтобы не дублировать код Save(), если вдруг мы захотим сохранять в другую БД, добавляем уровень абстракции AnimalSaverToSQL с методами Update() и Insert(). Итого у нас 4 уровня абстракции. И когда мы будем добавлять класс Hamster, нам придётся так же добавить конкретные классы HamsterSaver, HamsterSaverToPersistentStore, HamsterSaverToSQL.

напоминает ооп головного мозга

1

Сообщение от asmquest Нет не поменял. Вы просто судите по псевдооп-языкам и дурному чтиву, поэтому Вы не понимаете сути. Синтаксис object.saveTo(database) следует трактовать: посылаем сообщение к object, и мне плевать, как он будет себя сохранять, с моей точки зрения, с тз отправителя сообщения, абсолютно похрену на это, я вижу только его интерфейс. А вот сам object может делегировать операцию своего сохранения кому угодно. Но это никого не волнует из-вне, для них он просто сохраняет себя.

Ну к чему это "не понимаете", "плевать", "похрену"? Холиварить тоже можно спокойно и корректно

Что касается данного примера, то он, пожалуй, один из самых избитых. И довольно единодушно признается что object.saveTo(dataBase) - явно плохо. Часто говорят типа "объект НЕ должен знать как себя сохранять". Вы создали "сладкую жизнь" для небольшого фрагмента кода (где зовете object.saveTo) но очень дорогой ценой - теперь object должен знать все подробности dataBase. Если теперь потребуется напр xml (вместо dataBase) - опять то же самое. Выходит классический пример плохой архитектуры "все про всех знают"

1

Сообщение от Igor3D И довольно единодушно признается что object.saveTo(dataBase) - явно плохо.

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

Сообщение от Igor3D теперь object должен знать все подробности dataBase.

зачем? какое ему вообще дело до особенностей какой то там dataBase?

Сообщение от Igor3D Если теперь потребуется напр xml (вместо dataBase) - опять то же самое.

да ничего не потребуется. будет как то так:

при этом объект ничего не знает ни про xml, ни про dataBase.

в худшем случае (на языках, которые не умеют метапрограммирование)
всё что он знает - что есть некий интерфейс,
через который он может передавать свои данные.

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

0

Сообщение от hoggy да ничего не потребуется. будет как то так: C++ 1 2 object >> dataBase; object >> xml ;

Совершенно верно. И при этом оператор >> объявлен извне и имеет доступ ко всем полям класса object. Т.е. содержательную часть сохранения реализует НЕ object и НЕ dataBase, а "третье лицо" - оператор слива >>. Что, кстати, с полным правом можно рассматривать как несостоятельность концепций ООП и возврат к процедурному программированию.

Сообщение от hoggy напротив, как раз таки именно сам объект лучше всех знает собственное устройство, и знает как себя сериализовывать

А вот на деле выходит не так, см выше

Сообщение от hoggy ..его не парит

В который раз уже "радость начинающего" которому удалось что-то "круто" записать одной строчкой Думаю это и так всем понятно

0

Сообщение от Igor3D И при этом оператор >> объявлен извне и имеет доступ ко всем полям класса object. Т.е. содержательную часть сохранения реализует НЕ object и НЕ dataBase, а "третье лицо" - оператор слива >>.

вообще то >> - это оператор object

ну если вам так будет понятнее:
object.serialize(dataBase);
object.serialize(xml);

нет никакого "третьего лица".
и оно нафиг не нужно.

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

object сам знает все свои поля,
и как себя правильно сериализовывать.

нафига заводить ещё кого-то третьего,
кто будет знать про него то, что он итак о себе знает?

Сообщение от Igor3D А вот на деле выходит не так, см выше

я смотрю в сторону boost.serialization/cereal
практически идеальный дизайн,
который на сегодняшний день пожалуй что стандарт де факто
в мире с++.

то, что предлагает вы - это какое то ооп головного мозга.
архитектура ради архитектуры.
классы ради классов.

Сообщение от Igor3D В который раз уже "радость начинающего" которому удалось что-то "круто" записать одной строчкой Думаю это и так всем понятно

не распарсил этот поток сознания.

0

Сообщение от hoggy ну если вам так будет понятнее: object.serialize(dataBase); object.serialize(xml);

Не надо мне одолжений делать Не пишут так по той простой причине что класс object становится зависимым от классов dataBase и xml, и это факт весьма известный.

0

Сообщение от Igor3D Не пишут так

во-первых пишут.

я повторюсь:
в мире с++ boost.serialization/cereal - стандарт де факто.

а во-вторых:

Сообщение от Igor3D по той простой причине что класс object становится зависимым от классов dataBase и xml

это что за бред?
с какой стати, он должен от них зависеть?

на плюсах он даже от интерфейсов может не зависеть.

что касается классического ооп,
полиморфизм? не, не слышал
программирование в терминах интерфейсов? не, не слышал
Банда четырёх, паттерны ? не, не слышал.

зато плодим сущности без всякой необходимости.
которые что-то там про нас знают.

0

Сообщение от hoggy это что за бред?

Бред, это когда у Вас 10 независимых модулей, работающих с одним набором сущностей, и каждый из них должен знать про интерфейсы из всех остальных 9 модулей.
Или когда у Вас для одного набора сущностей есть 10 разных наборов классов и 20 конверторов туда-сюда.

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

0

Сообщение от Shamil1 Бред, это когда у Вас 10 независимых модулей, работающих с одним набором сущностей, и каждый из них должен знать про интерфейсы из всех остальных 9 модулей.

так это же вы предлагаете на каждый чих заводить абстракцию ради абстракции

Сообщение от Shamil1 Хотя, в прошлом веке, когда модульности уделялось мало внимания, шаблоны типа "актив рекод" были популярны.

казало бы, и при чем тут ActiveRecord?

0

Сообщение от hoggy так это же вы предлагаете на каждый чих заводить абстракцию ради абстракции

Не надо придумывать про меня то, чего не было.

0

Сообщение от Shamil1 Не надо придумывать про меня то, чего не было.

Ищу ментора(ов) по ООП (проектированию архитектуры и реализации)

0

Сообщение от hoggy Ищу ментора(ов) по ООП (проектированию архитектуры и реализации)

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

0

Сообщение от Shamil1 В данном сообщении я объясняю, что такое уровень абстракции. А так же на примере показываю, как может расти количество уровней абстракции. В этом сообщении я ничего не говорю о том, как надо делать, а как не надо.

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

0

Сообщение от Shamil1 А так же на примере показываю, как может расти количество уровней абстракции.

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

0