Так ли хорош DRY или все же он может нарушать O из SOLID

А на работу срочных посылок никто не жаловался

Очень интересно мнение сообщества по этому вопросу. Заранее благодарен за ваши комментарии.

. Если найдена ошибка в методе ArrivedToRecipient при работе с обычными посылками, то и исправлять надо именно работу обычных посылок. А на работу срочных посылок никто не жаловался и, вероятно, всех устраивает, как срочные посылки работают.

Кране против такого предложения.
Если один код скопировали в 10 различных мест, а при изменении требований изменили только в одном, то стоит ожидать в трекере 9 новых багов.

В описываемом вами случае можно ввести некий GenericParcel: IParcel, куда сложить всю логику, которая не зависит от типа посылок и затем уже наследовать Parcel и UrgentParcel от него

Если найдена ошибка в методе ArrivedToRecipient при работе с обычными посылками, то и исправлять надо именно работу обычных посылок. А на работу срочных посылок никто не жаловался и, вероятно, всех устраивает, как срочные посылки работают.

Не согласен. Это повод провести дополнительное тестирование и четко определить как именно должна работать данная логика для срочных посылок

Мне одному кажется, что public string Barcode {get; set;} — это верный признак DTO, в котором никакой логики не должно быть в принципе?

Однако, если не копировать код, а наследовать его, то изменения метода ArrivedToRecipient в классе Parcel сразу же приведут к изменению поведения класса UrgentParcel, что и будет являться нарушением Open-closed принципа.
Откуда у вас изменение метода ArrivedToRecipient? Если исправлена ошибка, то это не нарушение O по вашему же собственному определению. Если он изменился при добавлении какой-то другой функциональности (DangerousParcel), то нарушение О именно в DangerousParcel, а не тут. Если третья причина, то назовите ее;)

Целью принципа О как раз и является то, чтобы в базовом классе происходили только ценные изменения, которые вам по умолчанию нужны. Если "работает-не трогай" для вашей системы является более приоритетным, чем стоимость поддержки и модификации кода, то выпускайте базовый класс как отдельную версионируемую библиотеку и пусть UrgentParcel вечно живет с зависимостью от Parcel v.1.0 (это близко к смыслу, вложенному в open-closed principle автором термина Bertrand Meyer).

Кстати, с подходом расширения функциональности через наследование у вас скоро случится комбинаторный взрыв — UrgentParcel, DangerousParcel, UrgentDangerousParcel, InternationalUrgentParcel. В таких случаях лучше подходит компонентная модель (https://en.wikipedia.org/wiki/Component-based_software_engineering). Там и версионирование можно устроить, и комбинаторного взрыва избежать, да и качество абстракций получается более высоким.

Гораздо лучше создать новый класс UrgentParcel, и не нужно будет менять ни интерфейс, ни класс Parcel.

interface ParselInterface {

  public function getBarcode() : string;
  public function setBarcode(string $barcode);
}

class Parsel implements ParselInterface {

  public function getBarcode() : string {...};
  public function setBarcode(string $barcode) {...};
}

interface ParselInterface {

  public function getBarcode() : string;
  public function setBarcode(string $barcode);
}

class Parsel implements ParselInterface {

  public function getBarcode() : string {...};
  public function setBarcode(string $barcode) {...};
}

interface UrgentInterface {
  public function isUrgent() : bool;
}

class UrgentParsel extends Parsel implements UrgentInterface {
  public function isUrgent() : bool {return $this->isUrgent;}
}

interface ParselInterface {

  public function getBarcode() : string;
  public function setBarcode(string $barcode);
  public function arrivedToRecipient();
}

class Parsel implements ParselInterface {

  public function getBarcode() : string {...};
  public function setBarcode(string $barcode) {...};
  public function arrivedToRecipient() {...};
}

interface UrgentInterface {
  public function isUrgent() : bool;
}

class UrgentParsel extends Parsel implements UrgentInterface {
  public function isUrgent() : bool {return $this->isUrgent;}
}

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

На мой взгляд, больше похоже на пример применения SRP, если Parcel и UrgentParcel — это разные, с точки зрения бизнеса, сущности и будут меняться по разным причинам.

Тогда тот факт, что в них один и тот же код — случайность и скоро их код может стать совершенно разным.

Если же это UrgentParcel — просто особый вид Pracel, то почему бы не унаследовать его интерфейс от IParcel, применив в реализации делегирование интерфейса, например? Если переиспользование кода через наследование не устраивает по каким-то причинам

Очень интересно мнение сообщества по этому вопросу. Заранее благодарен за ваши комментарии.

    [Flags]
    public enum PostAttrFlags
    {
        Urgent,
        Prepaid,
        //...
    }

    public interface IParcelSimple
    {
        string Barcode { get; set; }
        PostAttrFlags Attributes { get; }
    }

    public class ParcelSimple : IParcelSimple
    {
        public string Barcode { get; set; }
        public PostAttrFlags Attributes { get; }
    }

public interface IParcelAttribute
    {
    }

    public struct ParcelAttrPrepaid : IParcelAttribute
    {
    }
    public struct ParcelAttrUrgent : IParcelAttribute
    {
    }
    
    public interface IParcel
    {
        string Barcode { get; set; }
        HashSet<IParcelAttribute> Attributes { get; }
    }

    public class Parcel : IParcel
    {
        public string Barcode { get; set; } = "";
        public HashSet<IParcelAttribute> Attributes { get; set; } = new HashSet<IParcelAttribute>();
    }

• Аттрибут может быть обычной пометкой. Для этого достаточно обозваться IParcelAttribute
• Часть бизнес логики реализуется с помощью возможностей строгой типизации и фундаментальных алгоритмов (HashSet гарантирует уникальность аттрибутов и быстрый доступ к конкретному аттрибуту письма, контроль типов гарантирует получение полных сведений о письме на всем протяжении отправки) и т.д.
• Выделение аттрибутов как отдельной сущности, позволяет проделывать с письмами интересные штуки. Например, «Сортировочный центр» может поставить отметку на письмо что оно прибыло на сортировку тогда-то и тогда-то, покинуло сортировку тогда-то и тогда-то и т.д.
• Теситровать такой код легче

namespace UnitPost
{
    [TestClass]
    public class UnitTest1
    {
        [TestMethod]
        public void TestIsParcel()
        {
            //-- Создадим срочную посылку
            Parcel p = new Parcel();
            p.Attributes.Add(new ParcelAttrUrgent());
            //-- Убедимся что это именно срочная посылка
            Assert.AreEqual(p.Attributes.Where(t => t.GetType() == typeof(ParcelAttrUrgent)).Any(), true);
        }

        
        [TestMethod]
        public void TestDblUrgentExcept()
        {
            //-- Создадим срочную посылку
            Parcel p = new Parcel();
            p.Attributes.Add(new ParcelAttrUrgent());
            //-- Дважды срочную посылку создать не получится
            Assert.AreEqual(p.Attributes.Add(new ParcelAttrUrgent()), false);
        }
    }
}

• Алгоритмы работы методов для класса легко «просматриваемые»
• Копипаст убирается отдельными реализациями различных закрытых методов внутри класса-стратегии
• Принцип SPR прекрасно реализован)