Но факт остаётся фактом: сторона представлявшая объектно-ориентированное программирование, во время открытой дискуссии с противниками под смех зала, даже запуталась в своих же концепциях. Люди вспоминают, что у всех создалось стойкое впечатление, что аргументация Lisp'еров была куда убедительней и последовательней, чем сторонников ООП

В восьмидесятых годах метод повторного использования каким-то неясным мне образом связали с объектно-ориентированным программированием, и сколь угодно многочисленные имеющиеся доказательства обратного, по-видимому, уже не избавят этот метод от этого клейма. Хотя иногда объектно-ориентированный код действительно годится для повторного использования, таким его делает вовсе не объектно-ориентированность, а программирование в стиле "снизу вверх". Возьмём, например, библиотеки: их можно подгружать и повторно использовать сколько угодно, потому что, по сути, они представляют собой отдельный язык. И при этом, совсем неважно, написаны ли они в объектно-ориентированном стиле или нет."

Я уверен, что ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, лишь тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой. Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы приходите к тому, что вы в состоянии сформулировать четкие и непротиворечивые интерфейсы

Именно из-за этой неразберихи в ООП так популярен рефакторинг — из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле

ООП ради самой ООП уже давно превратилось в замкнутый круг. Конечно, можно попытаться считать C# в .NET 3.5 с более чем 50,000 реализованных классов "венцом эволюции". Добавить в следующей версии .NET ещё миллион классов – что может быть более правильным и более вожделенным, с точки зрения ООП-программиста? Так вы говорите, это и есть то самое бегство от сложности?

Томас Поток из Oak Ridge National Laboratory даже провел масштабное прикладное исследование (9), которое продемонстрировало, что нет никакой заметной разницы в производительности между программистами, работающими в ООП и в обычном процедурном стиле программирования.

rem Параметры воспринимаются вместе с кавычками (то есть они тоже передаются как часть параметра)
IF NOT EXIST myfolder (
 call :MyFunction "param1" param2
 rem после вызова MyFunction, управление вернётся обратно на эту строчку
)
rem bla-bla

goto :EOF
rem :EOF определена по умолчанию для goto


:MyFunction
rem смотрите описание call, там сказано, что кавычки можно убирать так: %~1
IF EXIST %1 bla-bla
IF EXIST %2 bla-bla
rem всё, уходим вконец файла и автоматически возвращаемся в то место, откуда вызвали
goto :EOF

: MyFunction2
goto :EOF

половина всех концепций ООП являются скорее плохими, чем хорошими, в связи с чем он искренне сочувствует ООП-программистам, тогда как вторая половина от оставшихся концепций — и вовсе не имеет никакого отношения к ООП,

Но реально никто не начинает с аксиом, все начинают с доказательств....
Именно из-за этой неразберихи в ООП так популярен рефакторинг — из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле"

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

class BoundedInt<Range>
{
  public BoundedInt(int value)
  {
    if (value < Range.MinValue)
       value = Range.MinValue;
    else if (value > Range.MaxValue)
       value = Range.MaxValue;
    this.value = value;
  }
  public int value; 

  static BoundedInt<Range> operator + (BoundedInt<Range> v1, BoundedInt<Range> v2)
  {
     return new BoundedInt<Range>(v1.value + v2.value);
  }
}

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

using System;
using System.Linq;
using Nemerle.Collections;
using Nemerle.Text;
using Nemerle.Utility;
using Nemerle.Extensions;

namespace Tests
{
  using NorthWind;
  /// <summary>Description of Customer.</summary>
  [Record, StructuralEquality, StructuralHashCode]
  class Customer
  {
    [Accessor] _customerID : int;
    [Accessor] _name       : string;
    [Accessor] _country    : string;
    [Accessor] _city       : string;
    
    public override ToString() : string
    {
      $"Customer(CustomerID=$CustomerID; Name=$Name)"
    }

    public Orders : IQueryable[Order]
    {
      get { _orders.Where(o => o.CustomerID == CustomerID).AsQueryable() }
    }
  }
}

DeviceExt : Device
{
    Beep { Device.Send ("make bebeep") }
}

TurnGreenOn (id) { Send (id, "turn green on") }
...
Beep (id) { Send (id, "make bebeep") }

IDeviceExt : IDevice
{
    Beep
}

struct IMyDevice
{
    virtual void Foo() = 0;
};

struct IMyDeviceExt : public IMyDevice
{
    virtual void Bar() = 0;
};

class CMyDevice : public IMyDevice
{
public:
    virtual void Foo()
    {
    }
};

class CMyDeviceExt : public CMyDevice, public IMyDeviceExt
{
public:
    virtual void Bar()
    {
    }
};

void mymain()
{
    CMyDevice md;
    md.Foo();

    CMyDeviceExt mde;
    mde.Foo();
    mde.Bar();
}

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

Есть два интересных взаимодействия между эффектами гравитационного потенциала и эффектами скорости в показаниях часов. Сначала, на уровне моря все часы на Земле идут с одной и той же скоростью. Это связано с тем, что вращение Земли вызывает ее раздувание на экваторе, так как гравитационный потенциал там выше. (Часы на экваторе дальше от центра Земли.) Эффект в показаниях часов от этого большого потенциала в экваторе и эффект в показаниях часов от скорости вращения точно компенсируют друг друга. Так что показания часов на экваторе равно показанию часов на полюсах.

Второе взаимодействие гравитационного потенциала и скорости в показаниях часов происходит из-за эксцентричности орбит GPS. В перигее, более низкий гравитационный потенциал приводит к тому, что часы GPS идут медленнее, чем номинально. Также в перигее, спутники перемещаются быстрее чем в среднем и это также заставляет часы GPS работать медленнее — точно с той же суммой. Так что кажется, что энергия – вот что заставляет часы идти с другим темпом. Возрастающая гравитационная потенциальная энергия заставляет часы работать быстрее. Возрастающая кинетическая энергия (скорость) заставляет часы работать медленнее.

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

...
Это верно, что часы, которые облетают Солнце за год по радиусу земного полдня должны иметь тот же ход, что часы, которые облетают Солнце за год по радиусу земной полночи, то есть потенциальное гравитационное различие должно компенсироваться скоростным различием. Но объяснение Гофмана не может быть принято. Это противоречит поведению часов GPS. Различие в солнечном гравитационном потенциале для GPS синхронизируемых в точке, ближайшей к Солнцу и дальней от Солнца ( различие в расстоянии приблизительно в четыре раза превосходит земного диаметр) кажется, не оказывает никакого влияния на часы GPS.

S_S>>Вобщем, Гофман согласен, Хатч не согласен.

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

Свободная подпрограмма, в терминологии C++, — это функция, не являющаяся элементом класса. Свободные подпрограммы не могут переопределяться подобно обычным методам, в них нет такой общности.

// тут наследуем, т.к. PreDo()/PostDo() требуют особого доступа к базе по условию,
class PreAndPostDecorator : ThirdPartyClass

ThirdPartyClass - ЭТО ЖОСТКАЯ ЗАВИСИМОСТЬ КОТОРАЯ ПРЕПЯТСТВУЕТ ТЕСТИРОВАНИЮ


{
  public void PreDo() {}
  public void PostDo() {}
}

// структурная композиция
class PreAndPostDoerDecorator : IDoer
{
  private PreAndPostDecorator _decorator = new PreAndPostDecorator();

ВОТ ЭТО ЖОСТКАЯ ЗАВИСИМОСТЬ КОТОРАЯ ПРЕПЯТСТВУЕТ ТЕСТИРОВАНИЮ

 
  PreAndPostDoerDecorator(IDoer doer){  _doer = doer;} 

  void Do() {
    _decorator.PreDo();
    _doer.Do();
    _decorator.PostDo();
  }
}

interface IDoer
{
  void Do(); 
}

// тут наследуем, т.к. PreDo()/PostDo() требуют особого доступа к базе по условию,
class PreAndPostDecorator : ThirdPartyClass
{
  public virtual void PreDo() {}  // СМОТРИМ ВНИМАТЕЛЬНО - virtual
  public virtual void PostDo() {} // СМОТРИМ ВНИМАТЕЛЬНО - virtual
}

class PreAndPostDoerDecorator : IDoer
{
  private PreAndPostDecorator _decorator;

  public PreAndPostDoerDecorator(PreAndPostDecorator d)
  {
    decorator = d;
  }

  public PreAndPostDoerDecorator(PreAndPostDecorator d)
  {
    decorator = = new PreAndPostDecorator();
  }
 
  PreAndPostDoerDecorator(IDoer doer){  _doer = doer;} 

  public void Do() {
    _decorator.PreDo();
    _doer.Do();
    _decorator.PostDo();
  }
}

interface IDoer
{
  void Do(); 
}

I>>>Кто такое сказал ? Какие проблемы возникают ? Какие есть более толковые решения ? Или же вопрос чисто идеологический ?

OCaml — современный объектно-ориентированный язык

I>// тут наследуем, т.к. PreDo()/PostDo() требуют особого доступа к базе по условию,
I>class PreAndPostDecorator : ThirdPartyClass
I>ThirdPartyClass - ЭТО ЖОСТКАЯ ЗАВИСИМОСТЬ КОТОРАЯ ПРЕПЯТСТВУЕТ ТЕСТИРОВАНИЮ

1. Использование собственных интерфейсов/абстрактных классов, суть фасадов/адаптеров третьесторонних классов, вместо использования их напрямую. Одна реализация интерфейсов будет "реальная", остальные — заглушечные в целях тестирования.
2. Использование дотнетной техники CBO. Не обязательно ручками, можно брать готовые mock-фреймворки.
3. Создание целых заглушечных сборок, содержащих одноименные используемые классы в тех же неймспейсах, что замещаемые сборки. С заглушечной же реализацией лишь минимального мн-ва используемых членов. Линковка тестовой сборки с ней. Я иногда прямо тестовые исходники в проект тестовых сборок включаю, особенно если самих тестовых сборок много и много тестовых уникальных "заглушечных" сценариев. Тоже потянет.

Тебе надо было протестировать твой код, а не ThirdParty.

class ThirdParty {
  protected abstact int TemplateMethod();
  protected void EntryPoint() {}
}

interface IThirdPartyCallback {
  int TemplateMethod();
}

interface IThirdPartyAPI {
  void EntryPoint();
}

class ThirdPartyAdapter : ThirdParty, IThirdPartyAPI {
  IThirdPartyCallback _callback;

  public ThirdPartyAccess(IThirdPartyCallback callback) { _callback = callback; }
  new public void EntryPoint() { base.EntryPoint(); }
  protected override int TemplateMethod() { return _callback.TemplateMethod(); }
}

public delegate IThirdPartyAPI ThirdPartyFactory(IThirdPartyCallback callback);

class InternalParty : IThirdPartyCallback {
  IThirdPartyAPI _api;

  public InternalParty(ThirdPartyFactory factory) { _api = factory(this); }
  public void UsefulMethod() { _api.EntryPoint(); } 
  private int IThirdPartyCallback.TemplateMethod() { return 42; }
}

Я скипнул порожний текст.

    _decorator.PreDo();
    _doer.Do();
    _decorator.PostDo();

I>>>Поскольку свою точку зрения ты отказываешься пояснить, смысла продолжать нету

I>Не способен приводить примеры — просто не отвечай, не переживай, не ты первый

yield return
...
CurrentState().Method()

I find OOP technically unsound. (Alex Stepanov)

http://www.stlport.org/resources/StepanovUSA.html

Мсье Пуаро хочет знать, какого цвета была пара сапог, которые у Ральфа были в гостинице, – коричневого или черного? От этого многое зависит.
...
Откровенно признаюсь, что вопрос о цвете был поставлен лишь для того, чтобы скрыть цель моих расспросов.
Вы знаете, какие результаты дали наведенные ею справки. Выяснилось, что у Ральфа Пейтена действительно были с собой сапоги.

а где сам автор-то?
или это публикация ради публикации?

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

template <class T1, class T2>
bool operator==(my_pair<T1, T2>& l, my_pair<T1, T2>& r)
{
    return l.first == r.first && l.second == r.second;
}

>>Пустой аргумент, ни в пользу ООП ни против. Какая разница что с чем связали?
Разница в том, что многие под достоинствами ООП понимают другие вещи. Например, я считаю достоинством ООП — удобное создание Абстрактных Типов Данных (АТД). Но нельзя не согласиться с Грэмом, что это фишка есть и вне ООП. А раз так, то относить ее к достоинствам ООП уже некорректно.

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

Но объяснение Гофмана не может быть принято. Это противоречит поведению часов GPS.

Но объяснение Гофмана не может быть принято. Это противоречит поведению часов GPS. Различие в солнечном гравитационном потенциале для GPS синхронизируемых в точке, ближайшей к Солнцу и дальней от Солнца ( различие в расстоянии приблизительно в четыре раза превосходит земного диаметр) кажется, не оказывает никакого влияния на часы GPS.

S_S>Вобщем, Гофман согласен, Хатч не согласен.