дискуссия о ООП на примере java

Инкапсуляция — публичные и приватные члены класса

Классу-потомку доступны защищенные члены класса-предка. Всем остальным доступен только публичный интерфейс класса.

Но ведь потомок получает копию protected полей суперкласса.

public class Main {
    public static void main(String...args) {
        B b = new B();
        b.test();
        A a = new A();
        a.check();
    }
}

public class A {
    protected int test = 5;
    private static int staticTest = 10;

    public void check() {
        System.out.println(test);
    }
}

public class B extends A {
    public void test() {
        System.out.println(test);
        test = 7;
        System.out.println(test);
    }
}

выведет 5, 7, 5

Т.е. с инкапсуляцией всё в порядке.

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

Зачем некрофильствовать тут?

PS: 350 комментов на швабре... ТС знатно вбросил

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

Наверно, имеется в виду, что когда есть только 1 уровень наследования, то всё проще?

на фоне твоей предыдущей темы слишком хохотно читать эту.

Nick: misanthropy

Дата регистрации: 25.09.2016 21:12:17

Просто человеку очень хочется в толксы, а скор не растёт.

Лучше б новости писал — быстрее бы отросло :-)

Да, просто было интересно, имеет ли смысл, т.е. есть ли польза от такой траты времени.

Скор мне не интересен, а новости у вас - в лучшем случае копипаста с опеннета.

P.S. По теме у тебя есть что сказать?)

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

Эти классы перестанут соответствовать интерфейсу, но останутся вполне рабочими.

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

Теоретически (мне кажется), наследование публичного интерфейса надёжнее, чем приватного.

***

2) Реально изменить поведение предка можно только с помощью перекрытия виртуальных методов;

3) Принцип подстановки Лисков обязывает класс-потомок удовлетворять всем требованиям к классу-предку;

4) Для выполнения пункта 2 в точном соответствии с пунктом 3 классу-потомку необходима полная информация о времени вызова и реализации перекрытого виртуального метода;

5)Информация из пункта 4 зависит от реализации класса-предка, включая приватные члены и их код.

Что автор имел в виду под "...еобходима полная информация о времени вызова..."?

Автор изобрёл Go. Но зачем?

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

Тут надо и не переборщить (если всё сделать приватным и sealed/final, то ФИГАЧИТЬ не получится), если же совсем распоясатсья - получится динамическая лапша типа JS, так что тут нужно разбираться в сортах говнокода и понимать, говнокод какого вкуса тебе в данный момент приятней жрать

Классу-потомку доступны защищенные члены класса-предка. Всем остальным доступен только публичный интерфейс класса.

ЕМНИП, в SmallTalk нет protected, все поля — private, все методы — public, да поправит меня yoghurt

Runtime polymorphism?

Увидел слово «функционал» — закрыл вкладку. Не хочу обсуждать

Автор имел в виду этот паттерн?

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

это мир java, сынок ))

Еще очень важно, что т.к. никто не имеет в голове четкой архитектуры, её наличие заменяется runtime reflection. Например, ты не можешь понять, какие у класса должны быть поля, но ты можешь пойти и рефлекшеном собрать все классы из пакета, сложить в коллекцию и считать эту коллекцию «набором полей».

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

Главное не докатиться то JS. Нет ничего более беспомощного, безответственного и испорченного, чем JS зомби, пишущие JS лапшу. «Я знал, что рано или поздно мы перейдем и на эту дрянь.»

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

Хорошее ООП это хорошо, но код пишешь НЕ ТЫ. В основном, ты склеиваешь на синюю изоленту миллиарды классов, написанные натруженными индусскими ногами, добавляешь к этой горе жалкую горсточку из нескольких сотен/тысяч своих классов, и всё. Ты уже жрешь говно, и тебе надо уметь выживать в этом

Хорошее ООП это хорошо, но код пишешь НЕ ТЫ.

Разве это относится к ООП? Парадигма программирования здесь не причём.

Главное не докатиться то JS.

отдельные личности утверждают, что наследование на основе прототипов (объектов, а не классов), позволит решить проблемы, описанные в сабже.

https://medium.com/javascript-scene/common-misconceptions-about-inheritance-in-javascript-d5d9bab29b0a#.m1acq36qq

Эко тебя в Аксморе поколечили

Ты уже жрешь говно, и тебе надо уметь выживать в этом

как я и говорил: это мир java, сынок ))

т.к. никто не имеет в голове четкой архитектуры, её наличие заменяется runtime reflection. Например, ты не можешь понять, какие у класса должны быть поля, но ты можешь пойти и рефлекшеном собрать все классы из пакета, сложить в коллекцию и считать эту коллекцию «набором полей».
Поэтому очень важно, чтобы рефлекшеном можно было вмешаться в любой говнокодерский механизм и пофиксить так, чтобы начало работать. Если же сделать истинно приватные фиксированные структуры или запретить рефлекшен, сразу случится коллапс, говнокод перестанет работать и починить его станет никак. Дальше идут всякие джава агенты, аннотейшен-процессоры, автогенераторы и макросы

Я нихрена не понял, но хочется спросить, а ревью у вас делается? Если делается, как ревьюер реагирует на тот бред, что ты описал?

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

В каких случаях удобнее обычное наследование?

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

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

Ведь можно использовать композицию классов «млекопетающее» и «пёс», к примеру.

сабж же «на примере java», не?

и, собственно, как проблему «изменения базового класса ломают потомков» решит композиция?

Все так

Вот «публичных» методов только нет.

Есть сообщения, которые можно отправлять любому объекту, и как объект на него отреагирует, зависит только от него. Сообщения могут быть любыми.

Метод в смолтоке - лишь установленная в объекте реакция на конкретное сообщение, но отсутствие того или иного метода не запрещает слать объекту другие сообщения.

Как-то так

там какое то говно написано. Автор думает что обсуждает ООП, а что такое ООП он не знает. Да и Java к ООП отношения, собственно говоря, не имеет, это квазиооп

Ну так, в Io получается, что любые поля можно сделать любыми — хоть public, хоть приват, хоть какими угодно кастомными, потому что там есть доступ к объекту вызова и отсылателю сообщения

Foo := Object clone do(
   bar := method(
     if(call sender self isKindOf(Foo), "ok" println, "you are not subclass of Foo" println)
  )
)

SubFoo := Foo clone do(
   baz := method(bar)
)

Another := Object clone do(
   baz := method(Foo bar)
)


foo := SubFoo clone
another := Another clone

foo baz // ok
another baz // you are not subclass of Foo

Почему квазиооп?

http://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented

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

Есть такая фишка, конечно