Атрибуты инкапсуляции в объектах и ​​интерфейсах управления

Question

Я рассматриваю возможность привязки определенных «не очень часто доступных» атрибутов и функциональных возможностей к их собственным «конфигурационным» и «расширенным» объектам в структуре данных, чтобы я мог предлагать пользователю определенные callback - это объект типа, который предоставляет доступ к наиболее часто используемым функциям и атрибутам и предлагает метод getExtended, который возвращает тот же объект другому типу, который предлагает необычно используемые функции.

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

Я падаю сюда в очевидную ловушку против шаблона или это действительно хороший способ выложить структуру простой в использовании библиотеки?

Answer 1

Один из способов сделать это - использовать интерфейсы. Интерфейсы могут быть расширены через наследование точно так же, как классы. Ваша коллекция может ссылаться на базовый интерфейс, скажем ISimple, как показано ниже. Ваш getExtended() может вернуть интерфейс IAdvanced. Оба могут быть реализованы одним и тем же объектом (если они разделяют личность и цель) или разными объектами. Решение о том, следует ли реализовать вместе или нет, должно действительно основываться на Single Responsibility Principle. Вот пример кода:

interface ISimple { 
    IAdvanced getAdvanced(); 
    int getLength(); 
    String getName(); 
} 

interface IAdvanced extends ISimple { 
    void verifyAllTheThings(); 
} 

class Implementation implements IAdvanced { 

    public IAdvanced getAdvanced() { return this; } 

    // ISimple 
    public int getLength() { return 2; } 
    public String getName() { return "something"; } 

    // IAdvanced 
    public void verifyAllTheThings() { /* do stuff */ } 
} 

Я думаю, вы действительно спрашиваете, является ли это плохой шаблон или нет. Само по себе это не плохой шаблон (IMHO), но есть разные проблемы с дизайном, вытекающие из вашего вопроса. Если ваша мотивация быть дружелюбной к IDE - это потому, что на каждом объекте существует огромное количество методов, то это, возможно, сомнительный дизайн. Опять же, Single Responsibility Principle является хорошим руководством, чтобы рассказать вам, если ваш объект делает слишком много, и его следует разделить на отдельные проблемы. Если это так, то выполнение простого/расширенного расщепления - возможно слабый способ разделить набор всех методов, и вместо этого вы можете захотеть разбить объект по более концептуальным линиям.

Answer 2

Duane уже дошел до точки, но, к сожалению, пропустил отметку с использованием интерфейса. Интерфейс может быть унаследован , но не всегда нужен. И да, using interface to limit the method accessibility - это правильный способ сделать это.

В качестве примера, на самом деле вы можете:

interface ITwoDimensional { 
    int getWidth(); 
    int getLength(); 
} 

interface IThreeDimensional extends ITwoDimensional { 
    int getHeight(); 
} 

interface ISpherical{ 
    int getRadius(); 
} 

class Consumer{ 
    int calculateArea(ITwoDimensional a){ 
     // you can only access getLength() and getWidth(); 
    } 
    int calculateArea(ISpherical a){ 
     // you can only access getRadius(); 
    } 
    int calculateArea(IThreeDimensional a){ 
     // you can access getLength(), getWidth() and getHeight(); 
    } 
} 

Это только простой пример. Существует гораздо больше возможностей для доступа к интерфейсу.