Интерфейсы в ООП

Сходил ТСу в профиль. Там написано:

Программист должен программировать

Странно всё это. =)

@libvf50txt ведёт личный дневничёк на лоре.

До упоминания Столярова осталось 3..2..1…

Закончат обсуждением лиспа как обычно.

В целом, мне кажется, что наследование — скорее неудобная фича. Наследование наследует интерфейс и реализацию (через protected-поля), что ломает инкапсуляцию (сокрытие реализации) и приводит ко всем сопутствующим проблемам (размытые границы, запутанный поток выполнения). Можно, конечно, не использовать protected, но тогда мне сложно представить какие удобства даст наследование. Без доступа к реализации как будто весь смысл наследования теряется.

Множественное наследование в 99% не нужно, а том самом 1% делается через interface + @Delegate за 1 минуту. 99% воплей про «Множественное наследование в java» идёт от людей не программирующих в java и не знающих её.

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

Ссылка на «множественное наследование» в беседе это неумелая и не очень чистоплотная попытка запугать собеседника «непонятным словом».

Ну так может быть этот человек писал на C++, где множественное наследование есть.

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

Вот, я уже дженерики в Го упоминал. Их можно было сделать с самого начала. Но потребовалось 10 лет (а если считать от alef’а, то и все 20), чтобы «теоретически можно» превратилось «готово, можно пользоваться».

Не, до можно пользоваться они так и не доехали.

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

Вы вообще поняли, что написали?

• В Go упростили модель ООП.
• Ты не понимаешь Go.
• Конкретнее.
• Лично я знаю одну фичу Go…

делается за 1 минуту, как я и написал, если уж без геморроя жизни нет.

import lombok.RequiredArgsConstructor;
import lombok.experimental.Delegate;

public class Test {

    public interface IClassA {
        int a1();
        void a2(int y);
        void common();
    }

    public interface IClassB {
        int b1();
        void b2(String y);
        void common();
    }

    @RequiredArgsConstructor
    public class ClassC implements IClassA, IClassB {

        @Delegate
        private final IClassA a;
        @Delegate
        private final IClassB b;

        @Override
        public void common() {
            //for example
            a.common();
            b.common();
        }
    }

    public void test(ClassC c) {
        c.a1();
        c.b2("test");
        c.common();
    }

    public void test() {
        
    }

}

Го довольно много перенял, но сделал по-своему, как никто раньше не делал. Например, в каком ещё языке существует неявная реализация интерфейса, проверяемая во время компиляции? Я не знаю такого языка.

Закончат обсуждением лиспа как обычно.

Вносите Лавсана. Только в чистое белое переоденьте.

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

Скала?

1. Выкинуть из дизайна языка множественное наследование.

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

3. Обвинять окружающих, что у них «без геморроя жизни нет».

Готов выслушать содержательную критику.

Можно проще:

1. Интерфейс это требования к изделию (контракт)
2. Класс это чертёж изделия (реализация)
3. Объект это готовое изделие (экземпляр)

Я категорически не приветствую Тикток, но Гуглу стоит взять с них пример и ограничить длину роликов, скажем, 30 или 40 минутами. А то это выходит уже за всякие рамки — что не ролик то полтора часа, Леха Фридман вообще по 6 часов интервью пилить стал.

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

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

1.5 часа это классическая университетская лекция. Вы призываете основной видео-хостинг ограничить возможность выкладывать образовательные лекции, по одой лишь той причине, что вам их «длинно смотреть».

Ну это звиздец.

Ты слишком серьезный. :)

Но да, после 6 часового интервью я в очередной раз убедился, что мир свернул не в ту сторону.

Но да, после 6 часового интервью я в очередной раз убедился, что мир свернул не в ту сторону.

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

Из того что осталось в памяти (там было много фигни по прямому назначению генериков, а так в го и без них писать можно)

func CheckTypeGood(a MyType) { switch a.type...}

funct CheckTypeBad[T MyType](a T) { switch a.type...}

Просто некоторые люди больше одного предложения написать не в состоянии.

Невозможно не согласиться. Ваше стартовое сообщение в этом треде отличное тому доказательство.

У концепции ООП есть создатель, его имя Alan Kay. Есть общепризнанные в мировом сообществе авторы, которые развили концепцию OOD: Sendi Metz, Grady Booch, Robert Martin, Martin Fowler.

В вашем списке имен не хватает Ole-Johan Dahl и Kristen Nygaard (Simula 67), Bertrand Meyer (Eiffel).

Но вообще прикольно получается – первый ОО язык программирования (Simula 67) появиля еще до того, как Алан Кей занялся SmallTalk-ом, но отцом-основателем ООП упорно продолжают называть именно Кея. Маркетинг такой маркетинг.

О, да, точно. CORBA, IDL. Как ты всё это помнишь? Я вот почти всё позабывал:)

первый ОО язык программирования (Simula 67) появиля еще до того, как Алан Кей занялся SmallTalk-ом, но отцом-основателем ООП упорно продолжают называть именно Кея.

Симула – язык программирования и моделирования, а не тотальная ОО-парадигма. Зрелая Симула включает в себя «обычный» алгоритмический АЛГОЛ-60, и не требует общаться с числами с плавающей точкой, как с отдельными объектами со своим поведением.

Это чудовищно.

Симула – язык программирования и моделирования, а не тотальная ОО-парадигма.

А я где-то утверждал, что Симула – это парадигма? o_O

Речь шла про то, что первый ООЯ (с наследованием и динамическим полиморфизмом) появился еще до того как Кей хоть что-то сделал в рамках своего SmallTalk-а. Посему приписывать все лавры Кею как-то странно.

и не требует общаться с числами с плавающей точкой, как с отдельными объектами со своим поведением

Т.е. кучу современных языков из категории ООЯ тупо вычеркиваем на основании этого критерия, я все правильно понимаю?

Да Вас тоже с новым годом ! ПС. Если что уже 14.01.

Alan Kay придумал не первый ООЯ, а всю ту ООП-хрень, которая есть в Smalltalkах, вроде посылки объекту false сообщения ifTrue:

В Симуле-67 есть обычный алгоритмический язык, и эта смолточная ООП-хрень не нужна для обычных вычислений.

Множественное наследование в 99% не нужно, а том самом 1% делается через interface

ООП в 99% не нужно, а в том самом 1% делается через лямбды и замыкания

(define (make-animal name)
  (let ((name name)
	(weight 0))
    (define (rename new-name)
      (set! name new-name))
    (define (greet)
      (format #t "hello, ~a~%" name))
    (define (weigh) weight)
    (define (feed food-weight)
      (set! weight (+ weight food-weight)))
    (lambda (msg)
      (cond
       ((eq? msg 'rename) rename)
       ((eq? msg 'greet) greet)
       ((eq? msg 'weigh) weigh)
       ((eq? msg 'feed) feed)
       (#t #f)))))

(define (make-owner name)
  (let ((owner-name name))
    (define (owner)
      owner-name)
    (define (own-by new-owner)
      (set! owner-name new-owner))
    (lambda (msg)
      (cond ((eq? msg 'owner) owner)
	    ((eq? msg 'own-by) own-by)
	    (#t #f)))))

(define (make-dog name kind class owner)
  (let ((animal (class name))
	(kind kind)
	(owner (owner "")))
    (define (greet)
      (format #t "hello, good boy, ~a~%" name))
    (define (describe)
      (format #t "This is a ~a named ~a he has ~a kg and his owner ~a can feed him better!~%"
	      kind name ((animal 'weigh)) ((owner 'owner))))
    (lambda (msg)
      (cond
       ((eq? msg 'greet) greet)
       ((eq? msg 'describe) describe)
       (#t (or (animal msg) (owner msg)))))))

;;;; дальше пример работы в repl
scheme@(guile-user)> (define hachiko (make-dog "Hachiko" "Akita" make-animal make-owner))
scheme@(guile-user)> ((hachiko 'own-by) "Ueno")
scheme@(guile-user)> ((hachiko 'feed) 3)
scheme@(guile-user)> ((hachiko 'greet))
hello, good boy, Hachiko
$35 = #t
scheme@(guile-user)> ((hachiko 'describe))
This is a Akita named Hachiko he has 3 kg and his owner Ueno can feed him better!
$36 = #t
scheme@(guile-user)> 

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

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

Не менее странно считать ООП именно то, что сделано в SmallTalk. А не в Eiffel, к примеру.

динамический полиморфизм на практике появились раньше, чем

Раньше, чем придумали ОО ЯП.

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

Вы хотите продемонстрировать свои способности художественной резьбы по цитатам? Ну тогда OK.

Только вот речь же шла не про только лишь динамический полиморфизм.

Когда появились метаклассы?

Когда появились метаклассы?

В классической ООП-шной триаде «инкапсуляция, наследование и полиморфизм» метаклассов нет.

Как их нет и в классических ООП-шных языках вроде Eiffel или Java.

Так что еще раз повторю то, что говорил выше: «Не менее странно считать ООП именно то, что сделано в SmallTalk. А не в Eiffel, к примеру.»

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

Типа давайте удалять людям мизинец, т.к большинство не использует. Или уши удалять т.к большинство ими шевелить не умеет.

Я унаследовал от бабушки квартиру. Теперь у меня есть квартира.

Теперь у тебя нет бабушки.

Наследование это круто.

Когда нестановится бабушки, это печально.

А вот личные горести в общественное пространство выводить — последнее дело. Мои чувства — моё дело. Это если вам вдруг ещё нужно что такое инкапсуляция объяснять.

Внесите anonimous.

их нет и в классических ООП-шных языках вроде Eiffel или Java.

https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html

их нет и в классических ООП-шных языках вроде Eiffel или Java.

https://docs.oracle.com/javase/8/docs/api/java/lang/Class.html

public final class Class<T>
extends Object

Метаклассы они такие, метаклассистые.

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

Точно.

Класс и Тип это синонимы, точно также как Интерфейс/Протокол/Правила - просто для разных ситуаций используется разное слово. Например в сетях свод правил для взаимодействия между хостами - протокол, а свод правил между уровнями системы - API т.е. интерфейс.

Можно сказать: это горный велосипед профессионального класса.

Можно сказать: это горный велосипед профессионального типа.

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

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

• Объект - это деталь.
• Класс - чертеж детали.
• Интерфейс - чертеж соединительного крепления или штекера (интерфейса) по которому идет подключение. Модель крепления, Прокладка, Тип разъема/кабеля для подключения.

Одна идея интерфейсов может быть объяснена с разных сторон. Может быть более прикладным образом через Переходники/Штекеры/Прокладки, а может быть более абстрактно через зависимость реализации от абстракции.

Более абстрактное представление описывает Robert Martin в своей статье DIP (Dependency Inversion Principle) где интерфейс представляет как абстракцию (абстрактный класс). Что накладывается на преставление штекера для розетки - который питает прибор от абстрактной сети, которая может быть ТЭЦ, ГЭС, Дизель, Аккумулятор, Солнечные Батареи.

Если в Java есть метаклассы, то искомое множественное наследование можно реализовать путём наследования и создания нового метаобъекта. Возьмётесь показать как это работает?

Ну ок. Как я вижу понимание - что такое интерфейсы, у вас нема.

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

Это претензия от сппшника? Чудны дела твои господи. Т.е. просто упоротый? Или всё проще и джавист жену увёл? :D :D :D :D