LINUX.ORG.RU

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

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

Но ведь потомок получает копию 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

misanthropy
() автор топика

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

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

RazrFalcon ★★★★★
()
Ответ на: комментарий от goingUp

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

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

misanthropy
() автор топика
Ответ на: комментарий от Deleted

Nick: misanthropy

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

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

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

DeVliegendeHollander ★★
()
Ответ на: комментарий от DeVliegendeHollander

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

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

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

misanthropy
() автор топика
Ответ на: комментарий от misanthropy

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

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

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

goingUp ★★★★★
()
Ответ на: комментарий от goingUp

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

***

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

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

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

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

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

misanthropy
() автор топика

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

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

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

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 2)

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

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

korvin_ ★★★★★
()

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

anonymous
()
Ответ на: комментарий от stevejobs

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

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

shty ★★★★★
()
Ответ на: комментарий от shty

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

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

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

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

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

stevejobs ★★★★☆
()
Последнее исправление: stevejobs (всего исправлений: 1)
Ответ на: комментарий от stevejobs

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

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

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

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

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

misanthropy
() автор топика
Ответ на: комментарий от stevejobs

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

anonymous
()
Ответ на: комментарий от stevejobs

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

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

shty ★★★★★
()
Ответ на: комментарий от stevejobs

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

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

winlook38 ★★
()

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

arkhnchul ★★★
()
Ответ на: комментарий от misanthropy

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

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

arkhnchul ★★★
()
Ответ на: комментарий от misanthropy

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

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

arkhnchul ★★★
()
Ответ на: комментарий от korvin_

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

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

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

Как-то так

yoghurt ★★★★★
()

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

anonymous
()
Ответ на: комментарий от yoghurt

Ну так, в 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
в смолтоке нет этой фичи?

anonymous
()
Ответ на: комментарий от anonymous

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

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

yoghurt ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.