|
On more than one occasion, and again now, I face the problem of needing to aggregate logged exception data. Often the message includes one or more instance specific values, such as an account number etc. My problem is I must log the account number, or line item number, or whatever, but I also need top be able to, e.g. pull a report on how many invoices exports failed because the account was on hold.
I'm looking for a way to factor the instance specific information out of the message, making the message more of an event description, which is consistent for every occurrence of a certain exception, and additional data available for closer inspection. Using some sort of Event Type, with 'user' defined fields per event seems like a good concept for me, but what are my other options?
|
|
|
|
|
Hi all,
Have a question here. I am trying to build a software in C#, and is in the process of partitioning the work for different developers. The software will be made up of different components which will have some interdependency (ie one component will have to make use of methods from another component).
How can I proceed so that these components can be developed in parallel? Given that I have already clearly defined the interfaces to these components.
|
|
|
|
|
If the only dependencies are the interfaces and they've been cast in stone finalized, you should be able to start parallel development. I think.
Cheers,
Vıkram.
After all is said and done, much is said and little is done.
|
|
|
|
|
Say you have a class with a virtual method (using C#):
public class BaseClass
{
public virtual void DoSomething()
{
}
}
A class that derives from the base class:
public class DerivedClass : BaseClass
{
public override void DoSomething()
{
base.DoSomething();
}
}
Questions:
What is your opinion of the derived class calling the base class's implementation of DoSomething?
Suppose the base class is designed in such a way that any derived class must call the base class method/property when overriding it in order for the class's invariants to be maintained. Is this bad design?
|
|
|
|
|
|
I don't agree that it’s necessarily bad design. It’s perfectly reasonable for a derived class to add functionality rather than replace it.
Steve
|
|
|
|
|
|
The Grand Negus wrote: Perfectly reasonable presuming that one has accepted the notion that derived classes of any sort are reasonable.
Derived classes are perfectly reasonable just like it’s reasonable to use the term “vehicle” to refer to all manner of vehicles (cars, trucks, bikes, etc) or to class, say, a car as a vehicle. In the same way that much can be said about vehicles in general, a lot of the common aspects in a simulation of vehicles can be factored into a base class; the specifics of a particular vehicle are factored into derived classes.
Steve
|
|
|
|
|
The Grand Negus wrote: the question is whether or not operations upon things should be defined within those things (as if those things were capable of independent and autonomous action).
Operation on at thing usually causes a reaction that depends on the very nature of the thing itself. This is OOP point of view and, at least, an useful abstraction.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
The Grand Negus wrote: Perfectly reasonable presuming that one has accepted the notion that derived classes of any sort are reasonable.
No. the above is NOT a pre-requisite.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
|
|
|
|
|
Stephen Hewitt wrote: I don't agree that it’s necessarily bad design. It’s perfectly reasonable for a derived class to add functionality rather than replace it.
I guess what bothers me is the ambiguity involved. As a matter of practice should an overriden method call the base class method? If so, should it call it at the beginning of the overriden method or at the end? Should we rely on documentation to specify if calling the base class method is necessary?
|
|
|
|
|
That's where, in a perfect world, documentation would come into the picture. It might be valid to do things both before and after. One pattern you may be interesting in is the following:
NOTE: This is in C++. I'm no C# expert so I'm not sure how much of this will cleanly translate.
class CMyClass
{
public:
bool DoSomething()
{
int size = DoSomething_GetSize();
std::string str = DoSomething_GetString();
}
private:
virtual int DoSomething_GetSize()
{
return 1;
}
virtual std::string DoSomething_GetString()
{
return std::string("Hello");
}
};
In this pattern all the methods that users call are implemented by non-virtual public functions. Any customization needed is implemented by virtual function “hooks” that customize specific aspects of the public functions. In this pattern you don’t call the base class version (you can't as they're private) and customization is limited to specific preplanned areas.
Steve
|
|
|
|
|
What's inelegant about public and private members (no to mention protected)? Data hiding is a fundamental concept in computer programming and public, private and protected are just C++’s (and some other language's) expression of this concept. “Hooks” is my terminology; there is nothing inelegant: if you want a particular aspect of a function to be customised by a derived class you factor it into a virtual function which can then be overridden. This pattern is used in C++'s iostream library. “Crap” you say? If I wanted to find crap I’d visit here[^].
Steve
|
|
|
|
|
|
I don't want to get into a pointless flame war, but still I can't resist one last comment on the following:
The Grand Negus wrote: Technobabble. I think you guys like this stuff to be obscure.
It seems to me you like to "buck the system", so to speak. You're frequently rubbishing existing best practice. Most fields have their own jargon: the people involved generally consider this a simplifying factor rather than the opposite.
Steve
|
|
|
|
|
The Grand Negus wrote: Is "anterior" better than "front"? Is "podiatrist" clearer than "foot doctor"? Is "bi-directional communication link" an improvement over "two-way radio"?
Must you apply layman's terms to everything in everyones chosen career fields?? For the layman, yes, one is better than the other. For the people working in those chosen fields, no, they're not. The layman's terms are more ambiguous.
Just because you think everything is wrong with the world doesn't make it so for the rest of us.
The Grand Negus wrote: My 2006 Chevy has almost twice as many parts as my 1964 Cadillac but is not significantly better in any way.
I'm willing to bet, even with more complexity and parts, statistically, it's more reliable and safer. So, depending on your definition of "better", yes and no, it is "significantly better in any way".
|
|
|
|
|
For you maybe, but most of this is subjective. And you are finding that many of us actually enjoy it.
So, why insist on pissing on our parade? Oh right, you're not talking with us really you're attempting to reach the silent ones. Sorry, I forgot you have you're own agenda.
How does it help someone who is seeking help with his CURRENT design issue with a language that he HAS to use at his JOB by telling him OOP is POOP and English is the way!??? How does that help this person, who's thread you are hijacking with PE pushing?
This statement was never false.
|
|
|
|
|
Stephen Hewitt wrote: This is in C++. I'm no C# expert so I'm not sure how much of this will cleanly translate.
It's the same in C#
Also the non-virtual method usualy does all the parameter checking etc, so you don't need to duplicate it in derived classes.
"Throughout human history, we have been dependent on machines to survive. Fate, it seems, is not without a sense of irony. " - Morpheus
"Real men use mspaint for writing code and notepad for designing graphics." - Anna-Jayne Metcalfe
|
|
|
|
|
Stephen Hewitt wrote: One pattern you may be interesting in is the following:
This looks like the Template[^] design pattern. I'm glad you brought this up as I think it's a superior way of approaching the problem I described. Thanks.
(My C++ is rusty, but I think the virtual methods should have protected access rather than private, no?)
|
|
|
|
|
If you don't want the derived class to be able to call the base class implementation private is best as any attempt to call it will result in a compiler error. private doesn’t mean you can’t override the method in a derived class, you just can’t call the method in the base class from the derived class. Again, this is in C++, but I think it will be the same in C#.
Steve
|
|
|
|
|
So what? He still has to do his work. You aren't offering anything viable here for someone with a job to do.
This statement was never false.
|
|
|
|
|
A good example of this is in MFC where you can override some of the message functions, but might still call the base to get its bits. But again, I'd say this would be better for optional cases.
This statement was never false.
|
|
|
|
|
Just a thought,
If you override a virtual function in class inherited from a standard control, does that not by default inclde a call to the base function??
|
|
|
|
|
Yea, sorry, slip of the post there
|
|
|
|
|
pprice wrote: If you override a virtual function in class inherited from a standard control, does that not by default inclde a call to the base function??
It depends. If you write the code by hand, it's entirely up to you to add the code that calls the base class method. If you rely on intellisense, it creates the overriden method that includes a call to the base class method.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
