SOLID принципы

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


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

0

Сообщение от Shamil1 Насколько я знаю, первая реализация плюсов ("Си с классами") была транслятором, перерабатывающим исходный код Си с классами в исходный код простого Си.

Правильно. Запускался этот транслятор как дополнительный препроцессор. Т.е. код ООП-языка не просто без проблем транслируется в код процедурного языка, а настолько органично что оказалось гораздо проще сделать транслятор плюсов в ООП-языка С с классами в процедурный С чем изобретать отдельный кодогенератор и т.д. Фактически void Class::Method();это не что иное как void Method(Class* this); а вызов obj.Method(); ни что иное как Method(&obj); Т.е. фактически макроподстановка в соответствии со словарем наборов. Но поскольку такие макроподстановки и сам словарь наборов штатному препроцессору С недоступны то и был реализован транслятор в виде дополнительного препроцессора. Собственно отличия дополнительный препроцессор/трансялтор это просто два разных названия одного и того же. К примеру штатный препроцессор С тоже фактически транслятор. а препроцессор - это фактически термин включающий в себя еще и этап на котором нужно запускать этот транслятор т.е. перед компилятором.

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

Сообщение от Shamil1 Для этого достаточно в перегрузке метода/свойства делать не то же самое по-другому, а что-нибудь совсем другое.

И ничего это не нарушит. Просто пудель будет гавкать не так как доберман. Да и то если метод виртуальный. Если невиртуальный то вызовется метод ссобаки. А принцип не нарушен поскольку метод гавкать есть у любой собаки в силу того что он есть у абстрактной собаки.
При этом как оно гавкает вышестоящий код вообще не заботит. Главное что как то гавкает. Для того и изобреталось ООП чтобы вышестоящий код подающий команду голос не заботило как оно там гавкает или вообще мяукает

0

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

Разница между "не гавкать" и "гавкать не так" - неоднозначная штука.
В примере с квадратом. Если мы ожидали, что задав ширину 5 и высоту 3 мы получим прямоугольник площадью 15, то Принцип Лисков нарушается. Если нам всё равно, что площадь будет 9 или 25, то Принцип Лисков не нарушается.

Сообщение от Fulcrum_013 Запускался этот транслятор как дополнительный препроцессор.

Язык - и есть транслятор. Иначе получится, что С++ и Бейсик - один и тот же язык... просто нужно запускать разные трансляторы.

Сообщение от Fulcrum_013 Т.е. фактически макроподстановка в соответствии со словарем наборов.

Какая макроподстановка для class A : B {} ?

0

Сообщение от Shamil1 Какая макроподстановка для class A : B {} ?

Никакая. Добавление пустого нода в древовидный словарь подстановок . вобщето все объявления внутри class это добавление записей в древовидный словарь макроподстановок а не само использование макроподстановки.

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

Сообщение от Shamil1 просто нужно запускать разные трансляторы.

Типа того. К примеру C++ Builder компилит дельфовские модули. Причем и то и то на кучу таргетов. Делается это просто. Сменный лексер/парсер. Один генерит дерево вычислений из плюсового кода другой из паскалевского. Оптимизатор оптимизит уже абстрактное дерево. Потом генерится промежуточный LLVM-код. А LLVM уже генерит машкод под любой из тех таргетов под который у него есть кодогенератор.
И по большому счету все языки это лишь разные способы задания абстрактного дерева вычислений. Результат работы парсера для всех языков одинаков.

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

Сообщение от Shamil1 Разница между "не гавкать" и "гавкать не так" - неоднозначная штука

Разница в том что как оно гавкает личное дело того кто гавкает и никого остального оно не колышет как конкретно этот пудель мяукает.

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

Сообщение от Shamil1 Если мы ожидали, что задав ширину 5 и высоту 3 мы получим прямоугольник площадью 15, то Принцип Лисков нарушается. Если нам всё равно, что площадь будет 9 или 25, то Принцип Лисков не нарушается.

Ну это от недопонимания ООП и вообще поолиморфизма. Оно предназначено для того чтобы что там ожидать прямоугольник или квадрат вышестоящий код вообще не задумывался. т.е. общая суть. Есть автомат который обрабатывет данные заданные алфавитом A. Но данные есть в алфавитах B,C,D,E,F. чтобы не парится в каком алфавите оно задано к каждому из наборов данных прикрепляем свой перекодировщик в алфавит A. При этом автомат который обрабатывает алфавит A как работает перекодировщик и какой именно из них вообще не заботит. Точно так же как и прекодировщиков не заботит что там с данными переведнными в алфaвит A делает обрабатывающий автомат.
Точно так же делается и в обратную сторону. т.е. если есть автомат у которого на выходе алфавит A а нужны данные в алфавитах B,C,D,E и т.д. в разных случаях.

0

Shamil1, я у Вас там не увидел присваивания. Не путайте присваивание со связыванием. И синтаксический сахар тоже не надо тащить. Делайте то, о чем утверждали. Покажите присваивание на аппликации и абстракции.

0

Сообщение от asmquest я у Вас там не увидел присваивания. Не путайте присваивание со связыванием.

Бессмысленно спорить о терминологии. Если Вы считаете это не присваиванием, то возвращаемся на шаг назад.
Объясните, почему в ООП обязательно нужно "присваивание"?

Сообщение от asmquest И синтаксический сахар тоже не надо тащить.

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

0

Сообщение от Shamil1 Бессмысленно спорить о терминологии.

тут нет никакой неоднозначности в терминологии

Сообщение от Shamil1 Объясните, почему в ООП обязательно нужно "присваивание"?

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

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

По-сути Вы произносите какие то невнятные мантры, но обосновать ничего из того что Вы говорите не можете, поэтому это все не интересно

0

насчет инверсии зависимостей...
https://ru.wikipedia.org/wiki/... 0%B8%D1%8F

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

0

Сообщение от asmquest Я говорил о полноценном ООП.

Что такое "полноценное ООП"? Если Вы имеете ввиду какой-то хитрый, только Вам известный термин, то больше вопросов нет.
Если Вы под "ООП" понимаете то же самое, что и большинство теоретиков информатики... Зачем нужно "присваивание" в "полноценном ООП"?

0

Shamil1, Для построения абстракций. Вы без него, тупо, счетчик не сможете реализовать. Не говоря о чем то там сложном.

0

Сообщение от asmquest Для построения абстракций. Вы без него, тупо, счетчик не сможете реализовать. Не говоря о чем то там сложном.

Вы утверждаете, что в Haskel даже счётчик нельзя организовать?

0

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

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

0

Сообщение от Fulcrum_013 Так что вооружившись бубном и матерью которая в святом писании точно неупомяналась создать счетчик можно и классическими ФП-средствами

вот такого плана счетчик: counter.increment; counter.decrement Вы не создадите на неизменяемых данных.

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

Сообщение от Shamil1 Вы утверждаете, что в Haskel даже счётчик нельзя организовать?

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

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

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

Нельзя там реализовать цикл вообще, потому что в ФП циклов просто нет. Там компилятор разворачивает рекурсию в циклы, но это относится к финтам компилятора, а не к семантике ФП

0

Сообщение от asmquest Нельзя там реализовать цикл вообще, потому что в ФП циклов просто нет.

Рекурсия там цикл эмулирует.

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

Сообщение от asmquest Нельзя там реализовать цикл вообще, потому что в ФП циклов просто нет.

Есть условный переход значит можно и цикл организовать.

0

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

Где это он есть? В ФП что-ли?

0

Сообщение от asmquest Где это он есть? В ФП что-ли?

В любом тюринг-полном языке. Соответсвенно и в ФП.

0

Сообщение от Fulcrum_013 В любом тюринг-полном языке. Соответсвенно и в ФП.

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

0

Сообщение от asmquest Нет этого в ФП. К тому же, без присваиваний цикл бессмысленен, будете просто гонять одно и то же по кругу

Я бы Вам посоветовал почитать какую-нибудь книгу по программированию. Чтобы приобрести базовые знания.

Например, что Вы написали про метод "void TurnOn(Lamp lamp)":

Сообщение от asmquest Да, и возвращаясь к аналогии с функцией. Аналогия эта не верна. Функция рассчитывает на прием абстрактного, а не конкретного объекта, например, функция работающая с типом Integer, может работать с любым числом -- 1, 2, 3, n. Она специализирована только по типу принимаемого аргумента, но не по значению его. В вашем же примере с лампочкой получается так, что, дескать, наша функция изначально работает только и исключительно с одним числом, а мы расширяем это до типа Integer. То есть, до того, что и так должно быть

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

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

0

Сообщение от Shamil1 то лучше начать с SICP.

Если бы Вы читали SICP, и что-то поняли из нее, хотя бы первые 3 главы, Вы бы не несли эту ахинею. Так что перенаправляю этот совет Вам

0

Кстати о чтении книг

Сообщение от Shamil1 Я бы предложил CTM, так как в ней написано в том числе и про модели вычисления. Но, если эта книга покажется Вам слишком сложной, то лучше начать с SICP. Обе книги можно скачать бесплатно и на английском, и на русском языке.

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

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

0

Igor3D,
Эту хрень я тоже полистал только сейчас, и схожие ощущения. Но SICP, таки, достаточно полезная книжка, она считается классикой и преподается в цитадели CS и ИИ. В целом, книжка неидеальна, в частности, там достаточно мало дается материала по ООП, одна глава, и там достаточно примитивные вещи. Но в целом, книга дает общее представление о программировании. Самое главное, то что там дается начальное представление о реализации языков, и озвучена абсолютно верная мысль, что настоящая разработка немыслима без реализации языка, оперирующего терминами предметной области, и позволяющего выражать мысли в категориях этой области.
Также к преимуществам можно отнести и то, что там оперируют терминологией в канонической, академической манере, а не в фанбойс-стайл, как сейчас принято. Там под ФП подразумевается, например, только и исключительно подстановочная модель, а под декларативным программированием -- логическое. Никакой особой путаницы не происходит, в стиле "а што такое мое фапэ, которое рулез, и там есть цыкылы и монады в категориях пердофункторов"

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

Кроме того, ее авторы, в особенности Сассман -- это признанные авторитеты в области ИИ. Этот человек работал с Карлом Хьюиттом, Терри Виноградом, и прочими монстрами ИИ, сам разрабатывал языки и технологии, то есть не теоретическое ололо, а реаллайф инженер.

Рекомендую.

0