Именование классов, обеспечивающих полную реализацию интерфейса, но которые предназначены для расширения / использования в качестве миксинов

Question

Если вы пишете интерфейс с большим количеством методов, скажем IPerson, и ожидаете много разных его реализаций, то довольно распространенной практикой является предоставление абстрактного класса AbstractPerson, который реализует основную часть функциональности.

Обычно AbstractPerson является абстрактным, поскольку вы обычно оставляете некоторые ключевые функции не реализованными.В этом случае наименование имеет смысл.

Но что такое хорошее соглашение об именовании, если вы уже реализовали весь IPerson, но все еще ожидаете подклассы?Возможно PersonMixin, PersonHelper, GenericPerson или просто Person?Я думаю, что Person немного расплывчато, поскольку он не совсем ясно показывает предполагаемое использование.

Answer 1

Хотя это из Framework Design Guidelines (для .NET), я думаю, что это в равной степени относится к любому языку.Рекомендую:

Избегайте именования базового класса с помощью суффикса Base, если этот класс предназначен для использования в общедоступных API. Если библиотека предоставляет базовый класс в качестве возвращаемого типа или типа параметра, он не должен иметь базовый суффикс.

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

Я бы просто назвал класс Person и позволил бы любым производным классам использовать более конкретные имена.Я думаю, что Person очень ясен и указывает на то, что он используется в качестве общего (неспецифического) человека.

Answer 2

Я думаю Person просто отлично. Все дело в том, что вы можете специализировать его на конкретных типах людей, но это все же человек.

Answer 3

Если это можно использовать как есть, я бы придерживался Person. Если нет, я бы сделал его абстрактным (даже если он не имеет абстрактных членов) и назвал бы его PersonBase.