|
Ideally is the word, except if you want to share code between two different versions of the CLR. This is the method that you are pretty much forced to do if you want the same code to work between WP7, Silverlight and WPF.
|
|
|
|
|
As long as you share files across same kind of projects that are targeted for different platforms, you are fine. But if you share file with projects of different nature, changing the file in one project may render the other project not compile at all (and trying to fix it may make the other project not compile). And that is something really dirty.
|
|
|
|
|
Indeed, but as I say, sometimes it's necessary. Welcome to the world of the professional WPF/Silverlight developer.
|
|
|
|
|
|
Looks good. Nice find.
|
|
|
|
|
Ok so i'm messing around with a few things, specifically interfaces.
Say I have a class 'Cat' with its base as 'Animal' Animal has a method in it like so
public virtual void Walk()
{
}
So Cat would override it with:
public override void Walk()
{
}
Simple right?
Here's my question though, is there a way to force cat to override the base Walk() method? So if another developer added a Dog class they would be forced to implement their own Walk method (even if it was just base.Walk()) ?
So interfaces kind of solves this, this is what i've tried
Cat : Animal : Interface
Animal has to implement the Walk method, but Cat doesn't
Cat : Animal, Interface
Cat has to implement the Walk method, but if the developer doesn't add or forgets the ',Interface' then it will 'break' it.
can someone give me some pointer as to go about this ?
Thanks.
|
|
|
|
|
Sort of, you can make the method abstract, then it will have to implemented somehow. It could just throw a NotImplementedException though.
|
|
|
|
|
Using an abstract method in the base Animal class prevents you from doing base.Walk() because it has no implementation.
|
|
|
|
|
Yes, but you could call it baseWalk without the dot.. or something less silly.
|
|
|
|
|
|
Collin Jasnoch wrote: not virtual. That is for overloading
Virtual is not for overloading. You do not need any special keyword overload. Both virtual and abstract are for overriding. Abstract, is a forced one while virtual is not.
"The worst code you'll come across is code you wrote last year.", wizardzz[ ^]
|
|
|
|
|
Interfaces cannot have any implementation, which is what I want
|
|
|
|
|
Well, abstract will force the subclass to implement, but that prevents you from having a base implementation.
You could do this with a pair of methods...
public void Walk()
{
WalkInternal();
}
protected abstract void WalkInternal();
This way, the subclass is forced to implement WalkInternal() , but all external calls would go to the base class's Walk() (Which can't be overridden).
|
|
|
|
|
When I need this type of functionality, I normally implement an abstract On method that the sub classes have to override. Here's an example:
public abstract class Animal
{
public void Walk()
{
Console.WriteLine("Starting the legs off now...");
OnWalk();
}
protected abstract void OnWalk();
}
|
|
|
|
|
Member 8209737 wrote: can someone give me some pointer as to go about this ?
In general it isn't usually worth time trying to get someone else to do the 'right' thing.
For example even if you force it one can still throw an exception or just call the base method (whether that is right or wrong.)
One uses interfaces and abstract classes not to force others to do the correct thing but rather to implement functionality that would otherwise be difficult, hard, impossible or obscure via some other methodology. If done correctly. If not done correctly then the design if flawed anyways so implementation details become meaningless.
One uses unit tests, system tests, etc to insure that correct functionality is implemented.
|
|
|
|
|
Member 8209737 wrote: can someone give me some pointer as to go about this ?
Does it have to be on the class level, or would it be alright to have it at the object-level (say, an event[^]?)
class SomeAnimalClass
{
public event EventHandler IsWalkin;
protected virtual void OnWalk()
{
Console.WriteLine("Doing walking stuff for " + this.GetType().Name);
EventHandler isWalkin = IsWalkin;
if (isWalkin != null)
{
isWalkin(this, EventArgs.Empty);
}
else
throw new NotImplementedException("DoWalk isn't implemented in " + this.GetType().Name);
}
public void StartWalkin()
{
OnWalk();
}
}
class Cat: SomeAnimalClass { }
class Dawg: SomeAnimalClass { }
class Program
{
static void Main(string[] args)
{
SomeAnimalClass animal = new Cat();
animal.IsWalkin += (o, s) =>
Console.WriteLine("specific walking stuff for this animal of type " + animal.GetType().Name);
animal.StartWalkin();
SomeAnimalClass otherAnimal = new Dawg();
try
{
otherAnimal.StartWalkin();
}
catch (NotImplementedException nie)
{
Console.WriteLine(nie.Message);
}
Console.ReadKey();
}
}
Output;
Doing walking stuff for Cat
specific walking stuff for this animal of type Cat
Doing walking stuff for Dawg
DoWalk isn't implemented in Dawg
Reposted, seems I did something wrong as the prev. post doesn't show up
Bastard Programmer from Hell
|
|
|
|
|
I like the idea, and someone else suggested using event as well, however I think it would add to the complexity and would make a developers life harder.
Im going to have a think and have a play around with the suggestions
|
|
|
|
|
In a word, no. The closest thing is to declare the method abstract, but as others have pointed out, you can't have an implementation together with abstract.
However, if you have a base implementation, and it's valid for the subclass simply to call base.Walk, why do you want to require it to be overridden in the first place? Subclasses which do not will inherit that version of the method anyway, essentially having an implicit 'Walk() { base.Walk{} }' in terms of usage.
There's really three common scenarios that I've seen:
- You want polymorphic behaviour, but the base class doesn't know what that might be. This is what abstract methods are for.
- You want to allow subclasses to provide behaviour, but the base class has some idea what it a sensible default. For this you should use a virtual method, even if the default action is nothing.
public virtual void Walk(){} - You know what the basic template for behaviour is, but you want subclasses to be able to customise parts of it, or you are missing information. I tend to do this with the 'MethodName'/'MethodNameInner' approach, where MethodNameInner is usually protected abstract, but if there is a reasonable default (often empty), it can be protected virtual instead.
public void Walk(){
Leg legToMove = LegToWalkWith;
legToMove.MoveForward();
}
protected abstract Leg LegToWalkWith { get; }
or more realistically (pseudocode as I can't remember exactly how this works right now):
public void ReadConfig(string configFile){
XmlDocument xmlDoc = GetXmlDocument(configFile);
XmlElement elem = xmlDoc.GetElement(ConfigNodeXpath);
foreach(XmlNode node in elem.ChildNodes){
XmlElement subelem = node as XmlElement;
if(subelem == null) continue;
}
}
protected abstract string ConfigNodeXpath { get; }
Your situation sounds more like the second scenario (you want to provide a default implementation) and therefore a virtual method should do the job nicely.
|
|
|
|
|
In SQL Server 2008, I have a table with several columns. One of the columns is "Item Type". My application currently generates a basic report which says something like this:
# Units Received 100
# Units Tested 85
# Units Shipped 60
# Units Awaiting Shipping 25
I have been instructed to change this report in a way that will break the units down by the "Item Type" field. I have received a printed example which was created in MS Excel 2007 which looks like this:
Total
# Units Received 100
Laptop 50 50% (Percent of total)
Netbook 30 30%
Desktop 20 20%
# Units Tested 100
... Amt Pct%
etc., etc.
I am using LINQ To SQL (C#, .NET 4.0, VS2010). Should I read all of the necessary records into a collection in memory and then create collections based on each type, by category (received, tested, etc.)? Or is there a better way to do this?
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
IMHO, presenting the data to the user is job of the front end code. Thus, the layout should be done by the application. So, you should get the data from the database and then change it the way you like for display.
This does not mean that you should get each and every thing from the database. Just get the relevant data from the database and format it the way you like.
"The worst code you'll come across is code you wrote last year.", wizardzz[ ^]
|
|
|
|
|
Thanks, d@nish. I understand what you are saying. I guess I could have clarified that I was uncertain about how to retrieve the data (efficiently) from SQL Server, not about how to present the data. But I think I have figure it out now.
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
You can use DataReader since that is faster than DataSet. You can make use of SQL Profile and Database Tuning Advisor to improve the query performance. Checking the execution plan would help as well.
"The worst code you'll come across is code you wrote last year.", wizardzz[ ^]
|
|
|
|
|
If these numbers are going to remain the order of magnitude in question, yes, load the whole thing into memory and do whatever analysis you want in code. I agree with D@nish that it belongs there in principle, and with only a few hundred rows, performance shouldn't be a consideration.
|
|
|
|
|
Okay, thanks. I implemented it this way, loading the data into memory and then manipulating the data from there. It is quite fast -- and definitely quick enough for the purpose of the report. However, I have several thousand rows, not just hundreds.
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
Linq to Sql support the group by clause which might be helpful to you.
|
|
|
|