When would a class method be called fetchItems() rather than getItems()? Is there a difference?
fetchImage() vs getImage() etc...
"Get" is usually considered a local action and involves little more than poking at memory. "Fetch" may involve reaching across the network to a remote server to access the resource.
Related
I'm using AFNetworking for all my connections in my app. I created a singleton 'client' class that takes care of all the AFNetworking code and uses AFHTTPRequestOperationManager. What I am confused about is whether the AFHTTPRequestOperationManager object should be a property, or should I recreate one everytime my client is asked for a connection? If it is a property, can my client be called many times asynchronously, or will that cause problems, since the same instance of AFHTTPRequestOperationManager will be used possibly at the same time ?
Typically, your singleton 'client' class would be a subclass of AFHTTPRequestOperationManager. It could also be a property, but then you won't be able to override methods. Some commonly overridden methods are:
- HTTPRequestOperationWithRequest:success:failure:, to modify how all request operations are constructed (for example, if you need an identical header in every request)
– initWithBaseURL:, to apply additional customization to the operation manager
That said, a property could work fine depending on your needs. (See Prefer composition over inheritance? for some delightful weekend reading.)
And finally:
If it is a property, can my client be called many times asynchronously, or will that cause problems, since the same instance of AFHTTPRequestOperationManager will be used possibly at the same time?
Yes, AFHTTPRequestOperationManager is designed to be thread-safe. You can tell it to do stuff from different threads. (Note that its completion blocks are always called on the main thread, since UI work is typically done there.)
I'm reading up on Local Storage in HTML5, and I'm starting to view it sort of like a client-side version of how I use memcached. That got me thinking -- I currently do page-level caching in memcache.
Is that possible with localStorage? That is, can an assembled page store itself (or, more importantly, maybe parts of itself) in localStorage such that the client doesn't have to work its DOM so hard next time the user shows up to a page?
It seems to me that since things are only stored as strings this may not work unless there is some string to object transformation available.
Have a look at Christian's 2010 24ways post under the heading Caching a full interface (near the end). He basically does:
localStorage.setItem('state',f.innerHTML);
Followed by:
if('state' in localStorage){
f.innerHTML = localStorage.getItem('state');
}
Where f is the element he wants to cache.
The problem with this is that you don't know what's in the cache until you've loaded your page, meaning that you'd need to perform another HTTP request to get the data that you do need which leads to even more overhead. I would definitely stick with the server-side caching of resources.
You could do it, but something like this would basically involve a single, master index page of Javascript that either loaded cached local files or performed Ajax requests to load content from the server.
I have several service classes that have static methods and offer a service to the rest of my program. Most of these services involve accessing an instance of SqlDataContext (linq2sql).
First I tried instantiating this connection as a static private member per service class.
This works, but it also generates a bunch of lock ups, delays and dirty object problems.
Now I went with a private instance that gets instantiated at method level. This works better in terms of lock ups and problems with dirty objects because the scope is smaller and more predictable, but this also generates a bunch of overhead in terms of connection handshakes.
How do you suggest to take on this problem?
Take a look at this article by Rick Strahl - he explains the options and provides a good factory implementation to cope with creating a single request per web context/thread (depending on what you are working in.
Used this in most of the applications I have worked on where we used linq-to-sql and it seemed the right approach!
In all my projects till now, I use to use singleton pattern to access Application configuration throughout the application. Lately I see lot of articles taking about not to use singleton pattern , because this pattern does not promote of testability also it hides the Component dependency.
My question is what is the best way to store Application configuration, which is easily accessible throughout the application without passing the configuration object all over the application ?.
Thanks in Advance
Madhu
I think an application configuration is an excellent use of the Singleton pattern. I tend to use it myself to prevent having to reread the configuration each time I want to access it and because I like to have the configuration be strongly typed (i.e, not have to convert non-string values each time). I usually build in some backdoor methods to my Singleton to support testability -- i.e., the ability to inject an XML configuration so I can set it in my test and the ability to destroy the Singleton so that it gets recreated when needed. Typically these are private methods that I access via reflection so that they are hidden from the public interface.
EDIT We live and learn. While I think application configuration is one of the few places to use a Singleton, I don't do this any more. Typically, now, I will create an interface and a standard class implementation using static, Lazy<T> backing fields for the configuration properties. This allows me to have the "initialize once" behavior for each property with a better design for testability.
Use dependency injection to inject the single configuration object into any classes that need it. This way you can use a mock configuration for testing or whatever you want... you're not explicitly going out and getting something that needs to be initialized with configuration files. With dependency injection, you are not passing the object around either.
For that specific situation I would create one configuration object and pass it around to those who need it.
Since it is the configuration it should be used only in certain parts of the app and not necessarily should be Omnipresent.
However if you haven't had problems using them, and don't want to test it that hard, you should keep going as you did until today.
Read the discussion about why are they considered harmful. I think most of the problems come when a lot of resources are being held by the singleton.
For the app configuration I think it would be safe to keep it like it is.
The singleton pattern seems to be the way to go. Here's a Setting class that I wrote that works well for me.
If any component relies on configuration that can be changed at runtime (for example theme support for widgets), you need to provide some callback or signaling mechanism to notify about the changed config. That's why it is not enough to pass only the needed parameters to the component at creation time (like color).
You also need to provide access to the config from inside of the component (pass complete config to component), or make a component factory that stores references to the config and all its created components so it can eventually apply the changes.
The former has the big downside that it clutters the constructors or blows up the interface, though it is maybe fastest for prototyping. If you take the "Law of Demeter" into account this is a big no because it violates encapsulation.
The latter has the advantage that components keep their specific interface where components only take what they need, and as a bonus gives you a central place for refactoring (the factory). In the long run code maintenance will likely benefit from the factory pattern.
Also, even if the factory was a singleton, it would likely be used in far fewer places than a configuration singleton would have been.
Here is an example done using Castale.Core >> DictionaryAdapter and StructureMap
I want to do this (no particular language):
print(foo.objects.bookdb.books[12].title);
or this:
book = foo.objects.bookdb.book.new();
book.title = 'RPC for Dummies';
book.save();
Where foo actually is a service connected to my program via some IPC, and to access its methods and objects, some layer actually sends and receives messages over the network.
Now, I'm not really looking for an IPC mechanism, as there are plenty to choose from. It's likely not to be XML based, but rather s. th. like Google's protocol buffers, dbus or CORBA. What I'm unsure about is how to structure the application so I can access the IPC just like I would any object.
In other words, how can I have OOP that maps transparently over process boundaries?
Not that this is a design question and I'm still working at a pretty high level of the overall architecture. So I'm pretty agnostic yet about which language this is going to be in. C#, Java and Python are all likely to get used, though.
I think the way to do what you are requesting is to have all object communication regarded as message passing. This is how object methods are handled in ruby and smalltalk, among others.
With message passing (rather than method calling) as your object communication mechanism, then operations such as calling a method that didn't exist when you wrote the code becomes sensible as the object can do something sensible with the message anyway (check for a remote procedure, return a value for a field with the same name from a database, etc, or throw a 'method not found' exception, or anything else you could think of).
It's important to note that for languages that don't use this as a default mechanism, you can do message passing anyway (every object has a 'handleMessage' method) but you won't get the syntax niceties, and you won't be able to get IDE help without some extra effort on your part to get the IDE to parse your handleMessage method to check for valid inputs.
Read up on Java's RMI -- the introductory material shows how you can have a local definition of a remote object.
The trick is to have two classes with identical method signatures. The local version of the class is a facade over some network protocol. The remote version receives requests over the network and does the actual work of the object.
You can define a pair of classes so a client can have
foo= NonLocalFoo( "http://host:port" )
foo.this= "that"
foo.save()
And the server receives set_this() and save() method requests from a client connection. The server side is (generally) non-trivial because you have a bunch of discovery and instance management issues.
You shouldn't do it! It is very important for programmers to see and feel the difference between an IPC/RPC and a local method call in the code. If you make it so, that they don't have to think about it, they won't think about it, and that will lead to very poorly performing code.
Think of:
foreach o, o.isGreen in someList {
o.makeBlue;
}
The programmer assumes that the loops takes a few nanoseconds to complete, instead it takes close to a second if someList happens to be remote.