|
There are plenty of example explanations of this all over the internet.
Veni, vidi, abiit domum
|
|
|
|
|
This[^] article might help you.
|
|
|
|
|
Thanks for that link. The article showed some variation there in the end, that brought in some ideas on how abstract classes could be useful (the IEnumerable). I think I will play With several code blocks and compare the use of them. I will read some books on the subject.
I can also now can conclude on of my problems:
- abstract classes without any implementations just look like Interfaces
- It seems to me that using abstract classes in a small context is shear silliness, but in a larger "code-stretch" they are beneficial, as my second code post and it's answer shows.
- A class that inherits from an abstract class cannot access the original implementation of a method
modified 12-Jan-14 7:29am.
|
|
|
|
|
Quote: A class that inherits from an abstract class cannot access the original implementation of a method
Actually it can, just call base .MethodName(...) to call the base implementation, even if you have overridden it. Works for overridden properties too.
|
|
|
|
|
public class D
{
public virtual void DoWork(int i)
{
}
}
public abstract class E : D
{
public abstract override void DoWork(int i);
}
public class F : E
{
public override void DoWork(int i)
{
}
}
You can't call DoWork in class D from F. Which brought me to a new reason for using abstract classes: an abstract class can force derived classes to provide new method implementations for virtual methods.
|
|
|
|
|
Yes, that's right, you can't call the base.base method since F overrides E not D.
But I wouldn't agree that a base class can force its derived classes to provide a new method using virtual, since E has the choice to provide a new method or force it to the derived class. This is the function of the abstract operator, not the virtual one. The only reason that DoWork was forced to be overridden is because its base class (E) declared it as abstract, not because D declared it as virtual. In this instance E is the base class, not D, so it forces through the abstract keyword, not the virtual one.
|
|
|
|
|
netfed wrote: abstract classes without any implementations just look like Interfaces More or less Yes, but their purpose are different. Interface is used to enforce a contract while Abstract class is used to build family trees.
netfed wrote: A class that inherits from an abstract class cannot access the original implementation of a method As the reply below already suggests, use base.MethodName() syntax.
|
|
|
|
|
Hi,
1) With an abstract class A you can define re-usable implementation for derived classes. This is a way of removing duplicate code in multiple derived classes.
2) With an abstract class you can defer implementation to derived classes e.g. defining abtract methods or properties. Why would you do that? Well you can call the abtract definition from implementation in the abstract class.
3) With an abstract class you can let implementation code be extended via overrides
4) With an abstract class you can declare collections of the abstract class, but add derived classes to the collection.
I will try to make an example to illustrate above features:
abstract class A
{
abstract string Label {get;};
string ToLabel()
{
return this.Label;
}
virtual void Writeline()
{
Console.Out.Writeline();
}
}
class X : A
{
override string Label{ get{ return "I am X!"; }}
}
class Y : A
{
override string Label{ get{ return "Me is Y!"; }}
override void Writeline()
{
Console.Out.Writeline(">>>");
base.Writeline();
Console.Out.Writeline("<<<");
}
}
void SomeCode()
{
List<A> as = new List<A>();
as.Add(new X());
as.Add(new Y());
foreach(A a in as)
{
Console.Out.Writeline(a.ToLabel);
}
}
Lots of patterns make use of abstract classes e.g. http://en.wikipedia.org/wiki/Abstract_factory_pattern[^] and http://en.wikipedia.org/wiki/Composite_pattern[^].
Try play around with it and the different ways of calling up or down between abstract and concrete classes. It takes some getting used to and some redesign.
Some rules I try to stick to stay sane:
- (abstract class) only declare fields as private
- (abstract class) store a field for each non-abstract property (if a state)
- (abstract class) use protected properties/methods to serve derived classes (hidden from the public)
- (abstract class) always expect virtual methods/properties to be called by derived classes
- (derived class) always call base in overriden virtual method/property
I hope it helps.
Kind Regards,
Keld Ølykke
|
|
|
|
|
Thank you for the code, although it had to be modified a bit to run, but what do you mean by the following:
- (derived class) always call base in overriden virtual method/property?
This I do get, and I find it a good OO-realted advice:
(abstract class) only declare fields as private.
Thanks for the link that lead to this:
[^]
... which talks about the usefulness of it all.
modified 12-Jan-14 7:43am.
|
|
|
|
|
Hi,
You are welcome. Maybe you should post the runnable code, if you think it will help people.
"but what do you mean by the following:
- (derived class) always call base in overriden virtual method/property?"
Inheritance in OOP is relatively loose. The only thing you can be certain about is that constructors are chained e.g. new Y() will call the constructor of Y that as its first statement will call the constructor of A, etc.... all the way up til the contructor of Object. You can then have your constructor code in different implementation called on the way back from Object.
For all other methods/properties no such guarantee exists. In other words it is optional to call a base-method, which makes it pretty hard to manage private fields in the base class
So these 2 go together:
-----------------
- (abstract class) always expect virtual methods/properties to be called by derived classes
- (derived class) always call base in overriden virtual method/property
-----------------
It is just 2 calling convention rules that mimic the constructor chaining for all virtual methods. In this way we can design interdependency between A and X - even though the language supports that you can avoid calling base methods/properties.
I hope it makes sense... otherwise I can elaborate.
Thx for the nice link, btw.
Kind Regards,
Keld Ølykke
|
|
|
|
|
Hi Community. I have some questions about Loose Coupling Pattern in the Application Design. Is Loose Coupling Pattern The Best pattern for a TDD (Test Driven Development). Can you tell other Patterns in Application Design for TDD? Please can you bring some examples about Loose Coupling?
modified 8-May-21 21:01pm.
|
|
|
|
|
Hi Omar,
Loose Coupling it isn't a pattern, but a programming best practice. You are talking about Inversion of Control and Dependency Injection topics. I suggest you to read the following article to introduce yourself in the question : http://www.codeproject.com/Articles/25733/Dependency-Injection-Pattern-Loose-Coupling
|
|
|
|
|
Antonio Ripa wrote: but a programming best practice
Within reason of course.
|
|
|
|
|
jschell wrote: "best practice"
FIFY
|
|
|
|
|
Hi,
I have asked "Which Software Patterns makes your libs/apps testable?"
here[^]
At the bottom you will find a nice short list of patterns/principles to use.
Kind Regards,
Keld Ølykke
|
|
|
|
|
Hallo,
im a writing a quite bigger than usually project, and I am dealing with some questions considering architecture and security.
To make it short, I have a Windows server with a WCF installed, which is waiting for an outside question from a client that needs some updates.
The updates have to be created from a dll, which accesses a Database, runs sql scripts and provides a zip file in the end.
Is it ok to call the dll from a function inside the WCF? That function should then pass a string which needs the library.
Would it be better to call a programm that consequently calls the dll, thus having a separated instance between WCF Service and the library, which accesses the database?
Or maybe there is a better solution?
Thanks in advance.
|
|
|
|
|
How many levels of separation do you want. Your WCF should be enough separation, I would have it call the DLL (which IS another program after all). There may be some security issues around you web server and the WCF communications that you may need to address.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Some reasons for using a separate program.
- The dll is unstable and because of that it can cause an application exit.
- The dll is already encapsulated in an executable and in fact is easier to use that way or even can only be used that way.
- The dll is not structured for multi-threading and you want to use it in more than one thread.
|
|
|
|
|
1. Is the DLL a .NET Assembly?
2. Do you own the DLL?
Since it is a DLL, it is going to be loaded in the same process as your WCF service. If you are the author of the DLL or you trust the source, you should be able to safely use the DLL directly from the WCF service. However, if you don't own it or you're not sure of the source, then you can load the DLL in a separate AppDomain and access it from there, mind that it there will be a overhead though.
|
|
|
|
|
Hii
I have a doubt in web browser related to web designing.Why html image alt text doesn't work in Firefox and IE.Could you tell me the reason?
http://www.iqtechways.com
|
|
|
|
|
I'm sorry, but you have picked the wrong forum for this question. Please try the web development forum, and when you do, post some code to demonstrate the problem.
|
|
|
|
|
The "alt" tag is meant to show text when the image isn't loaded, the "title" tag is meant for a description of an image on cursor hover. IE has been doing that wrong for many years, where Firefox follows W3C standards. A properly coded webpage should have both "alt" and "title" tags. So you can use Title For that Purpose
modified 28-Nov-13 0:12am.
|
|
|
|
|
i want to implement a project , how can i start initially.
|
|
|
|
|
Open Visual Studio, select the project type that you are after and then give your project a name?
You have given too little information for any serious answer
Every day, thousands of innocent plants are killed by vegetarians.
Help end the violence EAT BACON
|
|
|
|
|
Well, it's very outrageous comment I think.
|
|
|
|