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 9 years ago.
Improve this question
The facade pattern is to provide a simplified interface for complex code.
Therefore, it is correct to use it as a wrapper for a system? That would be like a translation map for facilitating the understanding hiding the complexity?
Is it correct then call all Facade as API?
Well the programming interface into any application is the Application Programming Interface, so yes it would be an API, in the same way that your OS has an API keeping you from fiddling with too much memory or abstracting the hard drive - or a game engine has an API acting as a facade for graphics and audio code.
So yes, the implementation of a Facade is an API, but so is any other code which you use as an interface into a more complicated system. (I guess you could ask the question as "are all APIs a facade that just provides a layer of abstraction?" - and you could probably make the argument that it's true).
It's a bit of an odd question to consider however, because depending on who you talk to, these terms may change - we only really use them to represent the idea of abstraction, as we see fit.
Remember that design patterns are not hard fast rules. A Facade is an API that reduces the complexity of using some system. That system may be a single library, multiple libraries, various network clients, etc.
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 6 years ago.
Improve this question
I wanted to ask little bit generic question about Java API's. I'm new in Java, learning myself and of course I enjoy it while learning. But when it comes to Java API's, to me it's hard to understand even if I know OOP's Concepts. Actually I often confuse while reading JavaDoc's. Agree that there are bunch of information about what class's(interface, enum..) has, what they extend, implements or whatever. Even though I couldn't use them without looking from the internet.
So, what is the best way of learning those API's in general, just give me your followed way while learning Java.
The best way to learn Java is to read articles with examples. It is common approach for newbies and professionals. JavaDocs is dry, too formal and really are often confusing (especially for methods from Stream API with 3+ generic parameters).
The way I did was to read certification books, for OCA and OCP, they start from the very basic, and builds up on the top of that, with examples and exercises.
It is a really nice way to build your core knowledge of the language. With that solidified knowledge you can start reading articles about different subjects in the Java universe ...
Just be patient, code as much as possible, and it will become natural aftar some time.
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 attended a seminar about API basics yesterday and something struck out as odd to me. We covered a basic synopsis of what REST is and what SOAP is and these were defined as architectures of an api.
The way the presenter defined it is that programs have languages and apis have architectures. Is this the proper definition of what an architecture is for an api?
I've looked around on google trying to compare the two terms programming language and architecture and haven't found a clear result.
That statement was almost definitely hand-wavey over-simplification, and was probably only correct within the context of the point he was trying to make.
Architecture is the design and documentation of the high-level functioning of programs and the interaction of those programs.
Programs are implemented in languages, APIs are implemented as programs.
APIs are a documentation of a particular interface to a program, and thus are part of an architecture. APIs are implemented as programs, that themselves have architectures, that fit into a larger system architecture.
I would ignore his statement, it is not helpful to your mental model. Understand what programs are, what languages are, and what architecture is.
REST and SOAP are not even peers. REST is an architectural style, often implemented as HTTP verbs. It is contrasted with RPC style web services, which are often implemented with SOAP. SOAP is a protocol that sits on top of HTTP to implement RPC style web services, it is not an architecture, it is a protocol. REST is not a protocol, it is an architectural element. None of these are a full architecture in and of themselves. SOAP/REST/HTTP/programs/languages all are components in an architecture.
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'm currently developing a school project and we are instructed that we are required to implement Object-Oriented Programming concepts in our software. But I don't want to implement it just by simply inheriting this class to that class and overriding this method to implement its own functionality and so on. Though it is still acceptable but I want to do it differently. By differently, I mean by using design patterns. I'm trying to understand it one by one and I noticed that some of them are very useful(Builder, Memento and Adapter). But the problem is there are so many of them and if possible I want to put/implement it all(those 3 design pattern). Is it okay if I do that? Would it mess up the project as a whole?
As always: It depends.
Overusage of patterns on small and simple bits of code can obscure the code. But it can also make it more clear.
Don't use patterns wherever possible. Use them when it serves a purpose. Every pattern has its purpose and if you can't find that purpose in your code, you shouldn't rewrite it to match a pattern. Try to keep your code a) maintainable and b) easy to read. If a pattern fulfills these criteria more than your approach without patterns: go for it.
You can have code with dozens of patterns and code with none. In both cases it can be the ideal choice.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm running some test on those three networking framework: ResKit, NSURLConnection and AFNetworking. And I am seeing that it is not easy to see the differences between the third party libs. What are the major differences between the those? and why? which one is best among these
NSURLConnection is the standard Cocoa class for managing network connection.
That is the base to all these third party libs
The difference is that they are richer,They are written to improve usage of network call in the most easier way and all the basic network call is made possible by custom methods by these libraries
As a dev, Using these will give more Readability ,Performance and icing on the cake is..less code.
Restkit uses AFNetworking for the network communication ,Other than that restkit is a parser for the data coming through the network and is most suitable for RESTful webservices
MKNetworking is one of the other favorites which will have the second place in this list.Got performance and can reduce tons of code
For me,The winner is AFNetworking.It is one of the coolest framework in iOS making my programmig life much easier in network communication.Got great performance also.And uses the latest [or recent] block programming implementation which make the code super easy to read and understand
one more is there ASIHttpRequst : It was a good one but now sadly discontinued
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
Thinking about service orientation, our team are involved on new application designs. We consist in a group of 4 developers
and a manager (that knows something about programming and distributed systems). Each one, having own opinion on service design.
It consists in a distributed system: a user interface (web app) accessing the services in a dedicated server (inside the firewall), to obtain the business logic operations.
So we got 2 main approachs that I list above :
Modular services
Having many modules, each one consisting of a service (WCF).
Example: namespaces SystemX.DebtService, SystemX.CreditService, SystemX.SimulatorService
Unique service
All the business logic is centralized in a unique service.
Example: SystemX.OperationService. The web app calls the same service for all operations.
In your opinion, whats the best? Or having another approach is better for this scenario?
A web service is an interface. The invoker doesn't care how a service works, it just needs to know what arguments to supply and what outcomes to expect. So a multitude of simple, discrete servcies is probably better.
Behind their interfaces they can all join up in one great big bundle of business logic. Who cares?
In practice, teach of hese services will share some elements of SystemX functionality and will have some elements which it alone uses. Some may combine elements of SystemX and SystemY. If SystemX and SystemY are legacy apps it may not be possible to change them, so we have to work with them as they are. In other scenarios it is possible to expose impose modularity on them.