Статья про принципы ООП (холивар?)

[Alex11223]

Сообщение от Pavia

Если объекты изолированы друг от друга т.е они не взаимодействуют то они будут потоко-безопасными.

Изолировано что от чего? Если ничего ни с чем не взаимодействует, то что же программа делает?

Вот это же вроде не нарушает упомянутый закон Деметра, но не потокобезопасно:

public class Account {
  private decimal balance = 500.00m;

  public decimal GetBalance() {
    return balance;
  }

  public void Withdraw(decimal amount) {
    if (balance < amount)
      ...;
    balance -= amount;
  }
}

...
class Foo {
  var acc = new Account();
  
  void DoStuff() {
    RunThread(acc);
    RunThread(acc);
  }

  void RunThread(Account acc) {
    var thread = new Thread({
      while (true) {
        acc.Withdraw(1);
      }
    });
    thread.run();
  }
}

[Pavia]

Сообщение от Alex11223

Изолировано что от чего? Если ничего ни с чем не взаимодействует, то что же программа делает?

Вот по этому я и дал более точную формулировку.

Сообщение от Alex11223

Вот это же вроде не нарушает упомянутый закон Деметра, но не потокобезопасно:

Зато это уже не ООП стиль, а функциональный.

[Alex11223]

Что тут функционального?

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

[rrrFer]

Сообщение от Pavia

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

Изоляция лежит около абстракции.
Например, все тот же malloc/free - реализуют прекрасную абстракцию. За счет того, что хорошо инкапсулирует (читай - изолирует).
С терминами все окей, вроде бы. Классическая литература трактурет так же, не вижу ни одной нестыковки.

[oldsnowman]

Во всех ооп языках есть некоторые отклонения от эталонного ооп.

[rrrFer]

Сообщение от oldsnowman

Во всех ооп языках есть некоторые отклонения от эталонного ооп.

Именно, поэтому первый совет по дальнейшему изучения из этого "учебника":

посмотрите как описанные механизмы реализуются в вашем любимом языке и попробуйте реализовать небольшой проект.

[Pavia]

Сообщение от rrrFer

Изоляция лежит около абстракции.
Например, все тот же malloc/free - реализуют прекрасную абстракцию. За счет того, что хорошо инкапсулирует (читай - изолирует).
С терминами все окей, вроде бы. Классическая литература трактурет так же, не вижу ни одной нестыковки.

В данном случае речь скорее не об абстракции, а о сокрытии информации.
Мы скрываем детали реализации.

[rrrFer]

Сообщение от Pavia

В данном случае речь скорее не об абстракции, а о сокрытии информации.

1) Доклад от Яндекса "Память - идеальная абстракция": https://www.youtube.com/watch?v=i87W3KyZgPw

Идеальная потому, что очень хорошо скрывает детали реализации.

2) Доклад про иерархию кэшей: https://vk.com/@for_programmer-annot...ef=group_block - автор (10 лет работает в IBM) говорит "любая абстракция протекает". Тут абстракцией является процессор, а протекает, потому что бенчмарками удается установить (раскрыть) детали реализации - размеры кешей, в частности.

3) о том, что абстракции текут (а не должны, т.к. их суть в сокрытии деталей реализации, т.е. инкапсуляции) говорит Джоэл Спольски - у него есть "Закон дырявых абстракций"

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

[mirudom]

Сообщение от rrrFer

ИМХО, немного холиварная статья про "принципы ООП". С одной стороны, все это ООП - это очень просто, т.к. "добавили class, public, protected, virtual и ... все?".

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

А еще есть шаблоны проектирования, что с ними делать - пытаться понять или зазубрить? Преподаватель, отвечает на такие вопросы не всегда. Зато на эти вопросы пытается ответить статья, можно поспотрить и пообсуждать эту тему...

Ссылка.

Следует отделять обсуждение инструментов от контекста их использования. Инструменты достаточно выучить в той или иной степени.
Контекст использования - тут намного сложнее. Особенно забавно когда узнаешь об очень успешном проекте,
в котором в определенной точке его развития надо все, все переписывать.