Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Recently I have been asked in an Interview that: "Can you give an example of a situation where is it necessary to break the Inheritance chain?". I am not very sure if I could follow the question exactly.
Does any such situation exist when we to break the inheritance chain?
I tried google, but didn't get any clues.
A. When we get stupid questions that make no sense.
Inheritance is just a tool for managing and re-using code. Composition is a strong tool that is not part of an "inheritance-chain" so I'm guessing that's an answer they're looking for?
Another possible answer they're looking for is utilizing interfaces. As interfaces don't require an "inheritance chain". They enable you to be a little more flexible with your architecture and step away from strict inheritance "chains".
However the question implies that you have a number of objects that all inherit from one another and for some reason you "break" the chain of inheritance somewhere. There is no "set" reason why you'd do this as each implementation of OOP that addresses a problem is typically unique.
The way the interviewer phrased the question makes little to no sense. It's a bad interview question that wont result in the best answers or necessarily tell you anything about a candidate except that they don't understand your madness either ;).
EDIT: added some "better" questions.
Better questions include:
Q. What is the difference between inheritance and composition?
Q. I have the following class model (one crying out for an interface), can I improve it at all?
Q. I'm re-designing a base class and want to prevent other people from overriding this function. Can I do that?
Q. Is there a problem with calling virtual methods in class constructors, if so, what?
There's this blog post with a good explanation on why you'd want to "break the inheritance chain" (or "seal" your class).
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I explored c# source code reference. And I came across with interesting mention of IArithmetic<T> interface. For example, Int32, Double contain commented implementations of IArithmetic interface. I am interested by these details. As I understood, it is attempt to add "supporting" of arithmetic operations. But why are they commented? Is it bad way to add supporting generic "operators"?
It was probably scrapped due to performance reasons and not very much usability.
Primitive types supporting arithmetic operations through an interface is really not a very attractive scenario; performance would be horrible compared to simply using the value type itself due to the necessary boxing and unboxing.
What possible uses? Well, the first one to spring to mind would be the following scenario:
public Matrix<T> where T: IArithmetic<T>
or some such. Although this could be interesting, due to performance reasons, it would probably need to be solved some other way, not through interfaces; read this for very educated musing on the subject.
On top of all that, if you really need something similar to Arithmetic<T> you can always build your own with an added level of indirection.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
If I've some common functionality that I've to keep in a class, so will I go for static, sealed or abstract class...Does all these types of classes serve the purpose of keeping the common functionality together...where actually the difference lies when I've to go for one
abstract, sealed, static has nothing to do with real time development. It has to do with bring structure within your software, so that the functionality implemented in classes can and should be used in the right way.
After some comments i think this:
I think you can only learn this, by doing it. There isn't a book or epub that will explain you how to do programming. They will show the syntax and some examples. It will be trial and error. Every day you'll face a new challenge.
You'll have to practice it. The best advise is, look what others already created and try to imagine why did they wrote/solve it that way.
I can explain what a static/sealed/abstract class is/does, but it doesn't learn you when to use it.
Back to the question: Define 'real time'.. I think that static/abstract/sealed should NOT be decisive on how you write your 'real-time' software. If you are 'scared' about performance on this level, C# should not be your choise. I would write c++ or if you want a real challenge, try to beat the compilers with asm ;-)
I think you won't measure the 'overhead'
So, use abstract/static/sealed in a right way, so your future collega's/you can read/maintain it.
I use C# for communication (tcp/ip) between a windows computer and a PLC (with delta robots). But it's far from realtime. It's fast enough to keep many robot working with > 100 messages per second.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
The project I work on has multiple layers and each layer's object is being used in the subsequent layer. But some of the classes do not have any interfaces and have non virtual methods. So basically I will not be able to use a mock framework to stud those classes from other layers. When I asked the developer to create an interface for the same class, so that I can mock it, he asked me why should I create an interface if I am not going to reuse it.
Is it a good practice to write interface just to improve the testability of the code?
Your code should be loosely coupled and has good dependency management to allow you write unit-tests easily. If you can't write unit-tests easily, it's the first sign that your code is not well-architectured enough, and you need to refactor it. So, your motivation to change production code(in your case to add Interface) should be to make your code better, not just to aid testing. If you could do the first - you would get the second for free.
Btw, one of the main benefits of following the TDD practice is that the good architecture is enforced from the beginning: it's difficult to write untestable code, because you write tests before you write code.
So, the answer is YES, it's OK to add Interface, but it should be done for the sake of good architecture, not just to help you write tests for bad architecture.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm not really sure, when I should consider not use reflection.
At the moment I struggling with the following scenario:
A mapping between two classes are done by reflection (with dictionary to property).
In one class we have a dictionary<string, object> and in the other class we have properties with the same name as the key of the dictionary. Then I sue reflection to get the property and set it.
You see, there are also costly castings of all the objects. And sometimes I must do a custom cast, because the types are diffrent..
The only big advantage of the reflection is the 'easy' mapping with few lines and less classes. Both Reflection and the normal property set approach is possible.
NOTE: My question is more from the perspective of design, rather of 'how to' solve the problem.
It would be appreciated if you can give me some advices.
My question is more from a perspective of design, rather of how to solve the problem
To answer your question, in general you would use Reflection to do dynamic property mappings like this. However, in practise Reflection can be heavy & slow (as you are beginning to notice). As you have probably guessed this problem is pretty common and there are already libraries out there that do all the heavy lifting for you e.g. AutoMapper.
As far as mapping a Dictionary to an object is concerned, I have never used AutoMapper for something like that therefore I couldn't comment on whether it would support it or not (my guess it it probably could, it's pretty flexible). If your Dictionary is just a bridge for your custom mapping then if you did switch to using AutoMapper you could get rid of this completely.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I like design patterns very much, but I find it difficult to see when I can apply one. I have read a lot of websites where design patterns are explained. I do understand the most of them, but I find it difficult to recognize a pattern in my own situations.
So, that is why I ask this question. Are there any guidelines / alarm bells when to use which design pattern.
For example, if you are doing a switch statement to determine which object you need to create, you probably want to use the factory design pattern. So the switch statement in this case is a 'alarm bell' to use the Factory pattern.
So, do you know more 'alarm bells' to determine a design pattern?
Usually the process is the other way around. Do not go looking for situations where to use design patterns, look for code that can be optimized. When you have code that you think is not structured correctly. try to find a design pattern that will solve the problem.
Design patterns are meant to help you solve structural problems, do not go design your application just to be able to use design patterns.
Learn them and slowly you'll be able to reconize and figure out when to use them. Start with something simple as the singleton pattern :)
if you want to create one instance of an object and just ONE. You use the singleton pattern. Let's say you're making a program with an options object. You don't want several of those, that would be silly. Singleton makes sure that there will never be more than one. Singleton pattern is simple, used a lot, and really effective.
I completely agree with #Peter Rasmussen.
Design patterns provide general solution to commonly occurring design problem.
I would like you to follow below approach.
Understand intent of each pattern
Understand checklist or use case of each pattern
Think of solution to your problem and check if your solution falls into checklist of particular pattern
If not, simply ignore the design-patterns and write your own solution.
Useful links:
sourcemaking : Explains intent, structure and checklist beautifully in multiple languages including C++ and Java
wikipedia : Explains structure, UML diagram and working examples in multiple languages including C# and Java .
Check list and Rules of thumb in each sourcemakding design-pattern provides alram bell you are looking for.