Конкретный вопрос о правильном дизайне

Question

Теперь я знаю, что этот вопрос очень ориентирован на мнение, потому что люди обычно проектируют свои приложения по-разному ... Однако, я хочу знать, делаю ли я что-то неправильно, или вообще не одобряю это в сообществе программистов на c, или если у вас есть какие-либо предложения относительно того, как опытный разработчик obj c может по-другому это оформить ...

LOCATION - это структура, а BULLET - это перечисление, определенное в заголовочном файле Constants.h, BulletV - это подкласс UIView, а Bullet - это подкласс NSObject

У меня есть следующий код:

#import "Bullet.h"

@implementation Bullet

@synthesize Type;
@synthesize Location;
@synthesize Strength;

- (id)initWithLocation:(LOCATION)location Type:(BULLET)type Strength:(int)strength
{

    self = [super init];

    if (self)
    {
        self.Location = location;
        self.Type = type;
        self.Strength = strength;
    }

    return self;
}

@end

@implementation BulletV

@synthesize Type;

- (id)initWithLocation:(LOCATION)location Type:(BULLET)type
{
    self = [super initWithFrame:CGRectMake(location.x - 10.0, location.y - 2.0, 20.0, 40.0)];

    if (self)
    {
        self.center = CGPointMake(location.x, location.y);
        self.Type = type;
    }

    return self;
}

- (void)drawRect:(CGRect)rect
{
    switch (self.Type)
    {
        case Normal:
            self.backgroundColor = [UIColor redColor];
            break;
        default:
            break;
    }
}

@end

Теперь я относительно новичок в MVC ... но похоже, что разделение модели и представления создает много дубликатов, которые я ненавижу в своем коде ..

Например, тот факт, что у нас есть 2 с одинаковыми именами Свойства (Расположение и Тип), используемые в этих блоках реализации, меня беспокоит, но я не знаю, как бы я сделал это любым другим способом, сохраняя при этом разделение между моделью и видом.

Кроме того, оба метода init для вида и модели очень похожи, за исключением того, что модель также включает параметр прочности.

У меня очень Java-ориентированное мышление при программировании, мне нравится иметь отдельные файлы для каждого объекта и для каждого объекта иметь состояние и определенные действия. Теперь этот новый дизайн запрещает любые действия, которые будут использоваться в эти заголовки, потому что они должны быть размещены в контроллере.

Любые комментарии приветствуются, если именно так вы бы сделали «объект маркера» (больше похожий на прямоугольник) в своем приложении, тогда не стесняйтесь комментировать, но мне это не кажется правильным. Не стесняйтесь высказать свое мнение.

Answer 1

Я сразу вижу пару вещей, которые я бы изменил.

Первые соглашения об именах.Свойства и переменные экземпляра обычно начинаются с символа нижнего регистра, а классы начинаются с символа верхнего регистра.Имена классов должны быть описательными, поэтому BulletV будет более понятным, так как BulletView, «BulletV» может быть «BulletView», «BulletVelocity» или кто знает, что еще.

Во-вторых, я бы не позволил представлению быть ответственнымдля своей собственной позиции.Представление должно отвечать за его содержимое, но не должно знать о его положении или о чем-либо еще о своем суперпредставлении.

Вместо этого я бы рассмотрел, какой тип объекта содержит маркеры с позициями;комната, уровень или что-то еще.Позвольте представлению для этого пространства расположить представления для любых пуль, которые оно содержит.Отдельный BulletView нужно только решить, как нарисовать себя, основываясь на типе его маркера.Что, как предположил Яно, вероятно, означает, что вы хотите передать маркер инициализатору представления.

После того, как у вас будет такое разделение обязанностей, мы надеемся, что любой объект модели будет иметь смысл для пространства, содержащего маркеры, управлять своими позициями ивозможно другое поведение, такое как создание и уничтожение пуль.

Answer 2

Если бы вы собирались повторно использовать OrangeView, вы бы назвали его FruitView для начала и передали бы суперкласс объекта Fruit, у которого вместо этого был бы метод fruit.color с использованием переключателя.

Но я вижу, что вы делаете, цвет является визуальным свойством, а догма MVC требует, чтобы вы держали каждую часть изолированной, поэтому вы должны переправлять Bullet на маленькие части.Это не очень объектно-ориентированный, или легче понять или проверить.Преимущество ООП заключается в мыслить объектами: если бы вы показывали свой код себе, вы бы лучше поняли его, передав объект Bullet.

edit

Все проблемы в информатике могут быть решены с помощью другого уровня косвенности, за исключением проблемы слишком большого числа уровней косвенности .В небольшом приложении очень часто C знает M и V, а V - M. На стороне java-сервера вы создаете bean-компонент только для представления представления, но в таком маленьком примере это не рекомендуется.Даже когда вы можете определить шаблон перед открытием класса, это больше усилий, больше классов, больше косвенности.Не всегда подходит для каждого приложения.

Apple говорит об этом в Основы какао и Основы какао .

Можно объединить роли MVC, которые выполняет объект, заставив объект, например, выполнять роли контроллера и представления - в этом случае он будет называться контроллером представления.Таким же образом вы можете также иметь объекты модель-контроллер.Для некоторых приложений комбинирование таких ролей является приемлемым дизайном.