Базовый CS с нуля
Абстракция: модуль, что держит и потом протекает
Читать про interface, encapsulation и протечки — не то же, что ощутить, как они держат, а потом ломаются в твоём коде. Построй один небольшой module, докажи, что его interface держит, пока ты меняешь внутренности, затем дожми его до протечки — и запиши ровно то, что проступило.
Преврати четыре идеи юнита в одну собираемую вещь: module, открывающий крошечный public interface, инкапсулирующий данные так, что ни один вызывающий до них не дотянется, позволяющий заменить скрытую implementation, не трогая вызывающих, а затем демонстрирующий протечку, которую ты можешь назвать и объяснить.
Построй Stack как самодостаточный module с фиксированным public interface (push, pop, peek, size), полностью инкапсулирующий данные, затем докажи abstraction, поменяв внутреннюю implementation без единой правки кода вызывающих — и закончи, намеренно заставив abstraction протечь и задокументировав протечку.
- Короткий README со списком public interface (четыре экспортированных имени) и явным указанием, какие имена приватны — и почему вызывающий до них не дотянется.
- Доказательство (скриншот, вставка вывода или падающая строка с её ошибкой), что вызывающий не может прочитать или перезаписать приватное хранилище снаружи module.
- Та же программа-вызывающий запускается без изменений на минимум двух разных внутренних implementation и даёт идентичный вывод — показано бок о бок.
- Абзац-разбор протечки: что ты сделал, чтобы её вызвать, какая деталь нижнего слоя проступила и почему это соответствует Закону протекающих абстракций (abstraction была полезна И протекла на пределе).
- Добавь инвариант, который module обеспечивает внутри (например, size никогда не уходит в минус; pop на пустом бросает понятную ошибку, а не портит состояние), и покажи, что вызывающий не может нарушить его снаружи.
- Добавь третью implementation с другим профилем производительности и однострочную заметку о том, как interface остался фиксированным, пока характеристики стоимости изменились — намёк, что даже сохранённый interface может протечь через скорость.
- Напиши крошечный файл тестов, проверяющих только public interface, затем покажи, что те же тесты проходят после каждой смены implementation — тесты против interface, а не против внутренностей.
- Задокументируй вторую протечку другого рода (медленная операция или предел максимального размера) и сопоставь её с первой: тот же закон, другой способ, которым проступил нижний слой.
Это цикл, ради которого построен юнит, в твоём коде: открой небольшой фиксированный interface, инкапсулируй данные так, чтобы граница была обеспечена, а не просто обещана, и докажи abstraction, поменяв скрытую implementation без правок вызывающих. Namespacing позволяет двум module делить короткое имя без столкновения. А завершающая протечка — честная часть: ты заставил реальную, полезную abstraction проступить нижним слоем на пределе, назвал протечку и увидел, почему Закон протекающих абстракций держит: abstraction стоило использовать И она протекла, одновременно.