SOLID принципы

всего 5 принципов:
1) srp - класс должен описывать только те характеристики, которые на объект из предметной области возложены. То есть либо кот, либо пес, котопес быть не может.
2) ocp - Писать надо классы так, чтобы их можно было легко расширить, но не изменять
3) Лисков - ???
4) делайте много маленьких интерфейсов, один дольшой интерфейс это плохо. Так как рефакторинг усложняется...
5) Инверсия зависимостей. Типо композицию поменяйте на агрегацию


Я не понимаю принцип Лисков. Можете объяснить популярно?

0

Сообщение от asmquest можно

А кто и когда проверит тот факт что запихиваемое в этот массив имеет подходящий интерфейс включения и выключения?

0

Сообщение от Fulcrum_013 А кто и когда проверит тот факт что запихиваемое в этот массив имеет подходящий интерфейс включения и выключения?

если нужна проверка, она реализуется вручную. Но только в рантайме

0

Сообщение от asmquest если нужна проверка, она реализуется вручную.

Она нужна всегда иначе ничего работать не будет. Запихиваем мы один раз и в компайл тайме можем проверить имеет ли оно необходимый интерфейс или нет. Зачем пилить все это на каждый пук в ручную и опять же проверять на каждый пук в рантайме, если все эти проверки может сделать компилятор в компайл тайме, а без подобной проверки код будет неработоспособным? С какой стороны у скриптовой версии профит в эффективности выполнения и разработки? Насколько вижу одни лузы.

0

Сообщение от Fulcrum_013 Зачем пилить все это на каждый пук в ручную и опять же проверять на каждый пук в рантайме, если все эти проверки может сделать компилятор в компайл тайме, а без подобной проверки код будет неработоспособным?

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

На практике, эти проверки, как правило, вообще не нужны.

0

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

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

0

Сообщение от Fulcrum_013 Эта проверка позволяет проверить наличие интерфейса на этапе компиляции и гарантировать

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

Ключевым моментом является то, что язык с проверкой типов -- это слабый язык. На этом все.

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

Сообщение от Fulcrum_013 наличие интерфейса на этапе компиляции

а то я без сраного тайпчекера не знаю, какой я интерфейс пилю, он умней меня, ага.

0

Сообщение от asmquest Это уже вообще не ООП, потому что в ООП не программист, а именно программы манипулируют программами, в этом вся сила. А иначе это очередной сраный алгол под личиной ООП.

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

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

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

0

Fulcrum_013, короче, я не собираюсь тут проповедовать что-либо, равно как и разубеждать адептов

Хотите понимать ООП, смотрите в первоисточники, а мантры обсуждать нет смысла.

0

Сообщение от asmquest а то я без сраного компилятора не знаю, какой я инерфейс пилю, он умней меня, ага.

Он всего лишь проверяет что в данную переменную присваивается объект имеющий заданный этой переменной интерфейс. Что позволяет не разгребать что там именно за реализация интерфейса.

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

Сообщение от Fulcrum_013 При этом не нужно рассматривать объект как пассивное хранилище данных

Видел одного товарисча который начитался книг именитых маразматиков проповедующих бред подообный вашему. Эти именитые маразматики докатились до аксиомы что тру-объект это пассивное хранилище данных и в тру-ООП объект должен обрабатываться исключительно извне. Вот вы тоже потихоньку катитесь именно к такому маразму.
Отрезвление наступило после подсчета количества сравнений "что там за тип" при обработке которое нужно сделать для обработки последовательности. N^2 у этих маразматиков против 0 в реальном ООП с проверкой типов при компиляции.

0

Сообщение от Fulcrum_013 Что позволяет не разгребать

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

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

Сообщение от Fulcrum_013 что тру-объект это пассивное хранилище данных

это как раз от типодрочеров чаще всего исходит

0

Сообщение от asmquest Ошибки типов, на этом фоне -- вообще ничто.

Ничто они когда отлавливаются в компайл тайме. А если в рантайме то мало того что это может оказаться головняком на недели отладки так и вылезти не понятно когда и иметь повторяемость сравнимую с фазами луны.

Сообщение от asmquest да никто ничего не разгребает

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

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

Сообщение от asmquest это как раз от типодрочеров чаще всего исходит

Та нет. Это как раз от динамиков. Потому как если объект автономный то для управления им нужен как раз строго определенный интерфейс. А вот с динамической кашей вместо интерфейса именно к тому и идет что дирижер не знает как дерижировать пока не разгребет по данным чем и как там можно дережировать. В пределе приходим к пассивным хранилищам как в процедурщине и функциональщине от которых и ушло ООП в сторону активных сущностей.

0

Сообщение от Fulcrum_013 то мало того что это может оказаться головняком на недели отладки

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

0

Сообщение от asmquest такие ошибки на практике возникают крайне редко,

Ну не надо рассказывать сказки. Сталкивался с тем что то что в плюсах компилятор отлавливает в JavaScript или PHP попробуй найди где в этот чертов массив строка вместо инта сунулась, и какого лешего она вообще строкой а не интом оказалась.

Сообщение от asmquest Гораздо трудней отловить ошибки не связанные с типами, с плюсовой лапше, где из-за убогости языка, код растет экспонцеально, и быстро превращается в помойку, которую никто не в силах разгрести

Существуют два типа языков - которые никто не ругает и на которых никто не пишет. А лапша она у криворуких везде лапша какой язык не дай. В плюсах кстати при правильной разработке код очень часто в объеме не увеличивается а уменьшается за счет выделения более высокоуровневых абстракций при доделке нового функционала.
Мало того ООП язык в сборщике мусора не просто не нуждается, а сборщик мусора ООП языкам категорически противопоказан. Потому как сам по себе мусора генерировать не должен как к примеру С++, а по какому принципу организовывать уборку явно распределяемых программистом объектов виднее программисту исходя из сути задачи/назначения объектов. А встроенный мусоросборник и отсутствие деструкторов в скриптовых языках делают задачу создания иерархий автономных объектов вообще нереальной. К примеру объект не может самостоятельно удалится.

0

Сообщение от Fulcrum_013 К примеру объект не может самостоятельно удалится.

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

0

Сообщение от asmquest в таких языках удаляется ссылка на объект

Откуда объект о ссылке на него знает? А для того чтобы знал и остальным не надо было знать что он знает нужна не просто ссылка а двунаправленный смартпоинтер который мусоросборнику головняка и тормозов ой как добавит. А если мусоросборника нету все один раз строк в 200 разруливается. В результате реально слабые ссылки и реально слабовладеющие контейнеры (при любом откуда бы оно не было сделано удалении объекта все ссылки на него тут же обнуляются и из всех контрейннеров/списков обработки вычищаются). Мусоросборник скриптовых языков в таких делах не помощь а только помеха. Потому как рассчитаны эти скриптовые языки в исходе были на форматирование ввода вывода между клиентом и сервером БД, при котором контекст выполнения живет только время генерации страницы. а соответсвенно и подвисшие ссылки в них лечили фактически утечкой памяти которая недолгая в виду недолгой жизни самого контекста памяти. Потом дальше начали такую концепцию развивать работая по принципу "объект не нужен когда на него нет ссылок", которая пригодна разве что для вебхеллоувердов. А для автономных иерархий объектов актуальна концепция "объект не нужен когда логика его модели не допускает его дальнейшее существование в независимости от количества активных ссылок". при таком подходе ссылки на объект должены быть незамедлительно удалены из всех списко вобработки в которых он числится а все просто ссылки обнулены. И самое удобное место где хранить список ссылающихся при этом - сам объект, а самое удобное место в котором производить подобную чистку - деструктор. При этом если учесть возможность того что ссылающийся может удалиться раньше объекта, то в языках с мусоросборником вообще начинаются жутики по по поводу обеспечения установления/разрыва связи на оповещение об удалении.

Добавлено через 1 час 16 минут

Сообщение от asmquest Ключевым моментом является то, что язык с проверкой типов -- это слабый язык.

Во всех современных языках со статической типизацией есть библиотечные средства для работы с динамической типизацией. Их даже используют изредка. Например для работы с БД и т.п. а так же всяким криворуким бредом типа JSON и XML. Но не более. Потому как в 99% случаев динамическая типизация дает исключительно гемморой а не профит, а соответственно ее использование оправдано там и только там где структура данных неизвестна на момент компиляции. А такие случаи по большому счету исчерпывается вышеперечисленными задачами.
Посему язык с динамической типизацией по определению предназначен не более чем для хеллоувердов, а для решения серьезных комплексных задач средств просто напросто не имеет.

0

Сообщение от asmquest http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented

Документ по ссылке не является серьёзным источником.
Кто-то пересказывает своими словами, что Алан Клей когда-то сказал про ООП неизвестно в каком контексте. Эти слова относятся к тому, как было реализовано ООП в Смолтолке. Где гарантия, что Алан Клей считает, что эта реализация самая правильная?
Более того, по ссылке вообще нет описания ООП. Только несколько принципов без разъяснений, что они означают. Да те были сформулированы очень давно. Алан Клей с тех пор мог поменять своё мнение.

Если у Вас не секта адептов тру ооп, то должны быть учебники/книги/статьи и так далее. Поэтому вопрос остаётся:

Где можно почитать про настоящее ООП?

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

Сообщение от asmquest Хотите понимать ООП, смотрите в первоисточники, а мантры обсуждать нет смысла.

Вы до сих пор не привели ни одной ссылки на первоисточник.

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

Сообщение от asmquest На практике, эти проверки, как правило, вообще не нужны.

Чтобы некорректно написанная программа могла положить всю систему?

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

Сообщение от asmquest то уже вообще не ООП, потому что в ООП не программист, а именно программы манипулируют программами, в этом вся сила.

Об этом не было ни слова даже в тех тезисах, на которые Вы дали ссылку.

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

Сообщение от asmquest Ключевым моментом является то, что язык с проверкой типов -- это слабый язык. На этом все.

На самом деле в научном мире сейчас наблюдается прямо противоположная тенденция. Предпочтение отдаётся языкам со статической типизацией. В языки с динамической типизацией добавляют команды "включить проверку типов". Учёные изобретают новые типы данных, позволяющие всё больше ошибок отлавливать на этапе компиляции.

Несколько примеров (из TPL):

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

Компилятор ML Kit с помощью мощного алгоритма вывода регионов (region inference) заменяет большинство вызовов сборщика мусора (а иногда даже все вызовы) операциями управления памятью в стеке.

Есть даже типы (dependent types), позволяющие выход за границы массива проверять во время компиляции.

0

Сообщение от Shamil1 На самом деле в научном мире сейчас наблюдается

деградация. Это касается не только программирования.

0

Сообщение от Fulcrum_013 а так же всяким криворуким бредом типа JSON и XML

Ну про XML согласен, но какие некриворукие альтернативы JSON существуют?

0

Сообщение от asmquest Ключевым моментом является то, что язык с проверкой типов -- это слабый язык. На этом все.

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

и вопрос:
а нахрена она вообще нужна?
остается открытым.

0

Сообщение от hoggy динамика реализуется через статику.

продолжайте чудить, не хватает веселья сегодня.

0