پیش‌تر از این در اصل دوم SOLID که همان اصل Open-Closed است، بیان کردم که نامگذاری اصول SOLID برای یک برنامه نویس تازه کار خیلی گنگ و نامفهوم است، اصل سوم که Liskov Substitution نام دارد عجیب‌ترین آن‌هاست. انگار این اسم از یک کتاب درسی شیمی آلی آمده است. حتی ممکن است شما را از انتخاب توسعه نرم افزار به عنوان شغل پشیمان کند زیرا فکر می کردید که همه‌ی کار یک توسعه دهنده نرم افزار عملی است و تئوری وجود ندارد.
اما زود از کوره در نروید! به من اعتماد کنید، درک این اصل بر خلاف آن که نامش ترسناک است، بسیار آسان است. در واقع، ممکن است ساده‌ترین اصل از این پنج مورد برای درک باشد (خوب، شاید اشتباه می‌کنیم… اگر ساده‌ترین نیست، حداقل کوتاه‌ترین و ساده‌ترین توضیح را خواهد داشت).
این قانون به سادگی می‌گوید که کدی که با کلاس‌های والد (یا Interfaceها) کار می‌کند، وقتی آن کلاس‌های والد با کلاس‌های فرزند (یا کلاس‌های پیاده‌کننده Interface) جایگزین می‌شوند، نباید از کارکردن بیوفتند و متوقف شود و خطا بدهد. مثالی که درست قبل از این در اصل دوم SOLID بررسی کردیم یک مثال عالی است: اگر نوع عمومی IPDFGenerator را در آرگومان متد با نمونه خاص MilkyWayPDFGenerator جایگزین کنم، آیا انتظار دارید کد متوقف شود یا به کار خود ادامه دهد؟
مسلما به کار خود ادامه می‌دهد! به این دلیل که تفاوت فقط در نام است و هم رابط و هم کلاس تبعیت کننده از آن، متدهای یکسانی دارند که به یک روش کار می‌کنند، بنابراین کد ما مانند قبل کار خواهد کرد.
بنابراین، موضوع مهم در مورد این اصل چیست؟ خوب، به عبارت ساده‌تر، تمام این اصل این است که می‌گوید: مطمئن شوید که کلاس‌های فرعی شما همه‌ی متدها را دقیقاً همانطور که لازم است، با همان تعداد و نوع آرگومان‌ها، و همان نوع بازگشتی، پیاده‌سازی می‌کنند. اگر حتی یک پارامتر متفاوت باشد، ما ناخودآگاه به ساخت کدهای بیشتری بر روی آن ادامه می‌دهیم، و روزی به نوعی آشفتگی متعفن خواهیم داشت که تنها راه حل، حذف خواهد بود.
در مورد جایگزینی Liskov چیزهای بیشتری می توان گفت (اگر واقعاً احساس شجاعت می کنید، به نظریه آن نگاه کنید و در مورد Covariant Types مطالعه کنید)، اما به نظر من، این مقدار برای توسعه دهنده معمولی و کسی که برای اولین بار با این اصل روبرو می‌شود، کافی است.