Take for example a multiple choice question game.
You have a MathQuestion and WordQuestion classes, should these implement an IQuestion interface, that defines say a question, answer, and difficulty functions OR is it more usual to extend a question base class, and override these functions?
Which is the more correct way of doing such things?
Here's another way of thinking about the problem - is there actually any different between a MathQuestion and a WordQuestion? To me, it sounds like they are both Question objects and you could differentiate between the different types via composition.
You could start by defining an Enum class which lists the different types of Questions which appear in your Quiz (strictly speaking ActionScript 3 does not have proper Enums, but we can still achieve type safety with the following code.)
public class QuestionType {
public static const MATH : QuestionType = new QuestionType("math");
public static const WORLD : QuestionType = new QuestionType("world");
private var _name : String;
// Private constructor, do no instantiate new instances.
public function QuestionType(name : String) {
_name = name;
}
public function toString() : String {
return _name;
}
}
You can then pass one of the QuestionType constants to the Question Class when you construct it:
public class Question {
private var _message : String /* Which country is Paris the capital of? */
private var _answers : Vector.<Answer>; /* List of possible Answer objects */
private var _correctAnswer : Answer; /* The expected Answer */
private var _type : QuestionType; /* What type of question is this? */
public function Question(message : String,
answers : Vector.<Answer>,
correctAnswer : Answer,
type : QuestionType) {
_message = message;
_answers = answers.concat(); // defensive copy to avoid modification.
_correctAnswer = correctAnswer;
_type = type;
}
public function getType() : QuestionType {
return _type;
}
}
Finally, a client (the code which makes use of the Question object) can query the question type easily:
public class QuizView extends Sprite {
public function displayQuestion(question : Question) : void {
// Change the background to reflect the QuestionType.
switch(question.type) {
case QuestionType.WORLD:
_backgroundClip.gotoAndStop("world_background");
break;
case QuestionType.MATH:
_backgroundClip.gotoAndStop("math_background");
break;
}
}
}
It mostly depends on the exact specifics of your classes. If the classes functionality is radically different but share function/property names then an interface would be more appropriate. If the classes share a lot of common implementation, then it would be more appropriate to subclass.
From your description, the two classes seem to fit more into the category of "same function/properties" with different implementations and would probably be better off with an interface.
I generally use interfaces are too enforce a common behavior that a group of classes share whereas sub-classing is more appropriately used in cases where you can achieve serious code re-use through inherited functions/properties. At the end of the day it's mostly a design choice.
Related
To share data (complexe data ) between pages in my windows phone 8 application I want to implement a singleton, but I want it to be generic, is it possible? I suppose that it creates a new instance for each type isn't it?
public sealed class NavigationContextService<T>
{
private static readonly NavigationContextService<T> instance = new NavigationContextService<T>();
private NavigationContextService()
{
}
public static NavigationContextService<T> Instance
{
get
{
return instance;
}
}
public List<T> ShareList { get; set; }
public T ShareData { get; set; }
}
It is creating a new instance for every type, because it is generic - you want it to be like this (if you start with generics, take a look at some tutorials, blogs or MSDN - you will easily find many in the internet).
It is still a singleton. When you use
NavigationContextService<string>.Instance.ShareList.Add("Text");
then you have one Instance for type string. Generics helps a lot when you want to create same methods/classes that differ in type.
On the other hand if you want to create Singleton that will hold different types then you can for example modify your class to be non Generic like this:
public sealed class NavigationContextServiceNonGeneric
{
private static readonly NavigationContextServiceNonGeneric instance = new NavigationContextServiceNonGeneric();
private NavigationContextServiceNonGeneric() { ShareList = new List<object>(); }
public static NavigationContextServiceNonGeneric Instance
{ get { return instance; } }
public List<object> ShareList { get; set; }
public object ShareData { get; set; }
}
As you can see in the code above I haven't defined the 'exact' type of shared data - it is object type. Then you can easily hold most of data with it:
NavigationContextServiceNonGeneric.Instance.ShareList.Add("Text");
NavigationContextServiceNonGeneric.Instance.ShareList.Add(3);
NavigationContextServiceNonGeneric.Instance.ShareList.Add(3.0f);
It is singleton, which can hold different types of shared data. BUT it has also disavantages - the main is that you have to remember what type of data you hold and in what order. In my opinion Generic version is better because of that fact.
Everything depends on the purpose of your code. There may be easier and better ways that those two approaches.
As for the Page Navigation, you can for example try to use a method from this article - you extend Navigation service to pass the object:
public static class Extensions
{
private static object Data;
public static void Navigate(this NavigationService navigationService, Uri source, object data)
{
Data = data;
navigationService.Navigate(source);
}
public static object GetNavigationData(this NavigationService service) { return Data; }
}
Then you use it:
NavigationService.Navigate(yourUri, DataToPass);
After Navigation you can get your data:
string myTextData = NavigationService.GetNavigationData() as string;
This method has to disadvantages: it is not type-safe and your data won't be preserved in Tombstone mode.
As for the second disadvantage you can easily use PhoneApplicationService.State Property for the purpose of Page Navigation - it is a dictionary (which is preserved while tombstoning):
PhoneApplicationService.Current.State.Add("data", yourData);
Then when you want to get your data:
yourDataType yourData = PhoneApplicationService.Current.State["data"] as yourDataType;
There are also more ways in which you can pass the data.
In v3 if I wanted to pass two objects to another viewmodel:
public class Dog
{
}
public class Cat
{
}
var dog = new Dog();
var cat = new Cat();
ShowViewModel<SomeViewModel>(new {Dog = dog, Cat = cat });
public class SomeViewModel
{
Init(Dog dog, Cat cat)
{
}
}
As far as I can tell that won't work because the types aren't recognized and can't be stuck in a dictionary. If I wanted to have these serialized as json, passed to the view model, and deserialized as Init parameters, would I implement IExtraParser? And if that is correct, how do I go about adding the implementations to the ExtraParsers dictionary?
update:
This seems to do it:
var foo = Mvx.Resolve<IMvxFillableStringToTypeParser>();
foo.ExtraParsers.Add(new MyParser());
The default navigation mechanism in MvvmCross is deliberately lightweight.
It is really there to allow you to pass just one simple, serializable object - e.g.
public class DogNav
{
public int Id {get;set;}
public string Caption {get;set;}
}
// received in:
public class DogViewModel : MvxViewModel
{
public void Init(DogNav dogNav)
{
}
}
With this setup, if a navigation is triggered like:
// navigation
ShowViewModel<DogViewModel>(new DogNav() { Id=12, Caption="Good boy" });
then the underlying system will transport the values from that DogNav object - possibly using Uris, Intents or other serialization techniques - to the new DogViewModel and will then ensure Init is called with the correct values.
Because of the serialization, it's important:
not to pass big objects (Uris on WindowsPhone can break above a few hundred characters)
not to expect the same object instance to arrive - i.e. if you are using database-backed or stateful objects, then it's best to pass some kind of lookup key rather than the objects themselves.
not to expect that only one ViewModel will receive the message - on some operating systems, it may be that the user goes back and forth many, many times between apps causing many Views and ViewModels to be created.
not to expect that a ViewModel that receives the message is in the same process and memory space as the ViewModel that sent the request - the same may actually be received days later after a tombstoning event.
If you do want to pass multiple objects via navigation, then I think you can do this using code like:
public class CatNav
{
public int CatId {get;set;}
public string CatCaption {get;set;}
}
public class DogNav
{
public int DogId {get;set;}
public string DogCaption {get;set;}
}
// received in:
public class CatAndDogViewModel : MvxViewModel
{
public void Init(DogNav dogNav)
{
}
public void Init(CatNav catNav)
{
}
}
In this case you could navigate using:
var catNav = new CatNav() { CatId =12, CatCaption="Meow" };
var dogNav = new DogNav() { DogId =12, DogCaption="Woof" };
var bundle = new MvxBundle();
bundle.Write(catNav);
bundle.Write(dogNav);
ShowViewModel<CatAndDogViewModel>(bundle);
I think this would work...
However... please be aware that the serialization is very simple - so if CatNav and DogNav were to share a property name, then this would lead to problems - you'd end up with some Cags and Dots
Because of the Cag and Dot problem I don't recommend this approach...
If you do need more complex transitions in your apps, then one route is to:
UPDATE - see Passing complex navigation parameters with MvvmCross ShowViewModel
1. Add the Json Plugin (or any Json serializer) and change your Setup.cs code to create a MvxJsonNavigationSerializer - overriding CreateNavigationSerializer
protected override IMvxNavigationSerializer CreateNavigationSerializer()
{
return new MvxJsonNavigationSerializer();
}
Use a composite object in navigation like:
public class DogAndCatNav
{
public DogNav DogNav {get;set;}
public CatNav CatNav {get;set;}
}
This would be received by:
public void Init(DogAndCatNav dogAndCatNav)
{
}
But note that this technique does need a more powerful serialization engine - such as Json.
Overall... even after writing all this... I'd recommend you pass as little data as possible in your navigations!
At any point of time i will be setting only one setter method but the JsonProperty name should be same for both . when i am compiling this i am getting an exception. How to set the same name for both .?
public String getType() {
return type;
}
#JsonProperty("Json")
public void setType(String type) {
this.type = type;
}
public List<TwoDArrayItem> getItems() {
return items;
}
#JsonProperty("Json")
public void setItems(List<TwoDArrayItem> items) {
this.items = items;
}
Jackson tends to favor common scenarios and good design choices for annotation support.
Your case represents a very uncommon scenario. You have one field having two different meanings in different contexts. Typically this would not be a favourable data format since it adds messy logic to the consumer on the other end...they need to divine what the "Json" property should mean in each case. It would be cleaner for the consumer if you just used two different property names. Then it would be sufficient to simply check for the presence of each property to know which alternative it's getting.
Your Java class also seems poorly designed. Classes should not have this type of context or modes, where in one context a field is allowed, but in another context it's not.
Since this is primarily a smell with your design, and not serialization logic, the best approach would probably be to correct your Java class hierarchy:
class BaseClass {
}
class SubClassWithItems {
public List<TwoDArrayItem> getItems() {
return items;
}
#JsonProperty("Json")
public void setItems(List<TwoDArrayItem> items) {
this.items = items;
}
}
class SubClassWithType {
public String getType() {
return type;
}
#JsonProperty("Json")
public void setType(String type) {
this.type = type;
}
}
That way your class does not have a different set of fields based on some runtime state. If runtime state is driving what fields your class contains, you're not much better off than with just a Map.
If you can't change that, you're left with custom serialization.
public class A
{
public X x { get; set; }
}
public class B
{
public X x { get; set; }
}
public class X
{
public X(object owner) { /* ... */ }
}
Basically if classes A and B are registered in Windsor I want to be able to resolve X dependency in such a way that it gets instance of the class it was required for.
In plain code it would look like that:
var a = new A();
var x = new X(a);
a.X = x;
Is there a way to do this in Windsor, maybe through some extensibility mechanism?
It looks like some crazy question even for me, so here is some motivation behind it:
The X in the example above is ITracer which is a proxy for TraceSource that is adding some bits of info to each traced message, namely, unique ID of the owner and its type (now it is only ID - that's why the question - I can't get to the instance and call GetType() on it).
A brief example to make it more clear. Suppose you have some service IService and want to add traces to it in the most non-intrusive way. But in the application could be dozen of instances of this service, so in traces you want to distinguish them by ID/type. It would be good if class received its tracer from the container and just wrote messages there when needed, without thinking of IDs, concrete TraceSource etc.
I already have some infrastructure that allows me to write like that:
[TracedTo("NameOfTheTraceSource")]
public class Service : IService
{
public ITracer Tracer { get; set; }
}
And Windsor correctly resolves Tracer to be its own (non-shared with other objects) instance of ITracer pointing to TraceSource with name NameOfTheTraceSource. Moreover, if I add traceAllMethods = true to the attribute - Windsor will automatically add interceptor which will write down each method call on this instance via the same Tracer (and only does this if corresponding TraceSource has some listeners configured - we don't have to support adding them on the fly). This is just awesome because it doesn't require anything from the developer of Service and it doesn't suffer performance degradation when it is not needed, not a bit. And so I'm working to make this even more convenient :)
OK, I think what you want here is a facility. Here's a simple one (with no error checking) that may be what you're looking for (or at least point you in the right direction):
public class XFacility : AbstractFacility
{
protected override void Init()
{
this.Kernel.ComponentCreated += KernelOnComponentCreated;
}
private void KernelOnComponentCreated(ComponentModel model, object instance)
{
var props =
instance.GetType().GetProperties().Where(p => p.CanWrite && p.PropertyType == typeof (X));
if (props.Any())
{
var pi = props.First();
pi.SetValue(instance, new X(instance), null);
}
}
}
Now make sure you add the facility to the container before you do any resolving:
var container = new WindsorContainer();
container.AddFacility<XFacility>();
container.Register(Component.For<A>(),
Component.For<B>()
);
var a = container.Resolve<A>();
In response to What is your longest-held programming assumption that turned out to be incorrect? question, one of the wrong assumptions was:
That private member variables were
private to the instance and not the
class.
(Link)
I couldn't catch what he's talking about, can anyone explain what is the wrong/right about that with an example?
public class Example {
private int a;
public int getOtherA(Example other) {
return other.a;
}
}
Like this. As you can see private doesn't protect the instance member from being accessed by another instance.
BTW, this is not all bad as long as you are a bit careful.
If private wouldn't work like in the above example, it would be cumbersome to write equals() and other such methods.
Here's the equivalent of Michael Borgwardt's answer for when you are not able to access the private fields of the other object:
public class MutableInteger {
private int value;
// Lots of stuff goes here
public boolean equals(Object o) {
if(!(o instanceof MutableInteger)){ return false; }
MutableInteger other = (MutableInteger) o;
return other.valueEquals(this.value); // <------------
}
#Override // This method would probably also be declared in an interface
public boolean valueEquals(int oValue) {
return this.value == oValue;
}
}
Nowadays this is familiar to Ruby programmers but I have been doing this in Java for a while. I prefer not to rely on access to another object's private fields. Remember that the other object may belong to a subclass, which could store the value in a different object field, or in a file or database etc.
Example code (Java):
public class MutableInteger {
private int value;
// Lots of stuff goes here
public boolean equals(Object o) {
if(!(o instanceof MutableInteger)){ return false; }
MutableInteger other = (MutableInteger) o;
return this.value == other.value; // <------------
}
}
If the assumption "private member variables are private to the instance" were correct, the marked line would cause a compiler error, because the other.value field is private and part of a different object than the one whose equals() method is being called.
But since in Java (and most other languages that have the visibility concept) private visibility is per-class, access to the field is allowed to all code of the MutableInteger, irrelevant of what instance was used to invoke it.