Introduction:
I'm working on an API which provides access to Picasa, Flickr and some other image services.
I have a class WebAlbum (it provides access to nested photos, albums if allowed, and some meta information).
My API allows the user not only to read albums but it also allows them to create new albums. In the general case, in order to create new album, the API user should use a factory method, which creates an album and then call the method WebGallery#addAlbum (newAlbum).
But Flickr doesn't allow creation of empty albums, it requires at least one predefined photo in any new album (to make nice album preview probably). In Flickr terms this first photo is called the Primary Photo. So in order to create an album for Flickr, user should use a factory method, then add an image to the new album, and then call WebGallery#addAlbum (newAlbum).
Problem:
At the moment WebAlbum class has this method
public interface WebAlbum {
...
public boolean requiresPrimaryPhoto ();
}
I can't leave this name because PrimaryPhoto is just a Flickr term. I can change it to
public interface WebAlbum {
...
//with spaces: requires one added photo to create new album
public boolean requiresOneAddedPhotoToCreateNewAlbum ();
}
Please suggest a shorter name which has the same meaning.
boolean isEmptyAlbumAllowed
public boolean needsDefault;
or, more descriptive
public boolean needsDefaultImg;
EDIT
Another question you should ask yourself is if this property even should be exposed. If you want to make the experience of managing albums consistent on all backends, then maybe your library could provide default images where required. A logo for your app, maybe. Users are unlikely to have empty albums for very long anyway.
I would go with
public boolean requiresDefaultImage;
or
public boolean requiresAlbumImage;
I would use something like allowsEmptyAlbum or emptyAlbumPermitted
That being said, adding an extra method means that the user of the class needs to know that this could even be an issue and remember to make the check before adding the album. This could be an issue because most developers "want to get things done fast" and would not know about the differences between services.
Even adding a note in the documentation is not enough because many folks calling "addAlbum" would never read the documentation of the method since it seems straightforward (see my research for details).
Ideally, you would either be able to create different factories for each service (and provide the information there), or, if you have to use a single API, find a way of gracefully failing or maybe adding a placeholder image.
I think you can make it even shorter by removing the redundant Album portion.
public boolean canBeEmpty();
public boolean requiresInitialPhoto ();
public boolean doesOnePhotoExist ();
public boolean needsOnePhoto ();
Create FlickerWebAlbum and PicasaWebAlbum classes. Each of them will represent behavior specific to each provider.
The short answer to your question:
boolean isDefaultPhotoRequired;
The longer answer: the default photo requirement isn't shared by all WebAlbums, so it's a perfect candidate for using inheritance. Move that behavior to a Flickr specific subclass. You could do something like add the creation of that defaultImage to a Flickr.init().
Related
I have tried doing a search for this but I fear I may not be wording what I want to do very well.
Currently, we have about a hundred action classes in our application with each determining if a user has access to it. I would like to make a class that can figure out the calling method, what permissions are required for it, and if the user has those permissions. Unfortunately, I don't really know how to even get started with this as each class may have slightly different requirements.
I'm happy to add more explanation if needed but as I said, I'm not sure I'm wording what I'm trying to do very well so if anyone has a better way of putting it that gets me some google results or a link to a related question here that's already been answered, I know I'd appreciate it.
current permissions checks look like below. This is a simple implementation, there are usually multiple profile checks in one if block.
If (scc.getUser().getCurrentProfile().getSystemAdmin() != 1) {
logIllegalAccess(log);
break;
}
IMHO the most elegant solution would make use of annotation processing. The idea is that you would annotate action classes with a custom annotation, something like:
#RequiredPermission(Permissions.SYSADM)
class ActionA {
public ActionA newInstance() {
return new ActionA_Gen(new ActionA());
}
private ActionA() {...}
...
}
Action classes would have to have a newInstance() method to be used to create instances instead of calling new. The method would create an instance of a class by the same name with _Gen extension. This class would have one method for each method in the original action class, which would perform a permission check and call the corresponding method in the original class instance that was passed to its constructor.
The _Gen class would be generated by an annotation processor.
Note that by using reflection it might be possible to move the newInstance() method in a common superclass.
I just try to get more into SOLID principles but get stuck by implementing new structures in my old (not SOLID) code.
I have this Room.Class
public class Room {
private String roomCode;
private String roomDescription;
// getter/setter
}
Now I need to have a translation for the roomDescription. I started to create an interface
public interface ITranslation {
String findTranslation();
}
and an implementation
public class RoomDescriptionTranslation implements ITranslation {
#Override
public String findTranslation() {
return "translated Room";
}
In the already existing code there is a service class which creates some Rooms with codes and descriptions. These Rooms are also used in the view (as jsp bean).
The new requirement is to have the translated description on the view.
So for me the question is where I should implement the logic of translation of the existing Rooms.
Should I implement it in the existing serivce class where the Rooms are created?
Or should RoomDescriptionTranslation be a field inside Room?
Or should I created a new service class where just the description gets translated?
Just need a pointer to go to the right direction.
It could be first or third option, but not the second option in my opinion. I think one important question, in general for designing any class is this:
For a property p and class C, is p a property of C?
So, in your case the question becomes: is translation a property of Room? Semantically, it sounds that it is not.
Then, you can ask the same question on Room Service class. The answer to that depends on how you defined your service class. Again, another rule that helps to decide whether a property belongs to a class, is this:
What is one singe word or phrase that describes this class?
This goes to the very idea of what a class is in OOP and also to S in SOLID. Once, you ask this question and can describe one single purpose for your class, then you can go back and ask the first question, whether certain property belongs to this class or not.
Now, if your service class is such that, "Handle all room related actions" (not saying this is right, but if this is the case) then you can add one more action to it, namely translation. But, if it is not then you may create a new service, translation.
Considering all this, I lean more towards having a new translation service as it looks
Something independent
Will be easily extendible (compared to other option) like adding more languages
Does not require changing existing code
Again, there might be other factors affecting the whole thing.
I would create a model TranslatedRoom extends Room to use only in view this L from SOLID and inside this new model would take care about translations.
Of course if it is possible to refactor service which creates model for views etc.
One more thing (maybe it is S from SOLID) this idea is good if we need to show translated room only in this/these views.
If you want to translate text you should use internationalization solutions which already exist in java.
In your solution you'll create painful maintenance problems and every string which you'll return will be surrounded by if.
I have a some functionality implemented to store documents inside a data base.
Now, I want to access the functionality in my module but not directly.
As I have the FileInputStream with me and the functionality implemented accepts JSON string.
So, which design pattern could be used to bridge the gap in input parameters?
I know Adapter is one of the answers but can anyone suggest anything else?
Below is the sample of the functionality.
public interface DocumentService {
public String create(String jsonRequest);
public String search(String jsonRequest);
public String update(String jsonRequest);
public String fetch(String jsonRequest);
}
To elucidate my comments:
Trying to wedge every bit of functionality into an explicit "pattern" isn't a productive use of your time.
Even if it is, trying to find the perfect "name" for what you actually come up with isn't.
You need a helper class that converts an FIS into JSON, and that's about it.
You could compose a service that uses that helper and your existing class, or...
Compose your existing class into the FIS => JSON converter, or...
Modify your data flow so that you pass the data through a filter that JSONifies it, or...
In other words, (a) the "best" answer depends on your very specific situation, and (b) it doesn't matter what it's called. Do something, put it somewhere half-way reasonable, and if it ends up not being exactly right, iterate until it is. Don't waste time trying to name the "pattern".
It's like throws and joint locks: don't look for them, find them. The patterns are hidden in your application, surface them and implement.
Just make a private converting method
String toJSON(FileInputStream fs) {
...
}
If you happen to need that method in multiple locations move it into a utility class.
If that single method is not flexible enough for every situation you need it in right now then you should consider writing an adapter class.
The desire to design a perfect, flawless architecture for every functionality is natural in many programmers. It poses the risk of paralyzing the actual objective, which is to deliver a working product.
The important thing about good design is not that it fulfills every possible use case that may arise in the future, but that it is easy to understand and easy to change should that use case actually arrive.
Looks like Adapter is a good choice. I will move forward.
Why don't you use the DAO pattern?
Pass the input stream to the DAO object and make it convert it from the file input stream to JSON and call the create methods.
http://www.tutorialspoint.com/design_pattern/data_access_object_pattern.htm
I'm creating a Facebook application that uses many calls to Facebook's asynchrunner class. As such, I am constantly using many callback listeners.. I have many classes that have to respond. I am finding that I cannot remember which classes are defining which callback listener result codes. I am worried that I am going to end up using the same callback result code in two different classes and this could cause serious problems. What is the best practice for organizing this? Thanks!
I think you probably meant "request codes", but it doesn't matter for the purpose of this answer. I would suggest creating a separate interface to contain all these codes:
public interface FBCallbackCodes {
public final static int AUTH_CODE = 1;
public final static int POST_PHOTO_CODE = 2;
...
}
Then, whenever you need to introduce a new code, just add another public final static to this interface and use it like FBCallbackCodes.AUTH_CODE rather than hard-coding the values where you're using them.
This way you're achieving two things:
All codes are kept in one place and you'll easily see what else to add without introducing duplication.
If you have two places in your app that use the same functionality with the same code, you can easily see that the required code already exists and just re-use it.
I've checked the suggested solutions and can't find my answer. If the answer is out there, then I'm sorry for posting it again.
I'm consuming a wcf rest service.
In my test activity I do;
private final static String SERVICE_URI = "http://10.0.2.2/Service1.svc";
This will eventually be used in various activities.
So what I want to do is: private final static String SERVICE_URI = [CONSTANT]
so that if I need to re-point the service somewhere else, a single code update will result in dependent activities pointing to the correct location, allowing them to work, rather than having to update each activity.
So: how / where would I create such a constant in Android, and how would I reference it?
Many thanks any help.
The alternative to String Resources, you could do it the via creating Constants class and put your constant value there. This method is not exactly specific to Android, but have been a practice that is used by the Java community frequently.
public class Constants {
public final static String SERVICE_URI = "http://10.0.2.2/Service1.svc";
}
And refer it in other Activity/classes as Constants.SERVICE_URI. If you use this approach, you can use it anywhere even when Context or Application is not available for you.
From what you describe it sounds like you need to look at String Resources.
You can access them from any component in your Android app at any time and they're effectively 'constant' at build time.
EDIT Just to expand on the use of resources...
...take a look at Dororo's answer. All resources (strings, images / drawables and even UI elements such as Buttons etc) are accessed using 'resource IDs'. Any resId, i.e. R.blah is an int representing the resource. As such, it needs to be fetched in the correct way.
With UI elements we use findViewById(...) and with strings we use getString(...) as in Dororo's example.
My point was that the strings are constant at build time so it isn't necessary to declare any variable as final static that represents a string resource as part of any class such as an Activity because you can access any string using the Context.getString(...) method as shown in the link.
When would you want to change this string?
If you want to change it dynamically without issuing updates to the program, you'll want to probably set it globally and then create functions to edit it which can be called whenever you wish to change the address.
If you're happy to only ever change it when the program is updated (which not all users will necessarily do remember) then you'll want to set it as a string resource or just set it globally and slap on final. To access the string from a String resource use:
context.getString(R.string.resource_name)
application.getString(R.string.resource_name)
To create a string resource, open /res/values/strings.xml and create a new string using:
<string name="resource_name">whatever web address here</string>