Interface and MVC issue....

[mojito]

I have had a simple single purpose project develop into a dual purpose project. Luckily I had used good MVC I hope to help keep things organised.

But here is a specific question
package src.photo
{
import com.adobe.webapis.flickr.FlickrService;
import com.adobe.webapis.flickr.PagedPhotoList;
import flash.display.Sprite;
import flash.events.*;

public interface IPhotoModel extends IEventDispatcher
{
//specific to PHOTOMODEL
function setPage(val:uint):void;
function getFs():FlickrService;
function getPhotoList():PagedPhotoList;
function getThumbs():Array;
function getImageView(id:String):void;
function setRemainder(): void;
function getRemainder(): uint

//all types of model to have the following....
function hideOthers(keep:Sprite):void;
function setFlashVars(vars:String):void;
function registerView(v:Sprite):void;
function getAViews():Array;
function enterFullScreen():void;
function leaveFullScreen():void;
}
}

I want my interface to just have the bottom half declarations so that at run time I can type in the type of model as now I have two models.

I think I am right in wanting 2 models, as there is strict separated business logic for each of the component parts. And I had already done a single model as it was orginally a project for a single component purpose.

What I want to have is an AbstractView class that can at runtime get populated with a type of model. At runtime we will know which type of model it is but not until then. And this is what I thought interfaces were for. So I can provide a type to the model at runtime. So its a kind of model, but we don't know which until runtime. This would mean I can have a single abstract view class, instead currently i have one in each package pretty much identical except for the typing described above. If I can get the typing then I can shift the abstract view class to the higher folder level and use it from the folders beneath.

folder structure

src/photos/
src/map/
src/

currently here are the two component parts working independently. But I would like to abstract some common view stuff out into the src/ folder like AbstractView for example.

So back to the interface why cant I delete the lines that are specific to certain types of model; well compiler issues as if the lines aren't there then the methods aren't available public wise. But interfaces force the methods to be available in all classes using them, in my map model I dont want to have to have an empty signature for photo type methods for example.

there is a lot here sorry folks, but I thought this is a very good question.

:cool:

[Flash Gordon]

i've read your question for several weeks now and have no idea what you're trying to say....

[mojito]

Well I want the interface to create a general datatype so at runtime it can be decided the type of model it is.
But the compiler forces me to include the following


//specific to PHOTOMODEL
function setPage(val:uint):void;
function getFs():FlickrService;
function getPhotoList():PagedPhotoList;
function getThumbs():Array;
function getImageView(id:String):void;
function setRemainder(): void;
function getRemainder(): uint


I don't want to have these in the interface because then I have to implement the signatures in the model but they are specific to just one type of model I have.

[Flash Gordon]

sorry, don't know what you are trying to say. "interfaces don't create" anything.

best.

[mojito]

Got loads of respect for you FG just so as you know, you been round here helping me on many a time and others too...

but I need get clear on this and so back to your question "interfaces don't create" anything?

Don't they create datatypes ? Why do you use interfaces ? I have seen many instances when meaningless interfaces have been used. Why - I dont know the original developers werent around to explain to me. For myself I learn from books and want to learn more so I post this question...

At least Interfaces force signatures (methods) to exist in a class instance, but they do more as well. It's the polymorphic nature I want to get at here. I'm struggling because I want the compiler to allow me to define a datatype rather than a class as a class may be too rigid - but I need to type it. Isn't this where interfaces come into play. It's an area I admit to having some grey areas but that doesnt mean I don't feel that often they are badly used.

I have 2 models now since expanding my application. But I would like them to share some functionality, perhaps I could use an abstraction for this. But I feel the models are too different for an abstraction, and I just want a few methods to be sure to be implemented. So I thought great I will use an interface. But the compiler is forcing me to declare much more in each model that I want.

[Flash Gordon]

It's semantics...and I'm was having a hard time understand what you are saying. Interfaces themsevles create nothing....I suppose only things that say "new" can create or anything that "wraps" a new and returns it. So interfaces allow for polymorhpicism but they don't creally create anything....it's not a point worth aurging...i'm just confused as to what you were saying/trying to say.

I'd say give a VERY VERY stripped down version of your problem and let's go over it together.

[mojito]

Ok an application grows out of two separate applications a photo gallery and a map. Each was built as separate MVC.

I used an interface for the model of the gallery which I created first. I did this so that I was sure that I had all the methods I needed. I didn't really need the datatype at this stage. So I could type the model at this stage model or Imodel.

Problems came later when I created the map MVC and I thought well first should I have 2 models ! Yes - they are both performing backbone operations independent of each other. As I could have started to stick methods for the map into the gallery model. I would have separate views sure so it still may have been kind of valid, but the model would have been very unwieldy.
So I stuck with 2 separate models.

Here is where it gets interesting, a third model, like an abstraction which I placed common elements to both models. So each model extends this common functionality.

public class PhotoModel extends Model implements IPhotoModel


the issue I have is that I have to identical abstract view classes because I have a different type of model (as this project has 2 models)

public function AbstractView(m:MapModel,b:Sprite,c:MapController=n ull)

I can make this a single class if I can make the type an interface.And I should be able to do this.
At run time AbstractView doesn't know what kind of model it gets, this is where an interface comes in (so i thought) it doesn't have to know what kind in fact, it just needs and be secure in the knowledge that the class has the contract of methods so it wont fail.

My initial problem was that the compiler is allowing the above but only if I list all methods not just common ones I need in the interface.

package src.photo
{
import com.adobe.webapis.flickr.FlickrService;
import com.adobe.webapis.flickr.PagedPhotoList;
import flash.display.Sprite;
import flash.events.*;

public interface IPhotoModel extends IEventDispatcher
{
//specific to PHOTOMODEL - if i have these here (and the compiler is requiring me to - then I need to implement them in the GALLERY MODEL and they arent needed there)
function setPage(val:uint):void;
function getFs():FlickrService;
function getPhotoList():PagedPhotoList;
function getThumbs():Array;
function getImageView(id:String):void;
function setRemainder(): void;
function getRemainder(): uint
//all types of MODEL to have the following....
function hideOthers(keep:Sprite):void;
function setFlashVars(vars:String):void;
function registerView(v:Sprite):void;
function getAViews():Array;
function enterFullScreen():void;
function leaveFullScreen():void;
}
}

I want the interface to have only the following

//all types of MODEL to have the following....
function hideOthers(keep:Sprite):void;
function setFlashVars(vars:String):void;
function registerView(v:Sprite):void;
function getAViews():Array;
function enterFullScreen():void;
function leaveFullScreen():void;

but from my original post " why cant I delete the lines that are specific to certain types of model; well compiler issues as if the lines aren't there then the methods aren't available publicly"

THERE IS A LOT TO GET ONES HEAD ROUND HERE I KNOW. Currently the solution rests with having two identical abstract views apart from the following line

public function AbstractView(m:IPhotoModel,b:Sprite,c:PhotoControl ler=null)
public function AbstractView(m:GalleryModel,b:Sprite,c:PhotoContro ller=null)

what I want is one class with

public function AbstractView(m:IModel,b:Sprite,c:PhotoController=n ull)

[ASWC]

I would create a globalModel interface with all common functionality and extend it with two child interface which I then implement respectively for my map and gallery. Then all I need is:
AbstractView(m:globalModel ...
then I check to see what kind of model i get but I'm all set.

[Flash Gordon]

Like I mentioned before, I'm very hands on. I would need a sample to say anything worth while.

However, just shooting from the hip I would guess you should have 3 models: Application Model, Photo Model and Map Model. All Application Model does is hold references to Photo Model and Map model.