This question already has answers here:
Differences between Java interfaces and Objective-C protocols?
(2 answers)
Closed 8 years ago.
I've been reading the swift documentation, and working through the playground. I have to admit I have zero knowledge of Objective-C/iOS development (outside of Xamarin at least). To my eyes, a protocol seemed identical to the C# interface.
However, I noticed whilst looking around on the web that Objective-C has a concept of both a protocol (source) and an interface (although I'm not really sure what the difference is). Swift doesn't seem to have both - just protocols.
Could someone explain, for swift, what the difference/relationship between a Protocol and a C# interface is?
Update: I appreciate that the answer might be functionally the same as the duplicates listed, but I think that, given that this is asking about a different language, that the question still has merit in it's own right. After all, new developers to swift might have no knowledge of Java (beyond Javascript, I have none). Placing an expectation on someone to have knowledge of a totally different language system in order to have the answer to their question is a bit much, isn't it!? This discussion on meta is also discussing this issue.
Objective C protocols serve basically the same purpose as interfaces in Java/ C#. Objective C interface files are different. Like C, Objective C has interface files that publicly declare the methods and properties of a class, that are then implemented in an implementation file. For example you may have an interface file of a class that looks something like this:
#interface
-(void)myMethod;
#end
then in your implementation file you actually implement the method:
-(void)myMethod{
//code
}
Swift does away with separate interface and implementation files. So it only has protocols.
Related
This question already has answers here:
TCPClient vs Socket in C#
(2 answers)
Closed 6 years ago.
Two computers have to communicate via TCP/IP to synchronize a certain process flow. What would be the advantage to use the wrapper classes TcpClient & TcpServer over a Socket object?
I have programmed it using the first but somehow it seems for me to complicated and could be much easier solved just using the latter.
Any good advice for me?
The idea is that with the wrapper classes much of the code that you are likely to want has already been written for you.
Advantages of using the wrapper should be:
Validation already done
Less code to write
Already tested extensively
Code re-use is to be applauded where it makes sense to do so
Advantages of rolling your own:
You get exactly what you want
You can create your own syntax
Disadvantages of rolling your own:
You have to write ALL the code, including tests
If you are like me, you are probably not as knowledgeable as the specialist who wrote the wrapper
As a result it is likely that the resulting code could be less efficient than the code in the wrapper.
The decision is always yours. After all, you could actually rewrite the whole framework if you wanted to do so, but why would you bother?
You need to look at what is provided for you by the wrapper and decide for yourself whether it provides what you need. If it does, then I would say use it. If it fails to meet your requirements either write your own or extend the wrapper so that it does do what you want.
Hope that helps.
This question already has answers here:
Why would I want to use Interfaces? [closed]
(19 answers)
Closed 8 years ago.
I am working on learning C# in depth. I am mostly confused by the frequent implementation of interfaces. I always read that this class implements this interface. For instance, SqlConnection class implements IDbConnection. What is the benefit for developers in this case?
the interfacing is based on object-oriented principles, e.g. see SOLID. You should not rely on implementation of other classes you're working with - it should be sufficient for you to know only what they do and what they should return. A good example with the SqlConnection would be that you may be able to change the DB you are using quite simply (to e.g. MySQL or Oracle) by changing the implementation on just one place, providing that your code is correctly using the interfaces and propagating the instances.
An interface contains definitions for a group of related functionalities that a given type must implement (a sort of Method Signature Contract). It does not, however, guarantee the specific behavior of those implementations.
Interfaces are particularily useful as they allow the programmer to include behavior from multiple sources in programming languages that do not support multiple inheritance of classes like C#.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
I've read some things about this, I even found similar question, but it didn't really answer this. For me it seems that privatizing something only makes my life so much harder when I need to find a private variable in a class to use it elsewhere. So what is would the problem be if everything was public? Would it somehow slow the program itself?
You must consider the maintainability of the code. Accessing all the variables everywhere in your solution is good only if you are the only one in the project and you will be the only one that maintain and use the code. If someone else's entered into project and do completely different things they will be able to access your methods/variables and set the things to unexpected variables. You should think as a OOP design and design your classes like that.
FYI I don't believe you are supposed to ask discussion-based questions like this on SO... But the simplistic answer is this: don't limit your thinking to the logic of the code. We all know there are ten thousand ways to accomplish the same thing. You can probably rewrite a bunch of your code to avoid encapsulation. However, data encapsulation provides a few benefits when you start working on larger projects or with larger teams that go beyond just writing functional code:
(1) organization by concept: if you're coding a bike you would code a class for the wheel, a class for the frame, a class for the handlebars, etc., and you'd know where to go to resolve an issue, perhaps even after months of time away from the code;
(2) separation of implementation and interface: you can tell the world about your public interface and handle the actual implementation privately, so people don't have to know how things work in your code, they just know that it works, like a black box; and if later you have to change your private implementation you can do so freely as long as the public interface still works;
(3) simplification for humans: remember, humans read your code, so would you like to slam them with every bit of data and logic in your project? that would just make for a bunch of angry programmers.
So that's a gentle introduction to encapsulation.
This comes from the fact that, a class should not expose its members directly but must provide a proxy through which the members must be accessed. (Like getters/setters or Properties)
See this question for more info: Why it is recommended to declare instance variables as private?
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Why is the default decision in C++, C#, and Ada 95 to use static method binding, rather than dynamic method binding.?
Is the gain in implementation speed worth the loss in abstraction and re-usability?
In general, you can consider that you have todesign the base class for extensibility. If a member function (to use the C++ vocabulary) isn't designed to be overridden, there is a good chance than overriding it will in practice not be possible and for sure it won't it be possible without knowledge of what the class designer think is implementation details and will change without giving you prior notice.
Some additional considerations for two languages (I don't know C# enough to write about it):
Ada 95 would have had compatibility issues with Ada 83 if the choice was different. And considering the whole object model of Ada 95, doing it differently would have make no sense (but you can consider that compatibility was a factor in the choice of the object model).
For C++, performance was certainly a factor. The you don't pay for what you don't use principle and the possibility to use C++ just as a better C was quite instrumental in its success.
The obvious answer is because most functions shouldn't be virtual. As AProgrammer points out, unless a function has been designed explicitly to be overridden, you probably can't override it (virtual or not) without breaking class invariants. (When I work in Java, for example, I end up declaring most functions final, as a matter of good engineering. C++ and Ada make the right decision: the author must explicitly state that the function is designed to be overridden.
Also, C++ and (I think) Ada support value semantics. And value semantics doesn't work well with polymorphism; in Java, classes like java.lang.String are final, in order to simulate value semantics for them. Far to many applications programmers, however, don't bother, since it's not the default. (In a similar manner, far too many C++ programmers omit to inhibit copy and assignment when the class is polymorphic.)
Finally, even when a class is polymorphic, and designed for inheritance, the contract is still specified, and in so far as is reasonable, enforced, in the base class. In C++, typically, this means that public functions are not virtual, since it is the public functions which define and enforce the contract.
I can't speak about Ada, but for C++ two important goals for the design of C++ were:
backwards compatibility with C
you should pay nothing (to the extent possible) for features that you don't use
While neither of these would necessarily dictate that dynamic binding couldn't have been chosen to be the default, having static method binding (I assume you mean non-virtual member functions) does seem to 'fit' better with these design goals.
I'll give one of the other two thirds of Michael Burr's answer.
For Ada it was an important design goal that the language be suitable for system's programming and use on small realtime embedded devices (eg: missile and bomb CPUs). Perhaps there are now techniques that would allow dynamic languages to do such things well, but there certianly weren't back in the late 70's and early 80's when the language was first being designed. Ada95 of course could not radically deviate from the orginal language's basic underlying design, any more than C++ could from C.
That being said, both Ada and C++ (and certianly C# as well?) provide a way to do dynamic method binding ("dynamic dispatch") if you really want it. In both it is accesed via pointers, which IMHO are kind of error-prone. It can also make things a bit of a pain to debug, as it is tough to tell from sources alone exactly what is getting called. So I avoid it unless I really need it.
I'm guessing most of us have to deal with this at some point so I thought I'd ask the question.
When you have a lot of collections in your BLL and you find that you're writing the same old inline (anonymous) predicates over and over then there's clearly a case for encapsulation there but what's the best way to achieve that?
The project I'm currently working on takes the age old, answer all, static class approach (E.g User class and static UserPredicates class) but that seems somewhat heavy-handed and a little bit of a cop out.
I'm working in C# mostly so keeping in that context would be most helpful but i think this is generic enough a question to warrant hearing about other languages.
Also I expect there will be a difference in how this might be achieved with the advent of LINQ and Lambdas so I'd be interested in hearing how this could be done in both .Net2.0 and 3.0/3.5 styles.
Thanks in advance.
Specification pattern might be worth checking out.
With some polymorphism & usage of generics it should work.
A Predicate is essentially just an implementation of the Specification design pattern. You can read about the Specification pattern in Domain-Driven Design.