It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
I came across one issue as to how to package interface, interface client and inheritance. That is, in the book below, author mentioned that Switachable is more appropriate to deploy with Switch together as a component, rather than Light.
What I want to understand is the reasoning behind it (Both Switch and Switchable are packaged in one component, rather Switchable and Light) , and example if possible.
I think there are cases where both scenarios are valid. One example that is oppoiste of that design is, IStream, FileStream are in one component, ISream client is in another component.
Below is from unclebob's agile in C# ch 33, p497.
Since Light inherits from Switchable, it could also be deployed with Switchable - it seems, however, due to the naming, that the primary class interacting with the Switchable interface will be Switch - which means that the two are tightly-coupled: you should never put tightly-coupled class/interface definitions in separate assemblies.
You could also conceive of other Switchable classes, such as Outlet or a whole set of Appliances. These could be added at a later date, and they would have nothing to do with Light, meaning that Light and Switchable aren't necessarily part of the same component. However, the Switch class would still apply to these new classes and would apply.
(It is true that a different consumer of the Switchable interface could be conceived, but it would likely be an awkward adaptation, such as a ToggleButton that toggled the on/off state by remembering the last method called. However, with the names chosen, Switchable still implies that a Switch could be involved.)
I hope this answers your question.
Related
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I have read that reflection is particularly useful when dealing with plugins. Could someone kindly highlight the benefits in this particular situation? Both in C# or Java.
"At the highest level of abstraction, the host application must be able to load plug-ins and then communicate with plug-ins to take advantage of their designed services. Both of these tasks can be implemented in different ways depending on a developer’s choice of language and platform. If the choice is C# and .NET, then reflection can be used for loading plug-ins, and interfaces or abstract classes can be used as a means for generic communication."
If you Google some of that you can see the article and read some more on it.
Why don't you just Google it?
In case of .NET you can use an interface to create a basic layout of a plugin. Let's call it 'IPlugIn'. Then you load an Assembly with a class implementing IPlugIn. Now you can look through all the types if one is derived by IPlugIn or define Attributes on the assembly to indicate which class is a plugin.
In my opinion you do not need to rely on reflection for plugin implementation. I'd suggest using usual interfaces and services. Define some interfaces for your plugins to implement and let them consume the services that will help them integrate with the framework you want to provide them.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I have some source code in C# that lies in a number of folders.
I need to understand this code as it wasn't written by me. Not only that, I want to learn how enterprise applications are coded. The best way to do that is if I have a graphical representation of classes, inheritance etc. I should be able to see the source code in multiple layers: e.g how classes relate to each other, how properties/methods in these classes relate and call each other, etc. I've heard of enterprise architecture and checked it out, but I don't understand what I've read.
Can anyone suggest something else?
Have you looked at NDepend? It can show you all the dependencies withing the code - eg through graphs;
http://www.ndepend.com
Simply use Microsoft Debug Canvas to get acquainted with the solution.
If you are using Visual Studio right click on project and choose "View Class Diagram".
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I have an utility library with the class ConsoleApp, which has only static method like GetIntValue(string name) to ask user to enter the integer value of the parameter with specified name, or functions to parse command line parameters.
As for me ConsoleApp is an utility class, and inheriting it just to get avoid "ConsoleApp." in the code looks like BaseBeen anti-pattern.
But on the other side, ConsoleApp will be inherited only by the classes that is really Console applications, in this way, it's not a BaseBeen.
So, is it really BaseBeen?
SOLID design principles (particularly SRP, O/CP, and DIP) suggest that you're better providing that functionality via delegation (e.g. strategy pattern). Has-A is better than Is-A, etc.
However, you're pretty squarely in first-world-problems territory here because Program.cs is very much on the transient end of your codebase. Clearly you might need to parse some command line parameters before your bootstrapper runs (e.g. to configure your bootstrapper!), so you might find it challenging to inject some kind of value provider.
So, I'd say yes it's an antipattern, however there are probably more important things to worry about.
See e.g. http://s3.amazonaws.com/hanselminutes/hanselminutes_0145.pdf page 8 where Uncle Bob talks about DIP:-
"Main is the most concrete of our
functions and it will create all of our instances and all of the
factories ... and it will then
hand off to the abstract part ... and the
abstract core will manipulate it as though it were in this fantasy
world where everything was abstract."
If Main has to call some static methods, that's ok. If you want to inherit from a utility class to make it easier for you, that maybe smells a bit but I don't really care. Just make sure you know where the boundary is. If you're using your static utility class outside of Main then you're likely to have a problem.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
What is the use of interface in projects except the use of loosely coupling?
Does it reduce memory usage while passing it as argument?
Please list the advandages deeply.
I think you should have look to oop example and specially Design pattern whihc help you to understand why to use interface..
Another important advantage to programming to interfaces is that it provides a means for polymorphism. If I have a collection of IShape and IShape provides a CalculateArea() method, I can supply a new shape to the project by adding a new implementation of IShape. So, yes, this is providing looser coupling by virtue of adhering to the open/closed principle. But, it's also allowing IShape to be treated abstractly by clients without needing to know which specific IShape it is.
Polymorphism is fundamental to object oriented design, and an interface is a way to achieve that (the other being inheritance).
I'd also throw in that interface implementation tends to be expressive in terms of code intentions. If I have some declaration like:
public class Foo : IDisposable, IPersistMyselfToDisk, IRaiseUpdateEvents
I can tell a lot about the class and what it does at a glance -- more so than I could if I simply buried that functionality somewhere in the details of the class. Again, this goes back to decoupling to some degree, but it stands on its own as well.
I think you're going to find that decoupling is wrapped up with just about all advantages of using interfaces since providing classes that are cohesive and loosely coupled is just about as fundamental to OOP as having classes with state and behavior.
It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
i want the ability to create a UI designer (Winforms/WPF/UI/User interface type agnostic).
The requirment is that it should be possible to add properties to a device and it should automatically turn up in the UI.The addition of properties would be via a admin screen.
eg. there is a UI object called Order.It should be possible to add a property called ordersoomething to the order object from the admin screen and it should automatically reflect in the User interface.
i am looking for something that is already available (Open Source/existing stuff etc).
Edit based on a couple if comments.
What i mean by UI agnostic is that i am looking for a architectural pattern. That would fit well.it should not matter if it is Webforms or Silverlight or Winforms.
Regards
David Xavier
Since you tagged this C#, make sure you know about VS LightSwitch
There is a DevExpress Application Frameowrk, something called XAF, see the Developer Express website, it's not for free but not too expensive considering what you are asking, I am not sure if it only targets WindowForms...