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).
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 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. :)
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 6 years ago.
Improve this question
I want to learn how to make layered architecture correctly. For that I need an advice.
For example project I started to write news website. I layered my project:
Is it best to do that? I'll do that angular (in web project).
And one more. Should I make one more layer for Dependency injection?
I would not call it NewsWebSite.BLL because it sounds like the BLL can only be used for web applications.
I would have it like this. If the company name is Contoso:
// This is where you can put all your common code.
// I do not mean cross cutting concern here. By common I mean if you have
// some contstants or enums that are shared by all Dlls
Contoso
Contoso.Business
Contoso.Api
Contoso.WebApp
Contoso.Data
// The name of test projects are exactly the same as the name of the
// assembly but has the word "Tests" at the end
Contoso.Business.Tests
Contoso.Api.Tests
Furthermore, see the Pascal Casing naming convention I am using. This way I do not have to deal with Contoso.BLL.SomeClass.
Also, my Contoso.Business.Tests will reside in a namespace that matches my Contoso.Buiness namespace. Here is a class in Contoso.Business:
public namespace Contoso.Business
{
public class Foo
{
}
}
The test for that class, I would not put it into Contoso.Business.Tests namespace (I am not talking about the DLL). I would make my test class which is testing Foo like this:
// See the namespace here, I am not using Contoso.Business.Tests
public namespace Contoso.Business
{
// The name of the class is identical to the name of the class being tested but the word "Tests" appended
public class FooTests
{
}
}
That way they share the same namespace and I can relate them easily.
I use often that architectural structure. In the same situations, meaning webAPI and angular.
But it's important that you considerate all the need in your project, including it's dimension. Ex: if you don't really have the need to manage Logic of business, using a BLL may just no be relevant.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I reading some code written by some other programmer, He made some design for application, application classes derived each other like that:
public interface IABase
{
}
class BBase : IABase
{
}
class CDesktop : BBase
{
}
class Report : CDesktop
{
}
class Sample : Report
{
}
This kind of design is anti pattern? I have to tell first, its realy hard to understand relationship of class and logic of application, this is my 2 cents. What else you can say?
There's a bit of general advice floating around to prefer composition over inheritance. The advantage often touted are that it's more flexible, and discourages tight coupling more. (see where-does-this-concept-of-favor-composition-over-inheritance-come-from, DeepClassHierarchies, deep-class-inheritance-hierarchy-bad-idea, long-inheritance-hierarchy amongst many others for discussions on this matter).
Specifically for C#, it's worth noting that composition can require considerable boilerplate - after all, if you want to expose much of the functionality of the component/base-class, then you'll need to manually expose that; inheritance (by contrast) makes it very easy to just expose everything.
It's probably a good idea to use inheritance sparingly when in doubt because it's easy to create lots of tightly coupled spagetti-monsters otherwise. But there are cases where classical dynamic dispatch and all that is wanted; and there are also cases where even though your concepts better map to a has-a relationship than an is-a relationship the wordiness of composition is a considerable burden.
So while this kind of code is harder to maintain, it might still be worth it on occasion. Your specific example looks like the hierarchy is unnecessarily deep; however, it's normal for old code to grow a few warts - if this is the worst of it, consider yourself lucky.
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.