Specific Question About Proper Design

Now, I know this question is very opinion oriented because people generally design their apps differently... However, I want to know if I'm doing something incorrectly, or generally frowned upon in the objective c programming community, or if you have any suggestions as to how an experienced obj c developer might design this differently...

LOCATION is a struct and BULLET is an enum defined in a Constants.h header file, BulletV is a subclass of UIView, and Bullet is a subclass of NSObject

I have the following code:

#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

Now, I am relatively new to MVC.. but it seems like keeping the model and the view separate creates a whole lot of duplications, which i hate in my code..

For example, the fact that we have 2 of the same named Properties (Location and Type) utilized in these implementation blocks kind of bothers me, but I don't know how I would do this any other way while still maintaining separation between the model and view.

Also, both init methods for the view and model are very similar, with the exception that the model also includes a strength parameter..

I hav开发者_如何学Ce a very java-oriented mindset when programming, I like to have individual files for each object, and for each object to have a state and certain actions.. Now, this new design disallows for any actions to be utilized in these headers, because they need to be placed in a controller.

Any comments are welcome, if this is the way you would make a "bullet object" (more like just a rectangle) in your app, then feel free to comment so, but it just doesn't seem right to me. Feel free to give your insights.

I immediately see a couple of things I would change.

First naming conventions. Properties and instance variables usually start with a lowercase character while classes start with an upper case character. Class names should be descriptive so BulletV would be clearer as BulletView, "BulletV" might be a "BulletView", a "BulletVelocity", or who knows what else.

Secondly I would not allow a view to be responsible for it's own position. A view should be responsible for it's contents but not need to be aware of it's position in or anything else about its superview.

Instead I would consider what sort of object contains bullets with positions; a room, a level, or whatever. Let a view for that space position the views for whatever bullets it contains. An individual BulletView only need to decide how to draw itself based on the type of its bullet. Which, as Jano suggested, probably means you want to pass a bullet to the view's designated initializer.

Once you have that separation of responsibilities it hopefully makes sense for whatever object models the space containing bullets to manage their positions and possibly other behaviors like creating and destroying bullets.

If you were going to reuse OrangeView you would name it FruitView to start with, and pass a Fruit object superclass which would have a method fruit.color instead using a switch.

But I see what you are doing, color is a visual property, and MVC dogma demands that you keep each part isolated, so you smuggle Bullet in little pieces. This is not very object oriented, or any easier to understand or test. A benefit of OOP is thinking in objects, if you were to show your code to yourself, you would understand it better passing a Bullet object.

edit

All problems in computer science can be solved by another level of indirection except for the problem of too many layers of indirection. In a small app is very common for C to know M and V, and for V to know M. In java server side you create a bean just to feed the view, but that's uncalled for in such a small example. Even when you can spot the pattern before opening the class, it's more effort, more classes, more indirection. Not always a good fit for every application.

Apple talks about it in Cocoa Core Competencies and Cocoa Fundamentals Guide.

One can merge the MVC roles played by an object, making an object, for example, fulfill both the controller and view roles—in which case, it would be called a view controller. In the same way, you can also have model-controller objects. For some applications, combining roles like this is an acceptable design.