0

I have a class: DatabaseService.as This class creates a local sqlite connection and creates tables if they do not exist. Connection link will be used by several other classes. Some classes will be called on startup others on user interaction. "DatabaseService" class dispatches event when database connection is opened. Other classes initialise "DatabaseService" class and awaits for "DatabaseReadyEvent". This works great but what can I do when I need to call a function/method from the same class several times?

Example:

I create an instance of "PrefService" class in mxml component. "PrefService" creates a new "DatabaseService" class in it's constructor. It then waits for "DatabaseReadyEvent" and executes sql query(this works fine). but then I also need to call "addDir" method (and few others) in "PrefService" class and the sqlConnection property is not set yet causing an error. How can I deal with this? I am new to OOP so I am probably missing something quite simple...

What I've tried / My ideas:

  1. I could check if if sqlConnection exists in "PrefService" class but I think this would be poor practice and still require a delay mechanism of some sort.

  2. I could also create a new instance of "DatabaseService" class for each method and add a new event listener but this would be very cumbersome with 2 functions for each method call not to mention events.

What is the best option in this scenario?

DominicM
  • 6,520
  • 13
  • 39
  • 60

2 Answers2

3

The hate for Singleton is well-deserved. I'd suggest not ever getting in the habit of using it, so you don't have to break that habit when you find how horrible it is to maintain.

Your biggest mistake is having your View creating and executing your service. Unfortunately, this is encouraged by how the FB service generation code works. What you want, instead, is something more like MVCS (Model-View-Control-Service) of the type encouraged by Frameworks like Robotlegs.

To walk through how to go from a tightly-coupled architecture to a loosely-coupled one, start with this example. Note that the Service is a static Class, which pretty much has all the issues as a Singleton as far as encouraging tight coupling. Even though there is only one Class using the Service, imagine what would happen if you have a large project where tens or hundreds of Classes are referencing it. Now imagine something needs to change. Ick.

Now look at the project, refactored so that the View is simply generating an Event that results in calling the service. The service is still static, but in this case there is exactly one thing that knows about it (Mate), so if you want to make that not static or sometimes use a different service, you easily can, now.

In fact, you can change things around so easily that this is the project, refactored to use Robotlegs. You don't necessarily have to use a Framework, as I did--you can see that the basic structure involved in the core Classes doesn't care a bit about how the Event is being handled or how the data gets into the Views. If you're not comfortable using a Framework, handle it your own way. But Frameworks have been around a while, and they've worked out a lot of issues you haven't thought of yet.

Amy Blankenship
  • 6,485
  • 2
  • 22
  • 45
  • 1
    +1 Good advice. http://puremvc.org/ might also be a framework worth considering (very mature, well-supported and applicable in other languages). Using frameworks is a also a really good introduction to the correct use of design patterns (and worth noting that almost all of them make use of the Singleton pattern). – net.uk.sweet Sep 01 '12 at 15:33
  • I'm liking RobotLegs, will try to implement it if it doesn't confuse and demotivate me too much(so far its a bit foreign to me but not overly complex), Thanks for the in depth answer! @net.uk.sweet PureMVC might be bit much for me right now :) – DominicM Sep 01 '12 at 18:19
  • Certainly PureMVC uses Singleton, as do the older variants of Cairngorm. That's the major reason people are moving away from them. – Amy Blankenship Sep 02 '12 at 01:08
  • @AmyBlankenship -What evidence do you have that shows people are moving away from PureMVC? Or do you mean Singletons in general – Neil Sep 06 '12 at 14:13
  • Just the talks at things like 360Flex are about Robotlegs and Cairncorm 3, with nary a mention of PureMVC. That's what the industry leaders are doing, and that's who I had in mind. We hardly hold people who are following outdated practice up as examples, now, do we? – Amy Blankenship Sep 15 '12 at 01:55
2

It's tricky to advise without seeing any code, but it might be worth considering making the DatabaseService class a Singleton and initialising it (and the database connection) once as part of your start-up routine (ie. before the classes which use it are instantiated). This would ensure that the classes which use the DatabaseService all share a single connection link to the database, and that the link is available when they come to use it.

Singletons in ActionScript generate a fair bit of debate because in other languages the pattern relies on the ability to set the access modifier of the class constructor as private (which you cannot do in ActionScript 3.0). However, you could choose from a couple of approaches detailed here.

Also, Singletons in general generate a fair bit of debate which might be worth understanding before you use one in anger (since you state you are new to OOP I am assuming you have not done so before).

Community
  • 1
  • 1
net.uk.sweet
  • 12,444
  • 2
  • 24
  • 42
  • Thanks for the response. I was afraid I would have to delve deeper into design patterns :) Looks like LOTS of hate for singleton, will read up on design patterns a bit more, maybe I will use proxy, Thank you! – DominicM Sep 01 '12 at 00:29
  • 1
    You won't regret spending time studying design patterns; just remember that they're nothing more than tried and tested solutions to common programming problems. At this stage I wouldn't worry too much about the bad press the Singleton pattern gets (I just thought it would be remiss of me not to mention it); if it helps solve your problem then I would recommend you use it and, if not, use another approach (the Proxy pattern may well be a good fit). – net.uk.sweet Sep 01 '12 at 00:50
  • I might go with singleton for the DatabaseService since it only will ever require one instance, Proxy pattern like other patterns aren't all that simple to an OOP noob :) – DominicM Sep 01 '12 at 18:00
  • -1 for singleton. There's no excuse - ever - for using one. It's not easier to use as a noob and it teaches you extremely bad programming practices. – Creynders Sep 02 '12 at 13:41
  • 1
    -1 seems harsh especially since I've acknowledged the problems with the Singleton pattern in my answer. And I have to disagree with you on your point; I don't believe there is anything inherently wrong with it is a pattern though it is frequently misused. I think in this case (a single instance resource which needs to be managed) it's a reasonable fit and given the stage in his OOP journey of the person who asked the question, arguably a more reasonable suggestion than to implement an MVC framework. – net.uk.sweet Sep 03 '12 at 13:30
  • @Creynders - sometimes having a singleton to guarantee only one instance can be a life saver when working on a large project with multiple developers. As soon as they try to create an instance, they get an error thrown which tells them to use Whatever.getInstance() which I think has served me well over the years. – Neil Sep 06 '12 at 14:15
  • @net.uk.sweet maybe it's a bit harsh, sorry for that, but the problem is exactly that noobs are always pointed towards using a Singleton and it's a VERY nasty habit very hard to get rid of. Learning how to deal with racing conditions and dependency management should not be put off. – Creynders Sep 07 '12 at 14:39
  • @net.uk.sweet And there's definitely something inherently wrong with the Singleton anti-pattern, the problems are manifold: 1/ sometimes singletons need to be transformed to "normal" classes, which means you'll be modifying ALL its clients 2/they're a hidden dependency sprinkled throughout your code 3/ they make your classes untestable, since they're unmockable 4/the pattern violates SRP – Creynders Sep 07 '12 at 14:39
  • @Neil it's not the single-instance requirement which is bad. That's a very valid use case, which I encounter in all of my projects. The problem lies with the Singleton anti-pattern. The only benefit you gain from it is to have a RT error thrown if a developer wants to instantiate the class. Figuring out how to use a DI container takes you 2-3 hours and will save you 100's. – Creynders Sep 07 '12 at 14:40