Search Results

Search found 3061 results on 123 pages for 'interfaces'.

Page 1/123 | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >

  • Should interfaces inherit interfaces

    - by dreza
    Although this is a general question it is also specific to a problem I am currently experiencing. I currently have an interface specified in my solution called public interface IContextProvider { IDataContext { get; set; } IAreaContext { get; set; } } This interface is often used throughout the program and hence I have easy access to the objects I need. However at a fairly low level of a part of my program I need access to another class that will use IAreaContext and perform some operations off it. So I have created another factory interface to do this creation called: public interface IEventContextFactory { IEventContext CreateEventContext(int eventId); } I have a class that implements the IContextProvider and is injected using NinJect. The problem I have is that the area where I need to use this IEventContextFactory has access to the IContextProvider only and itself uses another class which will need this new interface. I don't want to have to instantiate this implementation of IEventContextFactory at the low level and would rather work with the IEventContextFactory interface throughout. However I also don't want to have to inject another parameter through the constructors just to have it passed through to the class that needs it i.e. // example of problem public class MyClass { public MyClass(IContextProvider context, IEventContextFactory event) { _context = context; _event = event; } public void DoSomething() { // the only place _event is used in the class is to pass it through var myClass = new MyChildClass(_event); myClass.PerformCalculation(); } } So my main question is, would this be acceptable or is it even common or good practice to do something like this (interface inherit another an interface): public interface IContextProvider : IEventContextFactory or should I consider better alternatives to achieving what I need. If I have not provided enough information to give suggestions let me know and I can provide more.

    Read the article

  • Should interfaces extend (and in doing so inherit methods of) other interfaces

    - by dreza
    Although this is a general question it is also specific to a problem I am currently experiencing. I currently have an interface specified in my solution called public interface IContextProvider { IDataContext { get; set; } IAreaContext { get; set; } } This interface is often used throughout the program and hence I have easy access to the objects I need. However at a fairly low level of a part of my program I need access to another class that will use IAreaContext and perform some operations off it. So I have created another factory interface to do this creation called: public interface IEventContextFactory { IEventContext CreateEventContext(int eventId); } I have a class that implements the IContextProvider and is injected using NinJect. The problem I have is that the area where I need to use this IEventContextFactory has access to the IContextProvider only and itself uses another class which will need this new interface. I don't want to have to instantiate this implementation of IEventContextFactory at the low level and would rather work with the IEventContextFactory interface throughout. However I also don't want to have to inject another parameter through the constructors just to have it passed through to the class that needs it i.e. // example of problem public class MyClass { public MyClass(IContextProvider context, IEventContextFactory event) { _context = context; _event = event; } public void DoSomething() { // the only place _event is used in the class is to pass it through var myClass = new MyChildClass(_event); myClass.PerformCalculation(); } } So my main question is, would this be acceptable or is it even common or good practice to do something like this (interface extend another an interface): public interface IContextProvider : IEventContextFactory or should I consider better alternatives to achieving what I need. If I have not provided enough information to give suggestions let me know and I can provide more.

    Read the article

  • Understanding interfaces [closed]

    - by user985482
    Possible Duplicate: When to use abstract classes instead of interfaces and extension methods in C#? Why are interfaces useful? What is the point of an interface? What other reasons are there to write interfaces rather than abstract classes? What is the point of having every service class have an interface? Is it bad habit not using interfaces? I am reading Microsoft Visual C# 2010 Step by Step which I feel it is a very good book on introducing you to the C# language. I have just finished reading a chapter on interfaces and although I understood the syntax of creating and using interfaces I have trouble of understanding the point on why should I use them? Correct me If I am wrong but in an interface you can only declare methods names and parameters.The body of the method should be declared in the class that inherits the interface. So in this case why should I declare an interface if I am going to declare the entire method in the class that inherits that interface? What is the point? Does this have something to do with the fact that a class can inherit multiple interfaces?

    Read the article

  • Design Patterns - Why the need for interfaces?

    - by Kyle Johnson
    OK. I am learning design patterns. Every time I see someone code an example of a design pattern they use interfaces. Here is an example: http://visualstudiomagazine.com/Articles/2013/06/18/the-facade-pattern-in-net.aspx?Page=1 Can someone explain to me why was the interfaces needed in this example to demonstrate the facade pattern? The program work if you pass in the classes to the facade instead of the interface. If I don't have interfaces does that mean

    Read the article

  • Instantiating Interfaces in C#?

    - by RealityDysfunction
    I am reading/learning about interfaces in C# at the moment, and thus far I managed to understand how it differs from an abstract class. In the book I am reading the author explains that interfaces are the ultimate abstract class and that it simply sets the standard of certain methods the inheriting class will have, but then provides the following example... static void Main(string[] args) { ... Circle c = new Circle("Lisa"); IPointy itPt = null; try { itPt = (IPointy)c; Console.WriteLine.(itPt.Points); } catch (InvalidCastException e) { Console.WriteLine(e.Message); } ... } The line that absolutely throws me off is the "IPointy itfPt=null;" did he just declare an interface??? I thought interfaces are abstract and can only be inherited? What kind of sorcery is going on here? Thanks for any help, I

    Read the article

  • Why are interfaces useful?

    - by Pankaj Upadhyay
    I have been studying and coding in C# for some time now. But still, I can't figure the usefulness of Interfaces. They bring too little to the table. Other than providing the signatures of function, they do nothing. If I can remember the names and signature of the functions which are needed to be implemented, there is no need for them. They are there just to make sure that the said functions(in the interface) are implemented in the inheriting class. C# is a great language, but sometimes it gives you the feeling that first Microsoft creates the problem (not allowing multiple inheritance) and then provides the solution, which is rather a tedious one. That's my understanding which is based on limited coding experience. What's your take on interfaces? How often you make uses of them and what makes you do so?

    Read the article

  • What are the differences between abstract classes, interfaces, and when to use them

    - by user66662
    Recently I have started to wrap my head around OOP, and I am now to the point where the more I read about the differences between Abstract classes and Interfaces the more confused I become. So far, neither can be instantiated. Interfaces are more or less structural blueprints that determine the skeleton and abstracts are different by being able to partially develop code. I would like to learn more about these through my specific situation. Here is a link to my first question if you would like a little more background information: What is a good design model for my new class? Here are two classes I created: class Ad { $title; $description $price; function get_data($website){ } function validate_price(){ } } class calendar_event { $title; $description $start_date; function get_data($website){ //guts } function validate_dates(){ //guts } } So, as you can see these classes are almost identical. Not shown here, but there are other functions, like get_zip(), save_to_database() that are common across my classes. I have also added other classes Cars and Pets which have all the common methods and of course properties specific to those objects (mileage, weight, for example). Now I have violated the DRY principle and I am managing and changing the same code across multiple files. I intend on having more classes like boats, horses, or whatever. So is this where I would use an interface or abstract class? From what I understand about abstract classes I would use a super class as a template with all of the common elements built into the abstract class, and then add only the items specifically needed in future classes. For example: abstract class content { $title; $description function get_data($website){ } function common_function2() { } function common_function3() { } } class calendar_event extends content { $start_date; function validate_dates(){ } } Or would I use an interface and, because these are so similar, create a structure that each of the subclasses are forced to use for integrity reasons, and leave it up to the end developer who fleshes out that class to be responsible for each of the details of even the common functions. my thinking there is that some 'common' functions may need to be tweaked in the future for the needs of their specific class. Despite all that above, if you believe I am misunderstanding the what and why of abstracts and interfaces altogether, by all means let a valid answer to be stop thinking in this direction and suggest the proper way to move forward! Thanks!

    Read the article

  • Interfaces, Adapters, exposing business objects via WCF design

    - by Onam
    I know there have been countless discussions about this but I think this question is slightly different and may perhaps prompt a heated discussion (lets keep it friendly). The scene: I am developing a system as a means for me to learn various concepts and I came across a predicament which my brain is conflicting with. That is whether to keep my interfaces in a separate class library or should they live side by side my business objects. I want to expose certain objects via WCF, however refuse to expose them in its entirety. I am sure most will agree exposing properties such as IDs and other properties is not good practice but also I don't want to have my business objects decorated with attributes. The question: Essentially, I'll be having a separate interface for each of my objects that will essentially be exposed to the outside world (could end up being quite a few) so does it make sense to create a separate class library for interfaces? This also brings up the question of whether adapters should live in a separate class library too as ideally I want a mechanism from transferring from one object to the other and vice versa?

    Read the article

  • What problems will I face if I remove the concept of interfaces from my code?

    - by Vishwas Gagrani
    I have been programming for many years but I am still not comfortable with the concept of "Interfaces". I try to use interfaces but many times I don't see a mandatory use for it. I think this is probably because the projects weren't so big, or because interfaces are more useful when teamwork is involved. So, making another attempt to understand the importance of interfaces, here is my question: What problems will I face if I remove the concept of interfaces from my code?

    Read the article

  • Default vs Impl when implementing interfaces in Java

    - by Gary Rowe
    After reading Should package names be singular or plural? it occurred to me that I've never seen a proper debate covering one of my pet peeves: naming implementations of interfaces. Let's assume that you have a interface Order that is intended to be implemented in a variety of ways but there is only the initial implementation when the project is first created. Do you go for DefaultOrder or OrderImpl or some other variant to avoid the false dichotomy? And what do you do when more implementations come along? And most important... why?

    Read the article

  • Naming interfaces for persistent values

    - by orip
    I have 2 distinct types of persistent values that I'm having trouble naming well. They're defined with the following Java-esque structure, borrowing Guava's Optional for the example and using generic names to avoid anchoring: interface Foo<T> { T get(); void set(T value); } interface Bar<T> { Optional<T> get(); void set(T value); } With Foo, if the value hasn't been set explicitly then there's some default value available or pre-set. With Bar, if the value hasn't been set explicitly then there's a distinct "no value" state. I'm trying to optimize the names for their call sites. For example, someone using Foo may not care whether there's a default value involved, only that they're guaranteed to always have a value. How would you go about naming these interfaces?

    Read the article

  • Interfaces on an abstract class

    - by insta
    My coworker and I have different opinions on the relationship between base classes and interfaces. I'm of the belief that a class should not implement an interface unless that class can be used when an implementation of the interface is required. In other words, I like to see code like this: interface IFooWorker { void Work(); } abstract class BaseWorker { ... base class behaviors ... public abstract void Work() { } protected string CleanData(string data) { ... } } class DbWorker : BaseWorker, IFooWorker { public void Work() { Repository.AddCleanData(base.CleanData(UI.GetDirtyData())); } } The DbWorker is what gets the IFooWorker interface, because it is an instantiatable implementation of the interface. It completely fulfills the contract. My coworker prefers the nearly identical: interface IFooWorker { void Work(); } abstract class BaseWorker : IFooWorker { ... base class behaviors ... public abstract void Work() { } protected string CleanData(string data) { ... } } class DbWorker : BaseWorker { public void Work() { Repository.AddCleanData(base.CleanData(UI.GetDirtyData())); } } Where the base class gets the interface, and by virtue of this all inheritors of the base class are of that interface as well. This bugs me but I can't come up with concrete reasons why, outside of "the base class cannot stand on its own as an implementation of the interface". What are the pros & cons of his method vs. mine, and why should one be used over another?

    Read the article

  • Two interfaces with identical signatures

    - by corsiKa
    I am attempting to model a card game where cards have two important sets of features: The first is an effect. These are the changes to the game state that happen when you play the card. The interface for effect is as follows: boolean isPlayable(Player p, GameState gs); void play(Player p, GameState gs); And you could consider the card to be playable if and only if you can meet its cost and all its effects are playable. Like so: // in Card class boolean isPlayable(Player p, GameState gs) { if(p.resource < this.cost) return false; for(Effect e : this.effects) { if(!e.isPlayable(p,gs)) return false; } return true; } Okay, so far, pretty simple. The other set of features on the card are abilities. These abilities are changes to the game state that you can activate at-will. When coming up with the interface for these, I realized they needed a method for determining whether they can be activated or not, and a method for implementing the activation. It ends up being boolean isActivatable(Player p, GameState gs); void activate(Player p, GameState gs); And I realize that with the exception of calling it "activate" instead of "play", Ability and Effect have the exact same signature. Is it a bad thing to have multiple interfaces with an identical signature? Should I simply use one, and have two sets of the same interface? As so: Set<Effect> effects; Set<Effect> abilities; If so, what refactoring steps should I take down the road if they become non-identical (as more features are released), particularly if they're divergent (i.e. they both gain something the other shouldn't, as opposed to only one gaining and the other being a complete subset)? I'm particularly concerned that combining them will be non-sustainable as soon as something changes. The fine print: I recognize this question is spawned by game development, but I feel it's the sort of problem that could just as easily creep up in non-game development, particularly when trying to accommodate the business models of multiple clients in one application as happens with just about every project I've ever done with more than one business influence... Also, the snippets used are Java snippets, but this could just as easily apply to a multitude of object oriented languages.

    Read the article

  • Cannot reset an network interfaces without a reboot

    - by yangchenyun
    I have edited the /etc/network/interfaces file and I use the sudo /etc/init.d/networking restart. After restart, the eth1 interfaces don't setup properly. I need a hard reboot to enable this configuration. Meanwhile the command line hints: Running /etc/init.d/networking restart is deprecated because it may not enable again some interfaces. Am I using the run command to restart network interfaces? auto eth1 iface eth1 inet static address 192.168.1.87 netmask 255.255.255.0 gateway 192.168.1.1

    Read the article

  • Ubuntu second static IP, ifconfig, /etc/network/interfaces

    - by Schmoove
    I would like to add a second static IP to my local Ubuntu 11.10 desktop machine and have it automatically available after rebooting. So far I am successfully using ifconfig to to temporarily set up an alias for my primary network interface: # ifconfig eth1:0 192.168.178.3 up # ifconfig eth1 Link encap:Ethernet HWaddr c8:60:00:ef:a3:d9 inet addr:192.168.178.2 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::ca60:ff:feef:a3d9/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:61929 errors:0 dropped:0 overruns:0 frame:0 TX packets:64034 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:45330863 (45.3 MB) TX bytes:28175192 (28.1 MB) Interrupt:42 Base address:0x4000 eth1:0 Link encap:Ethernet HWaddr c8:60:00:ef:a3:d9 inet addr:192.168.178.3 Bcast:192.168.178.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:42 Base address:0x4000 However, when I add the following to /etc/network/interfaces, the alias is not up and running as expected after a reboot: # vi /etc/network/interfaces auto eth1:0 iface eth1:0 inet static address 192.168.178.3 netmask 255.255.255.0 I would like to know what to configure to get this to work. As a side note, I am running gnome shell.

    Read the article

  • When to use abstract classes instead of interfaces and extension methods in C#?

    - by Gulshan
    "Abstract class" and "interface" are similar type of ideas, while interface being more abstract. One need of abstract classes was to provide method implementations for the derived classes. But in C#, that need has also been reduced by lately introduced extension methods. So, in C#, when should we use abstract classes instead of using interfaces and extension methods associated with the interface? And now, we can use 'Properties' in interfaces also. A notable example of interface+ extension methods is the Heavily used IEnumerable and it's helper methods. You use Linq and it's all by this extension methods!

    Read the article

  • Class inheriting from several Interfaces having same method signature

    - by Manish
    Say, I have three interfaces: public interface I1 { void XYZ(); } public interface I2 { void XYZ(); } public interface I3 { void XYZ(); } A class inheriting from these three interfaces: class ABC: I1,I2, I3 { // method definitions } Questions: If I implement like this: class ABC: I1,I2, I3 { public void XYZ() { MessageBox.Show("WOW"); } } It compiles well and runs well too! Does it mean this single method implementation is sufficient for inheriting all the three Interfaces? How can I implement the method of all the three interfaces and CALL THEM? I know it can done using explicit implementation but I'm not able to call them. :(

    Read the article

  • What did Rich Hickey mean when he said, "All that specificity [of interfaces/classes/types] kills your reuse!"

    - by GlenPeterson
    In Rich Hickey's thought-provoking goto conference keynote "The Value of Values" at 29 minutes he's talking about the overhead of a language like Java and makes a statement like, "All those interfaces kill your reuse." What does he mean? Is that true? In my search for answers, I have run across: The Principle of Least Knowledge AKA The Law of Demeter which encourages airtight API interfaces. Wikipedia also lists some disadvantages. Kevlin Henney's Imperial Clothing Crisis which argues that use, not reuse is the appropriate goal. Jack Diederich's "Stop Writing Classes" talk which argues against over-engineering in general. Clearly, anything written badly enough will be useless. But how would the interface of a well-written API prevent that code from being used? There are examples throughout history of something made for one purpose being used more for something else. But in the software world, if you use something for a purpose it wasn't intended for, it usually breaks. I'm looking for one good example of a good interface preventing a legitimate but unintended use of some code. Does that exist? I can't picture it.

    Read the article

  • Who extends interfaces? And why?

    - by Gangnus
    AFAIK, my class extends parent classes and implements interfaces. But I run across a situation, where I can't use implements SomeInterface. It is the declaration of a generic types. For example: public interface CallsForGrow {...} public class GrowingArrayList <T implements CallsForGrow> // BAD, won't work! extends ArrayList<T> Here using implements is syntactically forbidden. I thought first, that using interface inside < is forbidden at all, but no. It is possible, I only have to use extends instead of implements. As a result, I am "extending" an interface. This another example works: public interface CallsForGrow {...} public class GrowingArrayList <T extends CallsForGrow> // this works! extends ArrayList<T> To me it seems as a syntactical inconsistancy. But maybe I don't understand some finesses of Java 6? Are there other places where I should extend interfaces? Should the interface, that I mean to extend, have some special features?

    Read the article

  • Combinatorial explosion of interfaces: How many is too many?

    - by mga
    I'm a relative newcomer to OOP, and I'm having a bit of trouble creating good designs when it comes to interfaces. Consider a class A with N public methods. There are a number of other classes, B, C, ..., each of which interacts with A in a different way, that is, accesses some subset (<= N) of A's methods. The maximum degree of encapsulation is achieved by implementing an interface of A for each other class, i.e. AInterfaceForB, AInterfaceForC, etc. However, if B, C, ... etc. also interact with A and with each other, then there will be a combinatorial explosion of interfaces (a maximum of n(n-1), to be precise), and the benefit of encapsulation becomes outweighed by a code-bloat. What is the best practice in this scenario? Is the whole idea of restricting access to a class's public functions in different ways for other different classes just silly altogether? One could imagine a language that explicitly allows for this sort of encapsulation (e.g. instead of declaring a function public, one could specify exactly which classes it is visible to); Since this is not a feature of C++, maybe it's misguided to try to do it through the back door with interaces?

    Read the article

  • How Can I Learn about Interfaces

    - by BDotA
    I am using C# and I know what are the interfaces and how syntatically use them,etc. but what I have not learned yet is that when I am tasked to write a project, create a component,... How should I learn better about interfaces so when I want to do something I be able to Think about using them in my design...or for example I want to learn about dependency injection or even using mocking objects for testing, these are all related to good understanding of interfaces and know when and how to use them ... Can you plase provide me some good advice, reading,... then can help me with that?

    Read the article

  • How Can I Learn when to build my own Interfaces

    - by BDotA
    I am using C# and I know what are the interfaces and how syntatically use them,etc. but what I have not learned yet is that when I am tasked to write a project, create a component,... How should I learn better about interfaces so when I want to do something I be able to Think about using them in my design...or for example I want to learn about dependency injection or even using mocking objects for testing, these are all related to good understanding of interfaces and know when and how to use them ... Can you plase provide me some good advice, reading,... then can help me with that?

    Read the article

  • Scala class to implement two Java Interfaces - how?

    - by puudeli
    Hi, I have just started learning Scala and I'm now wondering how I could implement two different Java interfaces with one Scala class? Let's say I have the following interfaces written in Java public interface EventRecorder { public void abstract record(Event event); } public interface TransactionCapable { public void abstract commit(); } But a Scala class can extend only one class at a time. How can I have a Scala class that could fulfill both contracts? Do I have to map those interfaces into traits? Note, my Scala classes would be used from Java as I am trying to inject new functionality written in Scala into an existing Java application. And the existing framework expects that both interface contracts are fulfilled.

    Read the article

  • Alternatives to nested interfaces (not possible in C#)

    - by ericdes
    I'm using interfaces in this case mostly as a handle to an immutable instance of an object. The problem is that nested interfaces in C# are not allowed. Here is the code: public interface ICountry { ICountryInfo Info { get; } // Nested interface results in error message: // Error 13 'ICountryInfo': interfaces cannot declare types public interface ICountryInfo { int Population { get; } string Note { get; } } } public class Country : ICountry { CountryInfo Info { get; set; } public class CountryInfo : ICountry.ICountryInfo { int Population { get; set; } string Note { get; set; } ..... } ..... } I'm looking for an alternative, anybody would have a solution?

    Read the article

  • Should interfaces define properties?

    - by Otávio Décio
    Interfaces, as defined by MSDN "contain only the signatures of methods, delegates or events." However, since properties are no more than syntactic sugar for a get and set method, they are also allowed in interfaces. My question is - is there any situation where defining properties in an interface is appropriate or should we stick to the scenarios described by MSDN?

    Read the article

1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >