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 4 years ago.
Improve this question
I am confused with these implementations .In an interview,interviewer asked me what is composition and I gave him typical definition then I wrote this part of code for him.
public class Foo {
private Bar bar = new Bar();
}
But he claimed this implementation is correct
interface IFoo
{
int DoSomthing();
}
class Bar : IFoo
{
public int DoSomthing()
{
throw new NotImplementedException();
}
}
Which one is correct?
Edit: I realize now that both you and your interviewer were correct; answer updated accordingly.
From the wikipedia page on Composition over inheritance:
Composition over inheritance...is the principle that classes should achieve polymorphic behavior and code reuse by their composition (by containing instances of other classes that implement the desired functionality) rather than inheritance from a base or parent class.
Polymorphism is
the provision of a single interface to entities of different types.
So what you did (having Bar be a property of Foo) is Composition because Bar has an instance of Foo through having it as a property.
What your interviewer did was also Composition because, through the interface IFoo, Bar implements the same functionality, and it didn't use inheritance to do so. This appears to be the way it's documented on the linked wiki page but doesn't mean your way is wrong either.
Which method you use for implementing the same functionality in different places would depend on whether it makes sense for Bar to be a property of Foo or not.
Composition denotes a "is-a-part-of" relationship between objects. For example,
class Engine
{
//....
}
class Car
{
Engine engine = new Engine();
//.....
}
we can see, Engine is-a-part-of Car. Composition and inheritance are two different concepts and you probably shouldn't accept a job offer where he would be your boss. :)
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 9 months ago.
Improve this question
I'm working on an app which uses the Factory pattern to create new objects. In the Factory Class I've added a new Private method called SendApprovalEmail() and I am calling this from within the Process() method.
There are other Factory classes which will have their own implementation of SendApprovalEmail(). Therefore should I make an interface (containing a SendApprovalEmail() method) which these factory classes can inherit from? Or is it an acceptable approach to have a private method on each factory class which is just called from their Process() method?
Looking around the app, they tend to use interfaces when extending the factory classes. Unsure what the pros and cons of this are?
I would not put this in an interface. This would be a good situation to use a protected virtual function — if this method is intrinsic to your factory design (i.e. should be included in all factory classes) rather than just part of this particular factory implementation.
The reason for my suggestion is that you say the function is private. You wouldn’t usually put private methods in an interface.
If it really is private then that would suggest that it is not going to be defined in a similar way for other factories I.e. it is just part of this particular factory’s implementation.
However you other comments sound like it is going to also be a necessary part of the design for other factories. In that case you would make it virtual (or abstract) protected so that it can be redefined in other factory classes.
A private member makes no sense as part of an interface. An interface is there to define a set of methods, a role, an object must always implement. Private methods, on the other hand, are implementation details, not intended for public consumption.
I agree with #sjb-sjb. Depending on what you want to accomplish an interface or abstract method would be way more appropriate. These two options would enforce implementation per class inheritance. An abstract method on a base class would offer far more flexibility. Yeah, but that method cannot stay private if you want to implement inheritance.
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 3 years ago.
Improve this question
I like the DI feature of ASP.NET Core, but am finding that some of my classes end up with huge constructor parameter signatures...
public class Foo {
private IBar1 _bar1;
private IBar2 _bar2;
// lots more here...
public Foo(IBar1 bar1, IBar2 bar2, lots more here...) {
_Bar1 = bar1;
_Bar2 = bar2;
// ...
}
public DoSomething() {
// Use _bar1
}
}
In case this looks like a code smell, it's worth pointing out that any controller is going to use AutoMapper, an email service and 2 or 3 managers related to ASP.NET Identity, so I have 4 or 5 dependencies before I start injecting a single repository. Even if I only use 2 repositories, I can end up with 6 or 7 dependencies without actually violating any SOLID principles.
I was wondering about using a parameter object instead. I could create a class that has a public property for every injected dependency in my application, takes a constructor parameter for each one, and then just inject this into each class instead of all the individual Bars...
public class Foo {
private IAllBars _allBars;
public Foo(IAllBars allBars) {
_allBars = allBars;
}
public DoSomething() {
// Use _allBars.Bar1
}
}
The only disadvantage I can see is that it would mean that every class would have every dependency injected into it via the parameter object. In theory, this sounds like a bad idea, but I can't find any evidence that it would cause any problems.
Anyone any comments? Am I letting myself into potential trouble by trying to make my constructor code neater?
What you're describing sounds like the service locator pattern, and while it seems tempting to simplify your code by eliminating all those constructor parameters, it usually ends up hurting maintainability in the long run. Check out Mark Seemann's post Service Locator violates encapsulation for more details about why it should be avoided.
Generally, when you find yourself with a class with dozens of constructor parameters, it means that class might have too many responsibilities. Can it be decomposed into a number of smaller classes with narrower goals? Rather than introducing a "catch-all" class that knows about everything, maybe there's a complex part of your application that you can abstract behind a facade.
Sometimes, you do end up with large coordinator classes that have many dependencies and that's okay in certain circumstances. However, if you have many of these it's usually a design smell.
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 5 years ago.
Improve this question
Imagine we have an interface like below:
public interface ISome
{
void MethodOne();
int MethodTwo();
string MethodThree();
}
A class implements the interface:
public class Some : ISome
{
// Implementation...
}
Here is how it may be used:
public class App
{
public App(ISome)
{
// This class needs the whole interface: All three methods
}
}
I have a new requirement and it only needs one method from it: MethodThree and it can use the implementation provided by Some. Now I have 2 options:
Use ISome in the new class, like App uses it. The problem with this is that the new class does not really depend on the whole interface but only one method.
Split the interface like this using inheritance:
public interface INewSome
{
string MethodThree();
}
public interface ISome : INewSome
{
void MethodOne();
int MethodTwo();
}
The benefits of the 2nd option are:
The new class will depend on INewSome
Some still implements the whole interface so existing code will not break.
Unit testing will be much clearer since we know we just need to mock/stub one method in INewSome
Questions
I cannot think of a benefit for option 1 aside from not having to introduce a new interface. Do you know of a benefit with option 1?
Do you have another suggestion?
Am I overlooking anything and is this good/bad design?
what you have done in the option 2 is correct and goes perfectly with the fourth goal which is Interface Segregation Principle
From Wikipedia many client-specific interfaces are better than one general-purpose interface
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 9 years ago.
Improve this question
I have an interface:
public interface IMyObject
{
}
I have an abstract class:
public abstract class MyObject : IMyObject
{
}
And I have a class:
public class MyExtendedObject : MyObject
{
}
There are many interfaces, abstracts and concretes like this in my project. I wonder what is the best scenario to organize the code in namespace (folders in project) point of view. Should I put all related stuff under the same folder or should create, for example a Base namespace for abstract classes, Interfaces namespace for interfaces and another namespace for extended objects?
The best way is subjective and poject dependent.
Like a suggession I would say:
move in separate folder interfaces and abstract classes, so separate them from concrete implementation classes.
+ Absrtacts
-> IMyObject.cs
-> MyObject.cs
+ Concrete
-> MyExtendedObject.cs
Robert C. Martin (one of the founding fathers of Agile and now the Software Craftmanship movement) has a whole talk on that that is really worth watching
It's based on Ivar Jacobson's Object Oriented Software Engineering: A Use Case Driven Approach.
To summarize it in a few sentences, your project structure should reflect what it models and not the technology or particular language constructs you use. In the case of your abstract/interface/concrete classes this means that using a structure where you put all your abstract classes in a folder/namspace/assembly, your concrete classes in another folder/namespace/assembly is not the way to go (even though it is very common to find projects where this approach is taken).
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 9 years ago.
Improve this question
I have several classes that all implementing an interface:
interface ISample
{
}
class A:ISample
{
}
class B:ISample
{
}
class C:ISample
{
}
and another class that create them based on some situation for example:
class CreateISample
{
ISample Create(string situation )
{
switch(situation )
{
case "create A":
return new A();
case "Create B":
return new B();
case "Create C":
return new C();
}
}
}
What is the best name for this class?
Create ISample is not good, as then I have:
CreateISample.Create("Create A");
which has two Create as part of name. Also CreateISample may do some other things (for example hold some constant values that relates to all instances, or hold a list of created instances and so on). Then CreateISample is not a good name.
Is there any standard for this? I remember that I read a book about design patterns and they suggested a suitable name for this factory pattern.
you are describing the factory pattern http://en.wikipedia.org/wiki/Factory_method_pattern
generally the convention we use is SampleFactory
But don't overthink it. It's really hard to make names like this from samples. for example it is obvious to most people that a square inherrits from shape. so
ShapeFactory.Create("Square");
would make a lot of sense. so look at your problem to see what kind of thing ISample really is. If i makes sense from a business/problem side other programmers who understand the problem can figure it out.