What with tombstoning, serialisation is pretty central to WP7 apps. And location based apps are all the rage. But when I tried to put a GeoCoordinate into isolated storage settings, it failed to rehydrate later, and I ended up serialising lat and lng independently, which is highly unsatisfactory as I've ended up with boatloads of ad hoc serialisation code. I've cleaned it up somewhat using reflection, but really it's all a big mess.
What's the deal here? Is there a Right Way that I haven't learnt?
And if not, what were the writers of the GeoCoordinate class thinking? Annotation with the DataMember attribute is all it would have taken. Did it never cross their minds that locations might be part of app state in a WP7 app?
I've already seen this piece on serialisation and isolated storage files as well as this rather more interesting piece which links to a rather basic DIY binary serialisation helper (Microsoft's BinaryFormatter class is not available).
Mango includes Silverlight4, or so I'm told (my notebook doesn't have enough RAM, and she who must be obeyed has forbidden me to build a bigger system till after our August ski trip) - does anyone know whether this means BinaryFormatter will be available? I could reproduce BinaryFormatter but I'd rather not.
Unless I'm misunderstanding you, could you not just cast the values of your GeoCoordinate into a custom, serializable object? Rehydrating is simply deserializing your object and creating a new GeoCoordinate object.
I'm not sure if BinaryFormatter is avaialable in the Mango toolkit, but the Mango toolkit is already out (beta) so you could take a look.
Although I maintain my opinion that Microsoft should exercise some common sense and ensure that classes like GeoCoordinate are DataContract serialisable, I have found a convenient workaround. Generally when one is doing this sort of work, one has imported the interface for the BingRoute webservice, or similar.
Obviously all of the classes therein are serialisable so I converted all my code to use the BingRoute.Location type instead of GeoCoordinate, and the problem disappears. Where necessary, an extension method ToGeoCoordinate() makes the conversion sufficiently unobtrusive that the intent of existing code is unobscured.
public static GeoCoordinate ToGeoCoordinate(this BingRoute.Location loc)
{
return new GeoCoordinate(loc.Latitude, loc.Longitude, loc.Altitude);
}
If you take my advice then sooner or later you will miss GeoCoordinate's GetDistanceTo() method. Extension methods are your friend here too.
You could convert both points to GeoCoordinate and use the built-in method, but this will produce large numbers of transient objects and at some point your app will choke while the garbage collector does its duty.
I threw in the other built-in location type for good measure. Note that the distance code implements Haversine, which is a Great Circle computation with a number of limitations. Caveat emptor.
public static double GetDistanceTo(this BingRoute.Location A, BingRoute.Location B)
{
return GetDistanceTo(A.Latitude, A.Longitude, B.Latitude, B.Longitude);
}
public static double GetDistanceTo(
this Microsoft.Phone.Controls.Maps.Platform.Location A,
Microsoft.Phone.Controls.Maps.Platform.Location B)
{
return GetDistanceTo(A.Latitude, A.Longitude, B.Latitude, B.Longitude);
}
static double toRad = Math.PI / 180D;
static double toDeg = 180D / Math.PI;
static double GetDistanceTo(double lat1, double lng1, double lat2, double lng2)
{
lat1 *= toRad;
lng1 *= toRad;
lat2 *= toRad;
lng2 *= toRad;
double sin_dLng_on2_squared = Math.Sin((lng2 - lng1) / 2);
sin_dLng_on2_squared *= sin_dLng_on2_squared;
double sin_dLat_on2_squared = Math.Sin((lat2 - lat1) / 2);
sin_dLat_on2_squared *= sin_dLat_on2_squared;
double a = sin_dLat_on2_squared + Math.Cos(lat1 * Math.Cos(lat2) * sin_dLng_on2_squared);
double c = 2 * Math.Asin(Math.Min(1, Math.Sqrt(a)));
return c * 6371000;
}
It's also quite important to note that the more you store, the slower your app starts because it takes longer to create the settings object on activation. So you're best advised to store only simple option state here and keep as much as possible in isolated storage files.
Related
I am making a simple turn-based farming simulator game where players make choices whether to buy land or crops and have turn-count based growing. Different crops grow for different times, and have different purchase prices and sale values. Objective is to be the first to reach a dollar amount.
My question is how to develop these crops programmatically. I currently have each crop variation as a subclass of a Crop, however, this leads to a lot of redundancy (mostly different field/attribute values, or image paths). Since these objects are very similar save for some values, should they be subclasses, or would it be better practice to make one class Crop with an Enum of type and use logic to determine the values it should have?
Superclass Crop
subclass Wheat
subclass Corn
subclass Barley
Or
Crop.Type = CropType.Wheat
if(this.Type == CropType.Wheat) { return StockMarket.Wheat_Sell_Value; }
else if(this.Type == CropType.Corn) { return StockMarket.Corn_Sell_Value; }
If you make a single crop class it risks becoming very large and unwieldly, especially if you want to add a new crop type you'll have to update the 100's of if statements littered through your code (e.g. if(this.Type == CropType.Wheat) { return StockMarket.Wheat_Sell_Value; }).
To echo #oswin's answer, use inheritance sparingly. You are probably ok using a base-class with a few "dumb" properties, but be especially careful when adding anything that implements "behaviour" or complexity, like methods and logic; i.e. anything that acts on CropType within Crop is probably a bad idea.
One simple approach is if crop types all have the same properties, but just different values; and so crop instances just get acted on by processes within the game, see below. (Note: If crops have different properties then I would probably use interfaces to handle that because they are more forgiving when you need to make changes).
// Crop Types - could he held in a database or config file, so easy to add new types.
// Water, light, heat are required to grow and influence how crops grow.
// Energy - how much energy you get from eating the crop.
Name:Barley, growthRate:1.3, water:1.3, light:1.9, heat:1.3, energy:1.4
Name:Corn, growthRate:1.2, water:1.2, light:1.6, heat:1.2, energy:1.5
Name:Rice, growthRate:1.9, water:1.5, light:1.0, heat:1.4, energy:1.8
The crop type values help drive logic later on. You also (I assume) need crop instance:
class CropInstance
{
public CropType Crop { get; set; }
public double Size { get; set; }
public double Health { get; }
}
Then you simply have other parts of your program that act on instances of Crop, e.g:
void ApplyWeatherForTurn(CropInstance crop, Weather weather)
{
// Logic that applies weather to a crop for the turn.
// E.g. might under or over supply the amount of water, light, heat
// depending on the type of crop, resulting in 'x' value, which might
// increase of decrease the health of the crop instance.
double x = crop.WaterRequired - weather.RainFall;
// ...
crop.Health = x;
}
double CurrentValue(CropInstance crop)
{
return crop.Size * crop.Health * crop.Crop.Energy;
}
Note you can still add logic that does different things to different crops, but based on their values, not their types:
double CropThieves(CropInstance crop)
{
if(crop.health > 2.0 & crop.Crop.Energy > 2.0)
{
// Thieves steal % of crop.
crop.Size = crop.Size * 0.9;
}
}
Update - Interfaces:
I was thinking about this some more. The assumption with code like double CurrentValue(CropInstance crop) is that it assumes you only deal in crop instances. If you were to add other types like Livestock that sort of code could get cumbersome.
E.g. If you know for certain that you'll only ever have crops then the approach is fine. If you decide to add another type later, it will be manageable, if you become wildly popular and decide to add 20 new types you'll want to do a re-write / re-architecture because it won't scale well from a maintenance perspective.
This is where interfaces come in, imagine you will eventually have many different types including Crop (as above) and Livestock - note it's properties aren't the same:
// growthRate - how effectively an animal grows.
// bredRate - how effectively the animals bred.
Name:Sheep, growthRate:2.1, water:1.9, food:2.0, energy:4.6, bredRate:1.7
Name:Cows, growthRate:1.4, water:3.2, food:5.1, energy:8.1, breedRate:1.1
class HerdInstance
{
public HerdType Herd { get; set; }
public int Population { get; set; }
public double Health { get; }
}
So how would interfaces come to the rescue? Crop and herd specific logic is located in the relevant instance code:
// Allows items to be valued
interface IFinancialValue
{
double CurrentValue();
}
class CropInstance : IFinancialValue
{
...
public double CurrentValue()
{
return this.Size * this.Health * this.Crop.Energy;
}
}
class HerdInstance : IFinancialValue
{
...
public double CurrentValue()
{
return this.Population * this.Health * this.Herd.Energy - this.Herd.Food;
}
}
You can then do things with objects that implement IFinancialValue:
public string NetWorth()
{
List<IFinancialValue> list = new List<IFinancialValue>();
list.AddRange(Crops);
list.AddRange(Herds);
double total = 0.0;
for(int i = 0; i < list.Count; i++)
{
total = total + list[i].CurrentValue();
}
return string.Format("Your total net worth is ${0} from {1} sellable assets", total, list.Count);
}
You might recall that above I said:
...but be especially careful when adding anything that implements
"behaviour" or complexity, like methods and logic; i.e. anything that
acts on CropType within Crop is probably a bad idea.
...which seems to contradict the code just above. The difference is that if you have one class that has everything in it you won't be able to flex, where as in the approach above I have assumed that I can add as many different game-asset types as I like by using the [x]Type and [x]Instance architecture.
The answer depends on the difference in functionality between the crop types. The general rule is to avoid unnecessary complexity where possible and inheritance should be used sparingly because it introduces hard dependencies.
So if all crops are functionally similar and only differ by their attribute values then you would want to use a single class for crop, but if your game logic demands the crop types to behave very differently and/or carry very different sets of data, then you may want to consider creating separate structures.
If inheritance would be the best choice (in case you need separate structures) cannot be answered without knowing the exact details of your game world either. Some alternatives you could consider are:
interfaces (or another type of mix-in), which allows you to re-use behavior or data across multiple types, e.g. if crops can be harvested, maybe forests can be harvested as well.
structs (or data-classes), which only define the data structure and not the behavior. This is generally more efficient and forces you to do a simpler design with less abstractions.
a functional programming approach where the crops only exist as primitives being passed around functions. This has all the benefits of functional programming, such as no side effects, less bugs, easier to write tests, easier concurrency designs which can help your game scale larger.
It's been a very long time since I touched object oriented programming, so I'm a bit rusty and would appreciate your insight.
Given a class, for example CDPlayer, that includes the field numberOfTracks and currentTrack and the methods getCurrentTrack and setCurrentTrack, where should I put the functionality to set the current track to a random track? In a method such as setRandomTrack inside this class, or in the application code outside this class (e.g. player1.setCurrentTrack(randomnumbergeneratingcode))?
What are the pros and cons of each of these approaches? Which is easier to use, change and maintain? The above example is quite simple, but how do things change when I want e.g. the random number generation to be flexible - one CDPlayer instance to use a normal distribution for randomising, another to use a flat distribution, another to use a distribution defined by some set of numbers, and so forth.
EDIT
Thanks for the three replies so far.
Consider an extension to the op... After a decent amount of coding it becomes clear that on numerous occasions we've had to, in the application code, change current the track to the track three before it but only on Thursdays (which potentially has non-trivial conditional logic to work properly). It's clear that we're going to have to do so many times more throughout the dev process. This functionality isn't going to be user facing (it's useless as far as users would be concerned), it's just something that we need to set on many occasions in the code for some reason.
Do we created a setThreeTracksBeforeOnThursdays method in the class and break the tight representative model of a CD player that this class has, or do we absolutely stick to the tight representative model and keep this functionality in the application code, despite the pain it adds to the application code? Should the design wag the developers or should the developers wag the design?
Well there is no real benefit to where the code is besides that its more readable.
But in some cases it could be less redundant to put the code in the class, it all depends on the language. For example:
C# code in the class:
private Random random = new Random();
public void setRandomTrack()
{
setCurrentTrack(random.NextInt());
}
C# code outside the class:
Random random = new Random();
CDPlayer player = new CDPlayer()
player.setCurrentTrack(random.NextInt());
The code outside has to create a Random Generator outside the class to generate a random integer, you might have to create the Random Generator more than once if its not visible to the class where you calling it from.
If it is a function that all CD players have, then it should be inside the CDPlayer class.
If it is a function that just a few CD players have, then you should inherit the CDPlayer class and put the function in the child class.
If it is a function that no CD player has, then there is no reason to include it in the class. Does it make sense for the CDPlayer class to know about picking random tracks? If not, it should be implemented outside the class.
The pro of putting it inside CDPlayer is that it will be a single method call, and that the function is pretty typical of CD players so it "feels right".
A con of putting it in your application is that it requires two calls, one to get the number of tracks so you can generate the random number, and one to set it.
A con of putting it in CDPlayer is that the class needs to know about random numbers. In this particular case, it's simple enough to use a standard library, but if this were some top security CIA CD player that could be an issue. (Just noticed youvedited your post to hint at something similar)
I'd put the code in CDPlayer, (and add a method to change the random number generator, the fancy term for this is Dependency Injection) but this post hopefully gives you a few of the pros and cons.
Let's try to implement this feature. What are requirements for playing random track?
it should be random (of course),
it should be not current track (nobody wants to hear current track five times in a row if there other tracks to play)
you should pick track from those which exist in player (track number should not exceed count of tracks).
I will use C#:
Random random = new Random();
CDPlayer player = new CDPlayer();
// creates list of track indexes, e.g. { 1, 2, 3, 4, 5, 6, 7 }
var tracksNotPlayed = Enumerable.Range(0, player.NumberOfTracks - 1).ToList();
if(tracksNotPlayed.Count == 0)
// initialize list again, or stop
int index = random.Next(tracksNotPlayed.Count);
int nextTrack = tracksNotPlayed[index];
player.SetCurrentTrack(nextTrack);
tracksNotPlayed.Remove(nextTrack);
That looks like feature envy to me - some other class uses data from player to implement this functionality. Not good. Let's do some refactoring - move all this stuff into player:
public void PlayRandomTrack() // Shuffle
{
if(tracksNotPlayed.Count == 0)
tracksNotPlayed = Enumerable.Range(0, numberOfTracks - 1).ToList();
int index = random.Next(tracksNotPlayed.Count);
int nextTrack = tracksNotPlayed[index];
SetCurrentTrack(nextTrack);
tracksNotPlayed.Remove(nextTrack);
}
It looks better and it's much easier to use outside:
CDPlayer player = new CDPlayer();
player.PlayRandomTrack();
Also if you are implementing something like Winamp (it has two modes - shuffle playing and sequential playing when it automatically plays songs one by one) then consider to move this logic into some Strategy (or it should be Iterator?), which will have two implementations - sequential and shuffle, and will know nothing about player - it's responsibility will be picking number in some range (number of tracks or collection being enumerated should be passed):
public abstract class CollectionIterator<T>
{
public CollectionIterator(IEnumerable<T> source)
{
// save source
}
abstract int GetNextItemIndex();
}
The player will use this iterators/strategies to play next item:
public void PlayTrack()
{
SetCurrentTrack(iterator.GetNextItemIndex());
}
So, we have clear separation of responsibilities here - client uses player to listen music, player knows how to play music, and iterator knows how to pick next item from collection. You can create ThursdaysCollectionIterator if you want some other sequences on Thursdays. That will keep your player and client code untouched.
I have been exploring the CQRS/DDD-principles and patterns for a while now and have started implementing a sample project where I have split my storage-model into a WriteModel and a ReadModel. The WriteModel will use a simple NoSQL-like database where aggregates are stored in a key-value style, with value being just a serialized version of the aggregate.
I am now looking at ProtoBuf-Net for serializing and deserializing my domain model aggregates in and out of storage. Other than this post I haven't found any guidance or tips for using ProtoBuf-Net in this area. The point is that the (ideal) requirements for serialization and deserialization of aggregates is that the domain model should have as little knowledge as possible about this infrastructural concern, which implies the following:
No attributes on the classes
No constructors, getters, setters or any other piece of code just for the sake of serialization.
Ability to use any (custom) type possible and have it serialized/deserialized.
Thus far I have implemented just the serialization of the first versions of my aggregates which works perfectly fine. I use the RuntimeTypeModel.Default-instance to configure the MetaModel at runtime and have UseConstructor = false everywhere, which enables me to completely separate the serialization mechanics from my domain-assembly. I have even implemented a custom post-deserialization mechanism that enables me to just-in-time initialize fields after ProtoBuf-Net has deserialized it into a valid instance. So suppose I have class AggregateA like so:
[Version(1)]
public sealed class AggregateA
{
private readonly int _x;
private readonly string _y;
...
}
Then in my serialization-library I have code something along the following lines:
var metaType = RuntimeTypeModel.Default.Add(typeof(AggregateA), false);
metaType.UseConstructor = false;
metaType.AddField(1, "_x");
metaType.AddField(2, "_y");
...
However, I realize that up to this point I have only implemented the basic scenario, and I am now starting to think about how to approach versioning of my model. I am particularly interested in larger refactoring-scenario's, where type A has been split into type A1 and A2, for example:
[Version(2)]
public sealed class AggregateA1
{
private readonly int _x;
...
}
[Version(2)]
public sealed class AggregateA2
{
private readonly string _y;
...
}
Suppose I have a serialized bunch of instances of AggregateA, but now my domain model knows only AggregateA1 and AggregateA2, how would you handle this scenario with ProtoBuf-Net?
A second question deals with point 3: is ProtoBuf-Net capable of handling arbitrary types if you're willing to put in some extra configuration-effort? I've read about exceptions raised when using the DateTimeOffset-type, which makes me think not all types can be serialized by the framework out-of-the-box, but can I serialize these types by registering them in the RuntimeTypeModel? Should I even want to go there? Or better to forget about serializing common .NET types other than the simple ones?
protobuf-net is intended to work with predictable known models. It is true that everything can be configured at runtime, but I have not put any thought as to how to handle your A1/A2 scenario, precisely because that is not a supported scenario (in my defense, I can't see that working nicely with most serializers). Thinking off the top of my head, if you have the configuration/mapping data somewhere, then you could simply deserialize twice; i.e. as long as we still tell it that AggregateA1._x maps to 1 and AggregateA2._y maps to 2, you can do:
object a1 = model.Deserialize(source, null, typeof(AggregateA1));
source.Position = 0; // rewind
object a2 = model.Deserialize(source, null, typeof(AggregateA2));
However, more complex tweaks would require additional thought.
Re "arbitrary types"... define "arbitrary" ;p In particular, there is support for "surrogate" types which can be useful for some transformations - but without a very specific "problem statement" it is hard to answer completely.
Summary:
protobuf-net has an intended usage, which includes both serialization-aware (attributed, etc) and non-aware scenarios (runtime configuration, etc) - but it also works for a range of more bespoke scenarios (letting you drop to the raw reader/writer API if you want to). It does not and cannot guarantee to be a direct fit for every serialization scenario imaginable, and how well it behaves will depend on how far from that scenario you are.
I need to deal with a two objects of a class in a way that will return a third object of the same class, and I am trying to determine whether it is better to do this as an independent function that receives two objects and returns the third or as a method which would take one other object and return the third.
For a simple example. Would this:
from collections import namedtuple
class Point(namedtuple('Point', 'x y')):
__slots__ = ()
#Attached to class
def midpoint(self, otherpoint):
mx = (self.x + otherpoint.x) / 2.0
my = (self.y + otherpoint.y) / 2.0
return Point(mx, my)
a = Point(1.0, 2.0)
b = Point(2.0, 3.0)
print a.midpoint(b)
#Point(x=1.5, y=2.5)
Or this:
from collections import namedtuple
class Point(namedtuple('Point', 'x y')):
__slots__ = ()
#not attached to class
#takes two point objects
def midpoint(p1, p2):
mx = (p1.x + p2.x) / 2.0
my = (p1.y + p2.y) / 2.0
return Point(mx, my)
a = Point(1.0, 2.0)
b = Point(2.0, 3.0)
print midpoint(a, b)
#Point(x=1.5, y=2.5)
and why would one be preferred over the other?
This seems far less clear cut than I had expected when I asked the question.
In summary, it seems that something like a.midpoint(b) is not preferred since it seems to give a special place to one point or another in what is really a symmetric function that returns a completely new point instance. But it seems to be largely a matter of taste and style between something like a freestanding module function or a function attached to the class, but not meant to be called by the insance, such as Point.midpoint(a, b).
I think, personally, I stylistically lean towards free-standing module functions, but it may depend on the circumstances. In cases where the function is definitely tightly bound to the class and there is any risk of namespace pollution or potential confusion, then making a class function probably makes more sense.
Also, a couple of people mentioned making the function more general, perhaps by implementing additional features of the class to support this. In this particular case dealing with points and midpoints, that is probably the overall best approach. It supports polymorphism and code reuse and is highly readable. In a lot of cases though, that would not work (the project that inspired me to ask this for instance), but points and midpoints seemed like a concise and understandable example to illustrate the question.
Thank you all, it was enlightening.
The first approach is reasonable and isn't conceptually different from what set.union and set.intersection do. Any func(Point, Point) --> Point is clearly related to the Point class, so there is no question about interfering with the unity or cohesion of the class.
It would be a tougher choice if different classes were involved: draw_perpendicular(line, point) --> line. To resolve the choice of classes, you would pick the one that has the most related logic. For example, str.join needs a string delimiter and a list of strings. It could have been a standalone function (as it was in the old days with the string module), or it could be a method on lists (but it only works for lists of strings), or a method on strings. The latter was chosen because joining is more about strings than it is about lists. This choice was made eventhough it led to the arguably awkward expression delimiter.join(things_to_join).
I disagree with the other respondent who recommended using a classmethod. Those are often used for alternate constructor signatures but not for transformations on instances of the class. For example, datetime.fromordinal is a classmethod for constructing a date from something other than an instance of the class (in this case, an from an int). This contrasts with datetime.replace which is a regular method for making a new datetime instance based on an existing instance. This should steer you away from using classmethod for the midpoint computation.
One other thought: if you keep midpoint() with the Point() class, it makes it possible to create other classes that have the same Point API but a different internal representation (i.e. polar coordinates may be more convenient for some types of work than Cartesian coordinates). If midpoint() is a separate function you start to lose the benefits of encapsulation and of a coherent interface.
I would choose the second option because, in my opinion, it is clearer than the first. You are performing the midpoint operation between two points; not the midpoint operation with respect to a point. Similarly, a natural extension of this interface could be to define dot, cross, magnitude, average, median, etc. Some of those functions will operate on pairs of Points and others may operate on lists. Making it a function makes them all have consistent interfaces.
Defining it as a function also allows it to be used with any pair of objects that present a .x .y interface, while making it a method requires that at least one of the two is a Point.
Lastly, to address the location of the function, I believe it makes sense to co-locate it in the same package as the Point class. This places it in the same namespace, which clearly indicates its relationship with Point and, in my opinion, is more pythonic than a static or class method.
Update:
Further reading on the Pythonicness of #staticmethod vs package/module:
In both Thomas Wouter's answer to the question What is the difference between staticmethod and classmethod in Python and Mike Steder's answer to init and arguments in Python, the authors indicated that a package or module of related functions is perhaps a better solution. Thomas Wouter has this to say:
[staticmethod] is basically useless in Python -- you can just use a module function instead of a staticmethod.
While Mike Steder comments:
If you find yourself creating objects that consist of nothing but staticmethods the more pythonic thing to do would be to create a new module of related functions.
However, codeape rightly points out below that a calling convention of Point.midpoint(a,b) will co-locate the functionality with the type. The BDFL also seems to value #staticmethod as the __new__ method is a staticmethod.
My personal preference would be to use a function for the reasons cited above, but it appears that the choice between #staticmethod and a stand-alone function are largely in the eye of the beholder.
In this case you can use operator overloading:
from collections import namedtuple
class Point(namedtuple('Point', 'x y')):
__slots__ = ()
#Attached to class
def __add__(self, otherpoint):
mx = (self.x + otherpoint.x)
my = (self.y + otherpoint.y)
return Point(mx, my)
def __div__(self, scalar):
return Point(self.x/scalar, self.y/scalar)
a = Point(1.0, 2.0)
b = Point(2.0, 3.0)
def mid(a,b): # general function
return (a+b)/2
print mid(a,b)
I think the decision mostly depends on how general and abstract the function is. If you can write the function in a way that works on all objects that implement a small set of clean interfaces, then you can turn it into a separate function. The more interfaces your function depends on and the more specific they are, the more it makes sense to put it on the class (as instances of this class will most likely be the only objects the function will work with anyways).
Another option is to use a #classmethod. It is probably what I would prefer in this case.
class Point(...):
#classmethod
def midpoint(cls, p1, p2):
mx = (p1.x + p2.x) / 2.0
my = (p1.y + p2.y) / 2.0
return cls(mx, my)
# ...
print Point.midpoint(a, b)
I would choose version one, because this way all functionality for points is stored in the point class, i.e. grouping related functionality. Additionally, point objects know best about the meaning and inner workings of their data, so it's the right place to implement your function. An external function, for example in C++, would have to be a friend, which smells like a hack.
A different way of doing this is to access x and y through the namedtuple's subscript interface. You can then completely generalize the midpoint function to n dimensions.
class Point(namedtuple('Point', 'x y')):
__slots__ = ()
def midpoint(left, right):
return tuple([sum(a)/2. for a in zip(left, right)])
This design works for Point classes, n-tuples, lists of length n, etc. For example:
>>> midpoint(Point(0,0), Point(1,1))
(0.5, 0.5)
>>> midpoint(Point(5,1), (3, 2))
(4.0, 1.5)
>>> midpoint((1,2,3), (4,5,6))
(2.5, 3.5, 4.5)
My brother-in-law is a freshman engineering major in college. He has no prior programming experience. He is learning programming in his classes, but he seems to be struggling with the basic concepts. It doesn't help that he seems to be the only person in all his classes without some background in programming.
He did OK in Matlab (which I don't know), and then I helped him along when he was learning the basics of Python. Pretty soon his courses will start on C and C++. I'm worried that he will be left behind when Object-Oriented Programming comes up.
I tried explaining it to him with the analogy of a car.
Pseudocode:
Class Car
{
public string make;
public string model;
private string milesPerGallon;
private float gasolineGallonsInTank = 0;
private float tankCapacity;
private float odometer = 0;
public Car(maxGas, mpg)
{
tankCapacity = maxGas;
milesPerGallon = mpg;
}
public void fillTank()
{
gasolineGallonsInTank = tankCapacity;
}
public void drive(float miles)
{
if (miles == 0)
{
print("You don't want to drive?");
return;
}
if(miles < 0)
{
print("Ok, we're driving in reverse!");
miles = Math.AbsoluteValue(miles);
}
float maxDistance = gasolineGallonsInTank / milesPerGallon;
if (maxDistance >= miles)
{
odometer += maxDistance;
gasolineGallonsInTank = 0;
print("You've run out of gas!");
return;
}
odometer += miles;
gasolineGallonsInTank -= miles / milesPerGallon;
}
public float readOdometer()
{
return odometer;
}
}
I said that the Car class was like a car factory, and var mySedan = new Car(12, 20) was like producing a new car with a 12-gallon gas tank and 20 mpg. Then I showed him how the methods could be run, and it was like things were happening to the car.
Then I made a second car: var myMiniVan = new Car(21.5, 14) and showed how running methods on one car didn't affect the other.
But he didn't get it. All of this went way over his head. Is there a better or simpler visual analogy I can use? Am I explaining it wrong?
Our teacher used:
cars and their components - to explain classes, fields, methods, and to show what is aggregation and composition
animals (man, tiger and cat, exactly :)) - to explain inheritance
shapes - to explain more inheritance and polymorphism
Also, as far as I remember, there were some good examples in OOA&D book by Grady Booch.
On first OOP seminar we did rather unusual an interesting exercise: we implemented "classes" in C (not C++). We had to use structs and pointers to functions - this made us feel, what is state, what is behavior, what are class and objects. Then we proceeded to C++.
UPDATE
I just have remembered one more good and descriptive example of basic OOP concepts: GUI components (Buttons, TextBoxes, Captions, Dialogs). These examples are not as "abstract" as animals and cars, and they are rather descriptive - result can be seen immediately.
There are many GUI frameworks, - you just can suggest your brother to play with one of them.
Does he like beer?
http://keithchadwick.wordpress.com/2010/03/20/the-oo-beer-case-analogy/
Maybe you should take a program he understands (in python for example). And show him the benefits of following a oo approach. This is how i learned C++ after having some basic C knowledge.
But i thought your explanation was pretty clear already.
Another good analogy (especially for an engineering student) might be machine parts.
Take a carburettor. Carburrettor A is designed to meet certain spects for a certain motor, including the INTERFACE (usually sealed with a gasket which also conforms to the interface) between the manifold and carb.
There are certain holes on either surface which must line up just so, and fuel is expected to be delivered from the gas line to the carburettor at a specific pressure and volume rate. The Carb is expected to deliver a certain fuel-air mixture to the manifold for a certain vacuum pressure, etc.
This is a good starting perspective for the public interface. Carb Manufacturers dont need to know much about the motor other than the template for the interface between their carb and the manifold, and certain specs for fuel-air mixture and volume expected at the manifold. Likewise, the motor doesn't care HOW the carb does what it does, it simply needs to deliver fuel, at the proper pressure, to the proper hole in the manifold, so that the carb can perform some magic function, and deliver the proper fuel air mixture on demand. Different manufacturers may achieve this in different ways, but as long as the inputs and outputs are the same, everything works fine.
INSIDE the carb, there is all manner of stuff happening to better control the flow of fuel, and measure the vacuum pressure with pitot tubes, and such. These are akin to PRIVATE functions and methods. The means by which the carburettor knwos that, given Vacuum pressure of X, I need to supply qty of Fuel Y and air volume Z to the manifold.
While this does not necessarily do as good a job of describing Private member variables, getters vs setters, and the like, it MAY help with the concept to Interface, excapsulation, and Private vs Public methods. For me, this was initially harder to graps than private member variables and such (especially the "Interface" part . . .).
Programming is best learned by doing.
Work with him on writing a simple address book application. (No need to save anything, as this is a OOP learning experience.) Make a class CEntry that would represent each record in the address book. It would contain things such as the person's name, street address, city, state, zip code, and phone number. The make another class CName, which would have members first, middle, and last. Finally, make a third class CPhone which would have members for country, area_code, prefix, and number. As he writes it, you can explain why the use of classes makes sense for this application, as well as the benefits and drawbacks of having CEntry inherit from CName and CPhone or contain new instances of those classes.