|
Hi, thanks for your suggestion
But how could you read other's code which has 100 lines more in a method? It wasted me lot of time to scroll and positionning..
|
|
|
|
|
comiscience wrote: But how could you read other's code which has 100 lines more in a method? With a sad face.
Then I'd refactor the code, and ask the other if the change is acceptable. The compiler doesn't care about the length, nor do I - but I do care about readability and maintainability. Code that's complex is harder to support, so one would strive to keep it as simple as possible (one responsibility!)
Sit down with the other, and take the time to make it more readable; it'll help the other with writing better code, will lower your frustration-level, and will lower the cost to support the code, since simpeler code contains less bugs. Demanding that a method has a maximum length of, say, 10 lines would simply mean that coders start to divide that code over multiple methods that get called consecutively. You'd end up with the same code, but now divided over multiple methods.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Thanks Eddy
|
|
|
|
|
Install StyleCop across the team, and adjust its rules to suit the team. Then make sure that people review the output - I find that running it as part of the CI process is a great way to pick things up, plus it could form of your code review checklist. I'm pleased to see that you dropped your stance on not commenting - meaningful and well maintained comments are an absolute must.
|
|
|
|
|
|
Refering to the following two pair of classes:
public class Person
{
protected string ssn = "444-55-6666";
protected string name = "John L. Malgraine";
public virtual void GetInfo()
{
Console.WriteLine("Name: {0}", name);
Console.WriteLine("SSN: {0}", ssn);
}
}
class Employee : Person
{
public string id = "ABC567EFG";
public override void GetInfo()
{
base.GetInfo();
Console.WriteLine("Employee ID: {0}", id);
}
}
public abstract class animal
{
protected string ssn = "Poultry";
protected string name = "Mostly flying creatures";
public abstract void GetInfo();
}
class Seagull : animal
{
public string id = "ABC567EFG";
public override void GetInfo()
{
Console.WriteLine("Name: {0}", name);
Console.WriteLine("SSN: {0}", ssn);
Console.WriteLine("Specimen ID: {0}", id);
}
}
Implementing them:
Public class A2Implementation {
public A2Implementation()
{
Employee E = new Employee();
E.GetInfo();
Seagull A = new Seagull();
A.GetInfo();
}
Question
I get the exact same result in the implementation of the two pairs (unclear, albeit intentionally).
Now what are the pros and cons of using an abstract definition here (the animal-Seagull track), or what is best; just using ordinary base class Access (the Person-Employee track)?
Could I be mistaken in assuming that there is a concordance here.
modified 5-Jan-14 4:48am.
|
|
|
|
|
Not sure what you try to achieve, but from the example you made it's clear that the base-class approach is better for you.
When using abstract class you was unable to put Name and SSN into the abstract (no room for this), but if these properties are common to all then it's much better to put it in some base (that's why it called base!)...
|
|
|
|
|
Alright. I've managed to cram it in there, the abstract Properties, and I've changed the Whole lot to look a lot more similar With regards to content. Now here is what I got:
public class animal1
{
protected string name1 = "Poultry";
protected string ssn1 = "Mostly flying creatures";
public virtual void GetInfo()
{
Console.WriteLine("Name1: {0}", name1);
Console.WriteLine("SSN1: {0}", ssn1);
}
}
class Seagull1 : animal1
{
public string id = "ABC567EFG";
public override void GetInfo()
{
base.GetInfo();
Console.WriteLine("Specimen ID: {0}", id);
}
}
public abstract class animal2
{
public abstract string name2 { get; }
public abstract string ssn2 { get; }
public abstract void GetInfo();
}
class Seagull2 : animal2
{
public string id = "ABC567EFG";
public override string ssn2
{
get { return "Mostly flying creatures"; }
}
public override string name2
{
get { return "Poultry"; }
}
public override void GetInfo()
{
Console.WriteLine("Name2: {0}", name2);
Console.WriteLine("SSN2: {0}", ssn2);
Console.WriteLine("Specimen ID: {0}", id);
}
}
The implementation and output follows:
public class implementation
{
public implementation()
{
Seagull1 E = new Seagull1();
E.GetInfo();
Seagull2 A = new Seagull2();
A.GetInfo();
}
}
Resulting text output:
Quote: Name1: Poultry
SSN1: Mostly flying creatures
Specimen ID: ABC567EFG
Name2: Poultry
SSN2: Mostly flying creatures
Specimen ID: ABC567EFG
It seems to me that the use of abstract classes in this case is redundant, and the first track is sufficient, let alone more efficient. I am wondering then when the abstract classes kicks in with their possible advantages?
Could it be, if I introduced the Penguin which is not able to fly, that the flyingability becomes an issue urging the use of abstract classes?
modified 5-Jan-14 9:18am.
|
|
|
|
|
It get me back exactly to the same point...
netfed wrote:
public virtual void GetInfo()
{
Console.WriteLine("Name1: {0}", name1);
Console.WriteLine("SSN1: {0}", ssn1);
}
This code is common to all classes based on animal1 , you never write it again.
In the abstract version you have an empty GetInfo method (it's abstract so it must be empty!), and in every instance inherits this abstract class you must implement Name and SSN ...
You see base classes used when you have a certain amount of common functionality that known. Abstract class are more like interfaces as they declare the structure of the class inherits them, with the addition of some common functionality...
Again - based on your sample base class is better for you...
|
|
|
|
|
Abstract class provides you with an option to declare a non-instantiable base class from which your concrete classes inherit. You cannot instantiate an abstract class, you must instantiate one of your concrete classes.
But if you wish to be able to instantiate the base class, then do not declare it abstract. If there is shared logic that can be generalized, use an abstract base class. If the base set of functionality is complete on its own, then you can use a concrete base class.
|
|
|
|
|
Well yes. But what would be really cool is, if someone would be willing to take the time, to suggest a new code block, which could show where the abstract track is better. Anyone?
|
|
|
|
|
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
|
|
|
|