|
An object called MovableObject can move through different methods.
MoveByLegs, wheels & Wings. When we choose one method, i.e MoveByLegs and pass Legs arguments, the other two will be unused.
Should I design it like this:
enum MoveType
{
MoveByLegs,
MoveByWheels,
MoveByWings
}
class MovableObject
{
List<leg> lstLegs;
List<Wheels> lstWheels;
List<Wing> lstWings;
MoveType m_Movetype;
EnableMovement(MoveType movetype_in, object obj_in)
{
m_Movetype = movetype_in;
switch (movetype_in)
{
case MoveByLegs:
lstLegs = List<Leg>(obj_in);
break;
case MoveByWheels:
lstWheels = List<Wheel>(obj_in);
break;
case MoveByWings:
lstWings = List<Wing>(obj_in);
break;
}
}
Move()
{
if(m_Movetype == MoveType.MoveByLegs)
{
}
similar case for MoveByWheels & Legs
}
}
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy.
|
|
|
|
|
Hmmm, you're mixing and matching things a lot here. As you're creating movable "things", you should consider the fact that each one of these is a separate movable type. This indicates that you should consider the fact that you're using an enum and change it to something like this:
public abstract class MovableObject
{
}
public class Legs : MovableObject
{
}
public class Wheels : MovableObject
{
}And there you have it - it's a lot cleaner and simpler to work with OO features.
|
|
|
|
|
Hmm let me explain it visually.
The movable object = An Egg.
Now you attach a set of legs, it walks through Legs.
If you attach a set of wheels, it rolls by wheels.
And when you attach a pair of wings, it flies by wings.
So We cannot inherit leg, wings, wheels from the Egg.
The Egg _has_ all these.. one at a time. Not all at the same time.
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy.
|
|
|
|
|
My design still works - change MovableObject to MovableEgg in my example and you see that it still stands (so to speak). Consider this example:
public abstract MovableEgg
{
public void Move();
}
public abstract EggWithLegs : MovableEgg
{
public virtual void Move()
{
Console.WriteLine("I'm walking");
}
}
public abstract EggWithWings : MovableEgg
{
public virtual void Move()
{
Console.WriteLine("I'm flying");
}
}
|
|
|
|
|
I guess the egg is an object with many things in it other than how it moves. Does the way it movers affects other things, like graphics etc? If yes look for "component design pattern".
If it is just a different way of movement then you can use this:
Interface IMovementMethod
{
public void Move(Egg AnEgg,...);
}
Class Egg
{
public IMovementMethod MovementMethod {get; set;}
public void Move(...)
{
MovementMethod.Move(this,...)
}
}
This way you can change the MovementMethod property if you want to change the way it moves.
|
|
|
|
|
Better example Here[^]
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy.
|
|
|
|
|
VuNic wrote: Should I design it like this:
Movement is an attribute not an entity.
So
Entity (not MovableObject) 'has' movement.
Thus objects would be
Entity
MovementWings
MovementLegs
MovementWheels.
And you set it by calling.
entity.setMovement(Movement)
The Movement itself is either enable/disabled (where 'enable' means to actually allow movement) so each Movement object would have a property to enable it. Then Entity could call that if it has Movement (if internal varible is not null.)
|
|
|
|
|
I need to explain more about the requirement. I'll come back and roll them down soon. thanks for your replies.
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy.
|
|
|
|
|
Better example Here[^]
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy.
|
|
|
|
|
Except of course that has nothing to do with movement.
|
|
|
|
|
Hello: I'm working on a large database project that I currently have in VBA/Access 2007 and intend to put into VB.Net/Access 2007 as I think it might be a better idea but I'm not sure. This program is for a large law case where I will be required to deploy it by sending it out on disks to various other firms across the country. I'm a bit rusty with this so I want to know the best way to handle the solution. If all these other firms don't have Access, what other type of database should I use? What is the best practice for deployment?
|
|
|
|
|
What does "large" mean? Presumably you mean a lot of data versus a lot of users.
Using .Net should eliminate the problem of them not having MS Access. MS Access is the GUI part with some other additionally functionality, but is not required to actually access the data. However testing is always a good idea.
Member 8385949 wrote: If all these other firms don't have Access, what other type of database should I
use?
Alternatives really depend on exactly what the application is doing and what "large" means.
|
|
|
|
|
Do not use Access, for the precise reason you have indicated, the client will potentially need the exact version of office you are using.
I would look at SQL Server CE, there is a 4gb limit but I suspect this would not be a problem.. There are also a number of other small, embedable databases available.
When completed and tested deploy using an installation project or package.
Let me emphasise Access is WRONG for this job!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: the client will potentially need the exact version of office you are using.
That would only be the case if one used some fairly esoteric features and I doubt those are available via the normal databass access of C#/.Net.
|
|
|
|
|
... i think this may become a potentially heated debate but really i'm just hoping to hear from somebody with Crystal Ball (i.e. not interested in what's Right, what's Wrong, what's Cool and what's not) - I just want to know "what's going to happen"
Is .NET going to become legacy that new apps will mostly be done on top of WinRT API? [^]
After all, WinRT appears on both "Desktop" and "Metro" side of Windows 8 API stack - where as .NET only appears on "Desktop" side.[^]
While I have no doubt we'll all be coding under "Desktop" environment for years to come, that "Desktop" isn't going away. However, is this a hint that .NET is legacy? That WinRT is the shiny new API that us lowly developer should all adopt? Is M$ giving us a hint (shivers up my spline this reminds me of Silverlight M$ is very generous when it comes to wasting our time)
what I am thinking is, worst come to worst, our investment in server side will remain "Desktop" - we only consider any "Metro" development for GUI side. GUI (metro/WinRT) and server (Desktop/.NET) communicates via socket - but not sure if wiring down byte array will work or not. I am pretty sure an Int32 (what about IList/IDictionary or even DataTable) gets wired back/forth correctly serializing/de-serializing using .NET DataContractSerializer, just not sure what further complication.
Also wonder how easy/difficult will it be to port .NET code to WinRT (For example I suspect while C# be same on both platform, but platform API such as File.AppendAllLines will probably be different). Remember porting your .NET dll's to now dead Silverlight? (That SL enforces generics? Sh*t that's manual changes everywhere what were they thinking - I read somewhere WinRT too they will take away all the non-generic collections)
dev
modified 9-Dec-12 21:50pm.
|
|
|
|
|
devvvy wrote: I just want to know "what's going to happen"
And why do you believe that developers are any better at foretelling the future than astrologers?
One of these days I'm going to think of a really clever signature.
|
|
|
|
|
Richard MacCutchan wrote: And why do you believe that developers are any better at foretelling the future than astrologers?
No i don't believe in anything. But perhaps there are those who has inside information.
dev
|
|
|
|
|
devvvy wrote: However, is this a hint that .NET is legacy?
Why is it that with each new thing, something else "needs to become legacy"?
WinRT is unmanaged, and will not replace the unmanaged environments.
|
|
|
|
|
Eddy Vluggen wrote: Why is it that with each new thing, something else "needs to become legacy"?
hope not!
Eddy Vluggen wrote:
WinRT is unmanaged, and will not replace the unmanaged environments.
What about WPF and .NET itself you think?
dev
|
|
|
|
|
Take a look at history; both Microsoft and the community tried to kill VB6.
It's still here.
WPF looks definitely looks like something worth investigating. No, WinForms isn't going away either 
|
|
|
|
|
Eddy Vluggen wrote: WPF looks definitely looks like something worth investigating. No, WinForms isn't going away either
I do both so no bias here but you can't deny most new jobs requires WPF not winform.
dev
|
|
|
|
|
devvvy wrote: I do both so no bias here but you can't deny most new jobs requires WPF not winform.
Depends on your location; more WinForms here than WPF. A few kilometers south-east, and they'll tell you that Java is preferred.
|
|
|
|
|
I don't think WinRT/Metro was ever envisioned by Microsoft as a total replacement API for full .NET. After all, WinRT is a subset of .NET. I think the motivation and drive behind WinRT is the iPad. Microsoft saw (as did we all) a huge shift in consumer computing to include lightweight tablet computing (as opposed to "heavy" tablets, which have been around for a very long time, e.g. Windows XP Tablet Edition.)
Microsoft knew that if it didn't want to lose market share to Apple (considering the whole of the computing ecosystem), it needed to compete on the same grounds with the same range of offerings, rather than sticking to "desktop/laptop only". I think that's the real motivation behind WinRT. Smaller, lighter, runs on ARM.
Microsoft also wanted to make sure that unlike the iPad, that their offering had the rather novel convenience of having your portable apps run on both the "WinPad" and the desktop... something that can't be done with iOS. Since they couldn't support a full blown traditional application model on the tablet (given the storage, CPU, and battery life differences), they needed to create something new that would work on both platforms... hence, WinRT was born. And sure, Microsoft is pushing WinRT right now, and with good reason: they desperately want the WinPad to succeed. It has nothing to do with abandoning the desktop experience, or abandoning the full .NET framework.
In other words, I am very much inclined to believe that full .NET will continue to be developed by Microsoft, and WinRT is really for lightweight apps that need to be run on both "WinPad" and desktop. (Is anyone else calling it "WinPad", or did I just coin the term?? lol)
Let's say, for "giggles", that Microsoft was actually stupid enough to completely abandon the full .NET framework in favor of the lighter WinRT. What then? Nothing. Fortunately for us, Microsoft isn't the only game in town as far as .NET development goes. I've been fairly impressed by Mono, which offers a variation on .NET that's even cross platform... running on Windows, Linux, Mac, and even Android & iOS. Since Microsoft isn't the only one offering the full .NET "experience", if Microsoft jumps ship for an all-WinRT future (very unlikely IMO), all you'd need to do is switch to Mono, where your C# code should work pretty much as-is.
So, don't worry about it. Continue writing .NET apps until you know you'll need an app to run on both platforms. Then use the WinRT subset for that particular app. I think (and apparently Microsoft does as well) that there's room in the computing ecosystem for both full-on .NET desktop apps and lightweight WinRT apps. In short, WinRT is an addition to our computing ecosystem, not a replacement for full .NET.
|
|
|
|
|
|
Bottom line is that Metro is for "Windows 8 Apps", not "Windows Apps"... the latter being "real" Windows apps as we all know and love, and the former being lightweight apps that run on BOTH the desktop and WinRT. For applications appropriate for the portable space, that's probably the way to go... the *only* way to go if you want to target WinPad (Windows 8 tablets). For Line of Business applications that will require a more desktop experience, the full .NET is probably the way to go. (If portability is needed in such cases, I could see making a "light" version of an app with simpler controls and fewer features with Metro as a side-by-side addition to the main desktop app written against full .NET... that's pretty common these days for road warriors with iPhone apps that let them do some things for work while on the road, while having full features at their desk.)
Regarding WinRT appearing on the desktop, it does indeed, but only for Windows 8. (AFAIK there will be no WinRT mode ever for Windows 7, Vista, or XP.) This is done so that apps written for WinPad will also run on the Windows 8 desktop... it doesn't mean that WinRT is the "real core" of the Windows 8 desktop, or even the most important aspect. It's just something added to the desktop experience to let you use your Metro apps on both types of devices. This would be analogous to Apple creating a means to let apps for iPhone run natively on Mac OSX.
So, again, I figure it's not a replacement API, but a new additional API that has its purpose, just as the full .NET experience also has its purpose.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
