Проектируй классы снаружи-внутрь, начиная с точки зрения пользователя, а не деталей реализации. Думай о том, что объект логически представляет, а не о том, как ты его физически построишь. Хорошо спроектированный интерфейс должен использовать словарь пользователя и скрывать внутреннюю сложность.
Пользователей твоих классов интересует поведение и функциональность, а не реализация. Например:
push() и pop(), а не доступ к внутренним объектам LinkedListNodeПредставь LinkedList, построенный внутри из объектов Node с указателями next. Должны ли пользователи напрямую работать с объектами Node? Нет.
LinkedList концептуально — это последовательность элементов, а не цепочка узлов. Структура узла — просто деталь реализации. Вместо этого предоставь интерфейс итератора, который понятен пользователям:
for (LinkedListIterator p = list.begin(); p != list.end(); ++p) {
std::cout << *p << '\n';
}
Для этого нужны:
begin() и end()operator++() для обходаoperator*() для доступа к элементуoperator!=() для сравненияЧётко раздели, кто владеет какими данными:
get()/set())Такой подход делает твой класс:
Скрывай то, что пользователям знать не нужно. Раскрывай только то, что им необходимо для эффективной работы с твоим классом.
Подход outside-in в дизайне приоритизирует понимание пользователем концептуальной модели класса над внутренними структурами данных и механизмами реализации.
Новый — ещё не проверен сообществом
Вы