@ht1515

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


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

0

@Fulcrum_013

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

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

0

@Shamil1

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

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

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

0

@Fulcrum_013

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

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

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

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

0

@asmquest

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

0

@Shamil1

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

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

0

@asmquest

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

0

@ht1515

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

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

0

@Shamil1

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

0

@asmquest

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

0

@Shamil1

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

0

@Fulcrum_013

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

0

@asmquest

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

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

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

0

@Fulcrum_013

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

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

0

@asmquest

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

0

@Fulcrum_013

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

0

@asmquest

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

0

@Shamil1

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

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

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

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

0

@asmquest

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

0

@Igor3D

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

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

0

@asmquest

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

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

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

Рекомендую.

0