SOLID принципы

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


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

0

Сообщение от asmquest Эту хрень я тоже полистал только сейчас..

Ну почему хрень? Может там чего-то и есть мудрого - хз. НО: неясно что я должен делать? Просто так, читать "подряд", надеясь что осознаю концепции и.т.п.? Сам ненавижу эту тупую отговорку "нет времени", но ведь так - вот сейчас надо импорт дописать, уже давно должно быть готово. Почему я должен воспринимать ту или иную книгу как предмет тщательного изучения? Какие к этому основания или мотивы? Не вижу "цели". Разрабатывать свой язык - ну этим я точно заниматься не буду.

0

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

0

Сообщение от Igor3D Не слыхал ни о первой ни о второй. Для интереса открыл первую. Ну все как обычно. Длииинное оглавление и введение. Ладно. Сначала рассказывают что (оказывается) есть переменные, ф-ции, списки, объекты. Примеры в псевдокоде. Ну хорошо. Дальше почему-то начинают рассматривать вещи из multi-threading (concurrency, atomic). На этом мой энтузиазм иссяк. В общем, как всегда - полистал и закрыл. Нет, не то чтобы я "бравирую безграмотностью", но полагаю что подавляющее большинство точно так же пролистывает все эти книги "по диагонали". Возможно там и есть глубокие вещи которых я не знаю - но кому ж охота до них докапываться, а главное - зачем?

Насколько я понял, Вы Предисловие пропустили и сразу начали листать первую главу, которая называется "Введение в понятия программирования" (Introduction to Programming Concepts).

В этой главе авторы знакомят читателя с основными понятиями - функции, списки, потоки, объекты и т.д. (поэтому списки оказались рядом с потоками). Подробно эти понятия объясняются в последующих главах. В частности concurrency посвящено три главы (4, 5 и 8).

В этой книге нет примеров на псвдокоде. Все примеры там на языке Oz. Вы можете запустить их, например, в ideone.
Насчёт "зачем" (если Вам интересно) прочитайте Предисловие.

0

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

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

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

Сообщение от ht1515 Инъекция зависимостей и инверсия синонимы?

там же по вашей же ссылочке всё написанно:

инъекция - одна из реализаций инверсии))

0

Сообщение от hoggy расскажите это сишникам, который на чистой сишечке велосипедят ооп - только в путь.

Вы путаете Объектно-Ориентированное Программирование с Основанным-На-Объектах Программированием.
Для ООП нужно наследование. Нельзя имитировать наследование на чистой сишечке.

0

Сообщение от Shamil1 Вы путаете Объектно-Ориентированное Программирование с Основанным-На-Объектах Программированием.

ничего я не путаю.

оо-программирование,
это программирование с применением оо-парадигмы.
собственно, это - единственное требование.

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

а вообще, сама по себе оо-парадигма основана на процедурной парадигме.
без процедурщины ооп просто не может существовать.

это же такая банальщина и очевидность

0

Ооп это типо ии.

0

Ооп это типо ого-го!

0

Сообщение от hoggy на сишке ничего не мешает проэмулировать и наследование

Каким образом?

Сообщение от hoggy оо-программирование, это программирование с применением оо-парадигмы. собственно, это - единственное требование.

оо-парадигма подразумевает использование наследования

0

Сообщение от hoggy а вообще, сама по себе оо-парадигма основана на процедурной парадигме. без процедурщины ооп просто не может существовать.

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

0

На си пишет линус торвольдс например. И многие линуксоиды, они ваще сипипи не уважают. Гип глейд делает. А ядре линукса дофига гоуту.. вот так

0

Сообщение от Shamil1 Каким образом?

гляньте на дизайн gtk+, для примера.

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

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

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

без процедурной парадигмы существование ооп - невозможно.

и вот это:

ни что иное, как:

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

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

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

считайте, что ооп - наследник процедурщины.

Сообщение от Shamil1 оо-парадигма подразумевает использование наследования

нет, не предполагает.

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

взять какой нибудь к примеру std::string.
вполне себе полноценный самостоятельный механизм.
ну или там, std::vector какой нибудь.

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

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

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

Сообщение от Fulcrum_013 может быть и развитием ФП-парадигмы

нееет.

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

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

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

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

0

Сообщение от hoggy я хочу сказать, что фп, и процедурщина - вообще не совместимые парадигмы.

Ключем тут является то что ФП рассматривает функцию как объект первого класса. Без внесения такого довеска в процедурную парадигму реализация ООП (как минимум рантайм-полиморфизма) средствами процедурного программирования невозможна, потому как объект это структура содержащая список полей и методов их обработки.

0

Сообщение от Fulcrum_013 Без внесения такого довеска в процедурную парадигму реализация ООП (как минимум рантайм-полиморфизма) средствами процедурного программирования невозможна, потому как объект это структура содержащая список полей и методов их обработки.

бред какой то

0

Сообщение от Fulcrum_013 Ключем тут является то что ФП рассматривает функцию как объект первого класса.

ничего подобного. Ф-ция как объект первого класса есть в значительном количестве чистейших ООП-языков. Это никакого отношения к ФП не имеет.

0

Сообщение от hoggy бред какой то

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

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

Сообщение от asmquest Ф-ция как объект первого класса есть в значительном количестве чистейших ООП-языков.

А что значит чистейших? Как только в языке появляются указатели на функции так функцию сразу же можно рассматривать как объект первого класса, т.е. имеем некоторую домесь ФП.

0

Сообщение от hoggy вот здесь интересный момент: у них есть что-то общее. понятие функции, например.

Не надо путать функцию в виде процедуры и ф-цию в ФП-смысле. Это совершенно разные вещи.

Сообщение от hoggy если рассматривать фп в контексте с++, то это - язык метапрограмминга. полный по тьюрингу,

очень смешно сравнивать метапрограммирование и фапэ. В фапэ как раз полностью отсутствуют средства метапрограммирования, это одна из ключевых особенностей ФП.
Что касается шаблонов, то это можно конечно, назвать метапраграммированием, с натяжкой. Это макросистема, переписывание кода препроцессором. С++ де факто сам представляет из себя препроцессор си, хотя сейчас уже таковым не является.

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

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

Сообщение от Fulcrum_013 А что значит чистейших?

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

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

Сообщение от Fulcrum_013 Как только в языке появляются указатели на функции так функцию сразу же можно рассматривать как объект первого класса, т.е. имеем некоторую домесь ФП.

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

0

Сообщение от Fulcrum_013 Для реализации динамической диспетчеризации нужны указатели на функции. т.е функция должна быть объектом первого класса.

на сишке нет никаких "объектов первого класса".
и это не мешает ей манипулировать указателямии на функции.
что за бред?

вы вообще понимаете,
как устроен полиморфизм на низком уровне?

как устроенна технология COM ?

это всё - сишка чистой воды.

Сообщение от asmquest Не надо путать функцию в виде процедуры и ф-цию в ФП-смысле. Это совершенно разные вещи.

я вроде бы не давал повода так думать.

Сообщение от asmquest очень смешно сравнивать метапрограммирование и фапэ.

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

Сообщение от asmquest Это макросистема, переписывание кода препроцессором.

бред. полное незнание основ с++

Сообщение от asmquest интроспекции и рефлексии

в плюсы в грядущие стандарты завезут статическикую рефлексию.

хотя в принципе... не считая сериализации допустим,
что уже сейчас нельзя сделать,
используя существующую технологию метапрограмминга?

0

Сообщение от hoggy статическикую рефлексию

статическая рефлексия -- это оксюморон.

0

Сообщение от asmquest статическая рефлексия -- это оксюморон.

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

0