I have some database functions and would like to make those database functions accessible too all of my other classes. I would like to keep the functions in one place so they are easy to modify. What is the best way to achieve this goal? My application is running on android and is using threading and events.
Thanks in advance, if you need more information let me know.
make a class with all static methods/variables, or alternatively a Singleton
synchronize stuff if you need to, sounds like you might
Absolutely no reason why you can't have a package level class called something like DatabaseUtils and put general static methods in there. Doesn't have much bearing on it that you're using threading and events, although you will want to ensure your utility methods can handle simultaneous access if that's a possibility.
Related
Suppose I'm doing a java library that has to load a .so/.dll at its initialization, but I don't know which classes the user will use, so I cannot simply put
static{
loadSoFromMyJar();
}
on the one that is gonna be used.
The easiest solution I thought was by doing it in a class and subclassing all the classes from this one, but I also think this is not the best solution.
What would be a good solution here?
Make loadSoFromMyJar idempotent and add it in a static initialiser on all classes with native members.
What are best practices in defining access controls for methods in MVC pattern. I'm uncertain where to use static methods in a scenario like an ATM (client-server model). I'm using Java.
Appreciate if someone can shed some light on this.
Here's my approach I used to come up with a class diagram.
First I designed all the screens, sketched on a paper. (I'm kinda
artist if you wonder and into graphic design stuff :) )
Then I created View classes Created Model classes by studying the scenario
and use of data
Created Controllers for each Model and some more additional ones
Added methods to Controllers by looking at the buttons I got in the screens, which I think a straight forward way to never miss any method? + some additional ones for GUI controlling
etc.
What do you think about my approach?
Thanks.
I don't see what MVC has to do with it. A static method cannot access instance variables. Therefore static should only be used for methods that receive ALL their necessary data via parameters. Usually this is "utility" routines such as sort routines, formatters, common calculations, etc.
The other place where you might use static routines is to access static variables in a class. But it's rare that you want to do this without also accessing instance variables.
Note that there's no real requirement to make any routine static -- you can have an instance method that doesn't reference any instance variables. But a static method becomes accessible from situations where you don't have an instance handy to invoke the method.
I need to add some logic to GenericModel by means of extending it, but I understand that Play uses generics to enhance the GenericModel. What would be the right and most convenient way to extend this class?
I tried to do this, but some of the methods in GenericModel simply throw a UnsupportedOperationException exception, so this is clearly enhanced somewhere else.
Check out db.jpa.Model which also extends GenericModel.
If you intend to extends the GenericModel, I would do it in the models package. No need for an external module and it is best to avoid touching playframework core. You will have trouble updating it if you do.
But still, after a quick look at the source code, it seems that you are trying to modify JPA related code. What kind of logic are you talking about?
I've managed to get this working by means of reflection. Everything is now working 100%. :) Not really the best solution, but it works.
I have the following problem:
I have an abstract Activity class, lets call it MyAbstractActivity, that contains some code I'd like to reuse (for example: a standard service binder, common menu items, common initialization code, etc. etc.). Normally I would just use it to subclass my concrete activities and be done with it.
However, I occasionally need to use another supertype, such as a ListActivity or a MapActivity.
So the question is: how do I avoid duplicating that support code within an Activity, if I have to use another base class?
I have thought up of a solution based on the decorator pattern, like this one:
.
However, I see a problem with this approach:
What to do with protected methods (like onCreate())? Should I introduce an additional "bridge" class that makes them public for the purpose of the decorator, similarly to the way presented below (starting to look a bit byzantine...)?
Any other way?
I hope I made myself relatively clear. Thanks in advance for any feedback!
PS. Using static utility classes is not a good solution in my opinion, since it introduces a possibility of hard-to-identify programming bugs.
If I understand correctly, neither Fragments nor the Decorator Pattern are clean or appropriate solutions for what you want to accomplish. They were designed to solve other problems.
I find myself moving "support" code, or "framework" code, or "all that verbose, repetitive, boilerplate crap" to static utility methods. This isn't necessarily the approach I'd take on a non-Android project, but in my Android projects, it works pretty darn well.
Also, know that you don't need to subclass ListActivity to have a ListView.
I am building a small website for fun/learning using a fairly standard Web/Service/Data Access layered design.
To save me from constantly having to create instances of my service layer/data access layer classes, I have made the methods in them all static. I shouldn't get concurrency issues as they use local variables etc and do not share any resources (things are simple enough for this at the moment).
As far as I can see the only trade-off for this is that I am not really following a true OO approach, but then again it keeps the code much cleaner.
Is there any reason this would not be a viable approach? What sort of problems might arise later on? Would it be better to have a "factory" class that can return me instances of the service and data layer classes as needed?
You know those rides at the amusement park where they say "please keep your hands and feet inside the ride at all times"? It turns out the ride is a lot more fun if you don't. The only real trade-off is that you're not really following a true keeping-your-hands-and-feet-inside-the-ride-at-all-times approach.
The point is this -- there is a reason you should follow a "true OO approach", just as there's a reason to keep your hands and feet inside the ride -- it's great fun until you start bleeding everywhere.
The way you describe it, this isn't the "wrong" approach per se but I don't really see the problem you're trying to avoid. Can't you just create a single instance of these business objects when the server starts up and pass them to your servlets as needed?
If you're ready to throw OO out the window you might want to check out the Singleton pattern as well.
Disadvantages:
You will be unable to write unit tests as you will be unable to write mock data access/business logic objects to test against.
You will have concurrency problems as different threads try to access the static code at the same time - or if you use synchronized static methods you will end up with threads queuing up to use the static methods.
You will not be able to use instance variables, which will become a restriction as the code becomes more complex.
It will be more difficult to replace elements of the business or data access layers if you need to.
If you intend to write your application in this manner you would be better off using a language designed to work in this way, such as PHP.
You would be better off going for non-static business/data access layer classes by either:
Using the singleton pattern (creating a single instance of each class and sharing them among threads)...
Or creating instances of the classes in each thread as and when they are needed.
Keep in mind that each user/session connected to your application will be running in it's own thread - so your web application is inherently multi-threaded.
I don't really see the advantage to your design, and there are many things that could go wrong. You are saving a line of code, maybe? Here's some disadvantages to your approach:
You cannot easily replace implementations of your business logic
You cannot defined instance variables to facilitate breaking up logic into multiple methods
Your assumption that multi-threaded issues will not arise is almost certainly wrong
You cannot easily mock them for testing
I really don't see that the omission of one line of code is buying you anything.
It's not really an "OO Design" issue, but more of an appropriateness. Why are you even using Java in such a procedural way? Surely PHP would be more appropriate to this kind of design (and actually save you time by not having to compile and deploy).
I would just make your business layer non-static; it will make it so much easier for to maintain, change, and evolve your application.
You may have difficulty unit-testing your objects with this type of architecture. For example, if you have a layer of business objects that reference your static data access layer, it could be difficult to test the business layer because you won't be able to easily use mock data access objects. That is, when testing your business layer, you probably won't want to use the "real" methods in the data access layer because they will make unwanted changes to your database. If your data access layer was not static, you could provide mock data access objects to your business layer for testing purposes.
I would think that you will have concurrency issues with all static methods with multiple users. The web layer will thread out concurrent users. Can all your static methods handle this? Perhaps, but won't they constantly be locked in queuing the requests in single file? I'm not sure, never tried your idea.