Are singletons evil?

Ask your average developer what design patterns they use in their code and a high percentage will say "Oh yeah of course, I use the singleton all the time." they might even name drop the gang of four. In an earlier post I linked this compelling argument by Steve Yegge basically stating the pattern is overused and does more to defy good OOD than it does to help it.

Steve's post is one of many singleton's are evil sentiments posted all over the internet. I don't care to go about writing another Dijkstra-like "considered harmful" diatribe. Rather I'd like to give my take on some of the more interesting and popular talking points that either defend or abhor the use of this pattern.

Common talking points and my take on each:

1. A singleton is basically a memory leak
1. In terms of languages that implement a garbage collector this thought may be a bit pedantic, but if a singleton allocates memory that memory is not released until the application ends. Unless you explicitly implement a destructor, which for a singleton opens other problems. In C# you wouldn't be able to instantiate the same singleton within the same application domain again after destruction. Also since singletons tend to get referenced all over the applications that use them; what if some object still depends on your "basically global variable"? If I were still a C++ developer I might be more concerned with the memory leak issue. Also most alternatives to a singleton class will likely end up in the same boat (as far as memory management) as the intention is usually a long living class anyway. But... your not married to it, and you have control if you find another way besides singleton.
2. The singleton pattern breaks the "S" in Robert Martin's "Solid" - principles of object oriented programming mnemonic. This in my opinion is true. You are creating a class that is concerned with performing some function, and it is concerned with making sure it only gets instantiated once. A factory would be a better place to regulate how many times a class can be instantiated. This leaves your code flexible for the future, less tightly coupled, and better suited for unit testing.
3. Singletons are a lazy, procedural approach to adding globals
1. It has been suggested more than once that the gang of four patterns (while having many greatly useful patterns) were introduced to cover holes in the language du jour of the day C++. Was singleton one of said hole pluggers or was it an attempt to make procedural developers at home if they were not be able to wrap their heads around good OOD? I don't know. It's all speculation, and I wouldn't know where to hunt down the true story. However the idea of patterns defined 20 years ago in a programming landscape that looked like C++ was the present and the future, might have been defined around the strengths and weaknesses of said popular language doesn't feel too far fetched. Is it true? Who knows, who cares. All I care about is; does this pattern work well in modern OOP.
4. Global state effects the ability to write deterministic code
1. It's a fact that global state makes code less deterministic. Lets use testing as an example One test might change the state of this global, affecting the outcome of the next test to run. Therefore a unit test could have different results and different side effects just based on the order unit tests are called in. (Kinda complicates isolated unit testing doesn't it?)
2. One of the articles I linked above points out that it is not just the singleton class in question that is global. Most singletons are complex objects holding references to other complex objects. Thanks to their transitive relations all those reference instances are now part of the applications global state.
5. Is there a situation where a singleton is the best solution?
1. Example attempt to answer to this question on dofactory.com's forum: "A few days ago, I had to implement holding a list of loaded assemblies and its references during program-execution. As this is a bigger project, we're talking about 150 dll-files to look at. In that case, I just didn't want to load the same data again and again whenever I need to get one of these assemblies. Therefore, I used a singleton-class, which creates this certain list on its first call and holds that values until the application gets closed."
1. This list could be a lazy loaded static member of an instance class. But, isn't that still global state? Yes. 
1. Common uses
1. A logger class. Many brave warriors have tried to use a logger class as an example of a good use case for a singleton class only to have many others easily refute it as a bad example. So rather than come up with a new counter example I'm just gonna quote someone else. "Today, I might think that I need only one logger instance. But what if I realize­ tomorrow that I need two? That’s not so far fetched. We may have one log we write ad-hoc messages intended for debugging purposes, solely to be read by devel­op­ers, and another for­mal­ized log, where structured mes­sages are writ­ten when pre­de­ter­mined events occur, so that the appli­ca­tion can be mon­i­tored in pro­duc­tion. Sure, we could define the two as com­pletely sep­a­rate classes, and then we’d only need one instance of each (but then we’d start dupli­cat­ing code). Or we could use the same log instance to write to both logs (but then the log­ging code would become more com­plex, hav­ing to inter­leave two sep­a­rate and non-overlapping logs. Once we’ve accepted that an appli­ca­tion may need more than one log­ger, shouldn’t we do our­selves the favor of ensur­ing that our log­gers can be instan­ti­ated more than once, just in case it turns out to be the right thing to do? We’re not even adding any com­plex­ity, there’s no cost asso­ci­ated with this. On the con­trary, we’re remov­ing sig­nif­i­cant com­plex­ity. Thread-safe sin­gle­tons are sur­pris­ingly hard to get right. Depen­den­cies between sin­gle­tons are tricky and cir­cu­lar ones can cause them to blow up in all sorts of fun ways. And let’s not even get into how to han­dle any­thing our sin­gle­tons might do while the appli­ca­tion is shut­ting down. What if the data­base sin­gle­ton tries to write a sim­ple “good­bye” log mes­sage to the log sin­gle­ton? What if the log sin­gle­ton got destroyed before the data­base one? Ouch."
2. A data access class. My personal experiences with singleton classes. In nearly 12 years of professional development I have released 3 singleton classes into production. All three times it was to serve the same purpose and all three times I concede it was probably the wrong choice. In these three occasions I was writing a class that instantiated and gained access to some form of API that had specific credential and configuration settings. All three times my singleton wrapper would be used throughout the application to garner some form of data access using these API's (whether it be an ORM or a Rest API). In all cases there were to be different domains for these API's, and inevitably different permutations or completely different API's all together. So why make my local wrapper global. True I didn't want to rewrite the code to instantiate and authenticate. But why make it global? So what if different parts of your application authenticate. Is there a RESTful API that cannot handle that? Is there an ORM that cannot handle that?
3. A config class. This is one of the easiest to refute. You have config data and it gets shared amongst various layers of your application. You create a singleton class that grabs config info out of storage and holds the data for your various layers to utilize right? Wrong, what if you want to change the config values in a layer of your application that takes user input for changing config values. You have the changes and have yet to persist them to storage. Now all your layers have the changed values. But persisting to storage failed or the user changed their mind. Meanwhile some other layer has acted on those changed values. Example: The user went into the config UI and changed logging from "verbose" to "standard". Some other layer who has a reference to the config singleton has an exception. It goes to log its exception and shows standard logging details instead of verbose. The user changes their mind and cancels the change. But it's too late they've missed out out on verbose logging for that exception. Some might say there is an easy fix for that have the config management UI write to a different object representing the config object, and have a method inside the singelton config object that takes this other config object. First of all that certainly isn't a DRY approach and for all intents and purposes the behavior you are achieving here can achieved in a way that allows more flexibility. Create a config object that can be instantiated. It holds the members that define your config attributes. Expose your CRUD operations. What about reloading the config info over and over by each layer. This is where dependency injection comes into play. Via constructor injection or setter injection your class can require the config object. Here is an example config object implemented in Ruby. (Not my strongest language)At first it would appear there is a problem. A doesn't know B persisted new config data. However its not a problem, its just the lack of a side effect. If the config were a singleton A would immediately have the new data, but what if that creates an undesirable side effect for A? Should B changing its object state cause side effects in every layer of your application who is concerned with config values? You may have coded anticipating this side effect, but what if there was a situation that didn't want it? Or a situation you didn't think about? Suppose A is currently in the middle of an operation based off the config values it originally loaded. As a developer you may want the choice to load the new config values or you may want to hold off until you have finished your current operation. Would not the Observer pattern help you here? Your layers will get notified, and then you get to make your own choice.
1. *Note of course there is still global state going on here. It's access is controlled but it is there no the less.
6. What is the real difference between a singleton class and a class with all static members?
1. In a nutshell; one gives you back an object, the other only gives you access to methods. A static classes constructor is private cannot be called, and takes no parameters. Both can contain state. A singleton can implement an interface and enjoy polymorphism.
2. Both patterns are inherently non-thread safe. You have to implement safeguards to ensure thread safety. If you are developing in C# there are some really tried-and-true instantiation related thread safe singleton implementation examples. If you are in Ruby using Ruby's built in singleton functionality instantiation/constructor thread safety shouldn't be a concern either. But that does not guarantee the methods in these two types of classes are thread safe. You would have to wire that up as well.
1. One could argue what pattern or constructs are inherently thread safe without explicit safeguards. (immutable types). The argument with this pattern is there is an easily viewable and understandable issue of thread safety that arises with every implementation surrounding constructing a singular global object or its methods.
2. Using singletons incurs overhead. (see CPU cycles) You are calling the instance accessor every time you access members of a singleton class.
7. If singletons are good enough for Yukihiro Matsumoto and the Ruby language why aren't they good enough for me?
1. Singleton pattern versus singleton class. Not to be confused, these were touched on earlier in my post.
2. Ruby's built in features accomplish a lot of interesting behaviors like assigning a method to a single instance of an object. Ruby unlike other languages does not have a class structure that can contain instance methods and static methods. This may be in part due to the fact that the classes we define using Ruby are actual instances of the "class" object, and static methods are instance methods on an unnamed singleton class instance who exists in the inheritance hierarchy just before your actual class. All this is to say that the "everything is an object" nature and meta-programming abilities have led the Ruby team to use singleton objects within their class implementation. But are those singleton or eigenclasses, or metaclass (Some argue that the actual "Class" class is the truer metaclass save that for a different post) objects following the Singleton design pattern? Do they introduce global state all over the place constantly? How about a test? Why? This may go back to the time period they built in these features. Maybe less was known and observed about this pattern back then. Could they accomplish the same features without the use of the singleton pattern? I would like to think so, but I have no definitive proof. However, our choice to implement business domain applications using the Singleton design pattern should not default to "why not" just because the Ruby language incorporates them. Its difficult to tell a long time Ruby'ist to rethink their usage of a pattern that gets used abundantly in the implementation of their chosen language, but no code design is perfect, even the code written by industry legends.
8. Alternatives to the singleton
1. Mono­state pattern
2. Dependency injection

conclusion: A class that exists singularly as opposed to a class defined using the singleton pattern. Have a single class if it suits your needs, just don't ensure it is single by the use of a pattern that introduces unnecessary dependancies and global state. We're never going to get away from global state completely. The dire to have global state doesn't come magically out of thin air.

Preserve image aspect ratio

I've been meaning to put some code snippets in here. Nothing earth shattering just little handy coding bits.

A while back I spent some time in xaml trying to maintain image aspect ratio. The images that I'm binding to vary in size and ratio. I knew the area they would be displayed  would have a height around 200-220 pixels. This is what I ended up doing.



Only bind to the dimension you don't know, width
Create a multibinding value converter. You do that by implimenting IMultiValueConverter.
Because these converters take object parameters, and I don't know who may use them after I am off a project; I always check the types of each param.

The math for getting ratio is just width / height.

If you know what height you want, then take the height and multiply it by the ratio
If you know the width take it and divide it by the ratio.

Builder Pattern

*Disclaimer these writings are for my own learning purposes not as advice to others. If any part is incorrect please feel free to constructively discuss.

Previously I discussed
Strategy Pattern
Factory Pattern
Abstract Factory Pattern
Observer Pattern
Facade Pattern

Today I'll be discussing the Builder Pattern. I usually don't include UML because they are all over the web and haven't brought that much extra value to my write-ups. But this pattern has a few more parts then the previous patterns I have dicussed, and I feel it will help.

Straight from Wikipedia

The builder pattern is a creational pattern, and the point of it is to encapsulate the complexities of creating a
complicated object. The Builder pattern can also create variations of the complex object.

At first I thought this pattern sounded familiar. It sounded a little bit like the Factory or Factory Method Pattern or maybe Abstract Factory. Its pretty different though and a short definition of each should help illustrate.

Factory - Client calls factory and factory directly returns one of many different types based on the parameters given to it. The clinet doesn't know what it's getting back only that the object inherits from a given abstract class or interface.
Factory Method - Client has an instance of an abscract factory wich defines an abstract method for creating products, but the client instantiates the factory with a conrete instance of that factory. The concrete instance impliments the create method and can create one of many types of the product but only return the parent class or interface that represents the product.
Abstract Factory - There are some similarities to the Factory method pattern here but just remember the Factory method pattern only returns one parent type to the client. In Abstract Facotry the client has a reference to an abstract factory, and instanciates it with a concreate factory that implements the abstract factory. The concrete factory creates concrete products and returns multiple parent types to the client.

Builder Pattern - An abstract builder class defines abstract methods for creating various parts, and a method for returning a product. Concrete builders implement the abstract builder class and are responcible for building the parts, keeping track of their representations and providing a method to return the final product. A director class provides a construction method that calls the part building methods in the concrete builder classes. (In what ever order or with what ever parameters it decides on).

Below is my car demonstration of the Builder pattern. The source code along with all other pattern examples can be found here

















 

Part 2 Entity Framework 5 using the POCO pattern, a data first approach, for a Table Per Hierarchy model

*Disclaimer these writings are for my own learning purposes not as advice to others. If any part is incorrect please feel free to constructively discuss.

Part 2: MVC 4 with existing context class, and an abstract base type

Previously in Part 1 I discussed a data first approach to using Entity Framework, existing POCO's, and a table per hierarchy design.

With all that wired up I began to evaluate MVC 4.

Most MVC tutorials will have you start off with a table first approach or an object first approach. In the case of a table first approach you will end up with a datamodel (edmx file), and they will let EF code generate entity classes inheariting from EntityObject and a context class inheariting from ObjectContext. Some tutorials even advise that these entities might be a tad heavy for some uses. The alternative is to use DbContext by right clicking the model and choosing "Add code generation item", and selecting "ADO.NET DbContext Generator". This leaves you with a much more simplified context class inheriting from DbContext that just returns sets of each entity. You also get a much more stripped down simple entity class definitions.

I did not used EF code generation but instead defined my own entities and context class. (This will come into play later).

After adding an MVC app to my solution and choosing Razor as my view engine, I first needed to create a controller. In the "Add Controller" prompt you have the ability to choose a controller template that will wire up read/write actions and views for you. All you need is a model class and a context class.

If you choose this option you end up with a BookStore controller that already has the actions wired up for you.
You also get a class level instance of your context object instantiated in the controller.
Also notice the Get and Post verb comments added, (More about that later).



Also you get all your Razor cshtml views created for you.

This is enough to start the MVC application and view the default layout that comes with it.
Notice the RESTful URL style, and seperate views representing basic CRUD operations.

But there's a small problem. If I go to POST Or GET on one of my resources (create or an edit) I get this big ugly error.

Server Error in '/' Application.

---

Cannot create an abstract class.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.MissingMethodException: Cannot create an abstract class.



Why am I getting this? Pretty simple you cannot instantiate an abstract class. MVC has these ModelBinders, and I'm no expert but in simple terms they help bind the model information to the views. The default model binder may realize it needs a Book object but remember that discriminator thing we talked about in Part 1? The default model binder doesn't know how to make this discrimination. But we can define our own ModelBinder. To do that you need to derive from DefaultModelBinder. I'm only going to override the CreateModel method. Here is the result. 



But, we aren't done quite yet. I needed to tell the application to use this new binder before it worked correctly. You do this in global.aspx. 

Now that I have defined my custom modelbinder and added it to the global.aspx I can run the site. Its still just a very out of the box MVC 4 application. Notice the default edit and create views that got made for you. They don't reflect all the properties in our objects.

My enums are missing. This may be because of how we had to map the entities, but fixing is pretty easy. I added the following lines to use the DropdownListFor control in the html helper



This control requires a SelectedList of values. You can add the C# required to accomplish this directly in your cshtml page using the open and close tags like @{ }

Instead I added a static method to the book class. that looks like so.

Technically putting this functionality in the Book class is all kinds of wrong, and I would not actually do this in  a production application. The reason not to do this is I would be breaking the "separation of concerns" principle by bringing a UI concern into a domain object. This whole demo app could be structured so that my UI layer doesn't even know about my domain objects. A service layer could pass the UI layer nice flat DTO's. I could then add this method to the Book DTO. 

In the end I end up with something that represents all the elements ofthe book object I need to do a create. 

Obviously this is still not in a state I can really use. No one knows what ReturnPolicy value 3 means. To handle that I can decorate my Enum's with the Componentmodel.DescriptionAttribute and alter my EnumToSelectedList method so that the SelectedListItems text value pulls the description attribute. That's outside the scope of this blog but if I get around to writing it I will edit this blog and add it.

More to come in:

Part 3: MVC 4 view engine, Observer Pattern, and binding

Facade Pattern

*Disclaimer these writings are for my own learning purposes not as advice to others. If any part is incorrect please feel free to constructively discuss.

Previously I discussed
Strategy Pattern
Factory Pattern
Abstract Factory Pattern
Observer Pattern

The Facade pattern is widely used, and frameworks, and API's  are common implementers of this pattern. Often times a complex API or framework can have interfaces capable of large amounts of functionality and complexity. There may be too much complexity for the intended client to have to deal with. Stringing together a series of function calls for example. This is where the Facade pattern comes in to play. The Facade simply provides a layer of abstraction and or encapsulation by wrapping one or more complex interfaces to provide a unified interface showing only what is necessary to the intended client.

Considerations when implementing a facade layer:
Necessity: Is the facade really unifying complex interfaces for a client that doesn't need to use or understand all the functionality.
Forcing: Is the facade forced on the client? A facade should be bypass-able.
Adding functionality: Is the facade adding functionality? It shouldn't. Its primary focus is to unify a subsystem. It may collect some information to call several methods within the subsystem, therefore unifying functionality, but if functionality is added it might not really be the facade pattern, maybe Decorator instead.

Drawing from the automotive realm again Lets take the ignition process as an example. You the client want to turn the key and have the car start. You don't want to to think about the ignition switch allowing the electrical system to have power from the battery and in turn send electricity to the starter solenoid. The solenoid to send power from the battery to the starting motor. The gear on the starting motor to turn the larger gear on the flywheel. The flywheel to turn the crank driving the pistons. The vacuum from the pistons to pull atomized fuel and air mixture from the carburetor into the cylinders to be ignited by the spark plugs firing inside the cylinders... You just want your start method. You want to call it and let the rest of the stuff behind the scenes happen without your knowledge.

*Note it may be tempting to implement your facade as a singleton. Take a look at this interesting article discussing singleton, GoF patterns, their association with C++, and when is the best time to use a singleton. Its an interesting read. I'm not saying you shouldn't use it but just something of interest.

Here is that ignition example in code. (*Not how I would layout an object model for a serious project relating to an engines ignition process. But, its complex enough to get the point across for this demo).
The entire solution containing this project and the previously discussed projects can be found here.

//Ignition class


//Starter class and solenoid interface. Implements ISolenoidElectronic indicating it is a type of device that //requires a solenoid and should be expected to have a run method. (Not necessary for the Facade pattern //just makes this example make more sense to me.


//Flywheel Class


//Crank


//Carburetor


//Cylinder


//Sparkplug


//Facade class

Part 1 Entity Framework 5 using the POCO pattern, a data first approach, for a Table Per Hierarchy model

*Disclaimer these writings are for my own learning purposes not as advice to others. If any part is incorrect please feel free to constructively discuss.

Recently I wanted to become more familiar with Entity Framework, and MVC.
I'm going to discuss what I learned in a 3 part blog.

Part 1: TPH, Data First, with existing POCO's
Part 2: MVC 4 with existing context class, and an abstract base type
Part 3: MVC 4 view engine, Observer Pattern, and binding


Part 1: TPH, Data First, with existing POCO's

In the past I have worked with NHibernate, and Telirik Open Access ORM's. I have actually used Entity Framework a few times but in very simple scenarios. I follwed the wizards, and let EF create my entities.

I felt that this was pretty unrealistic experience, so I set out to make myself go through some pain so that I could learn the ORM better.

I decided that in many companies I would be asked to map to already existing data and object models.

I  already had an existing bookstore demo. This demo included an object model and a data schema. The two were not designed with this EF MVC demo in mind. So I thought I should have to jump through a few hoops to make it work. Well I did.

The model consists of one complex type (an abstract base class called book). And three POCO's (derived book types).

Here is the base class.


Here are the POCO's

Here is the very simple Book table.

I know its not a great idea to directly represent an Enum in a table by it's numeric value. But, I had read EF 5 has better Enum support so I wanted to put it to the test.

First I created an ADO.NET Entity Data Model. By default I ended up with something that looked like this:

First thing to do after generating the model was to set the "Code Generation Strategy" to "None". This stops EF from generating entities for you. *Remember I am plannig on using existing classes for my object model. Next I marked the Book entity type as Abstract.

The way the model is set now will work, but I don't like it yet. When I get a book out of my database I want it automatically casted to the derived type it really represents. I.E. I want many different types to map to the same table. This is called a "Table-per-hierarchy" design. There is also a Table-per-Type design but I'm not going to go into the differences. To accomplish the behavior I right clicked in the model's blank area, and chose "Add new Entity..." I'm guessing there is some string magic that goes on here so when typing the names of your derived types be sure to spell them the same way you did in your class declarations.
I created PaperBack, Magazine, and HardCover entities and set their base type to "Book"

The map looks like this now:

Almost done, but I need a way for EF to know how to map the derived types when fetching them from the DB. To do this I used a discriminator. In this case "BookTpye" is my discriminator. Right click on BookType in the Book entity, and choose "Delete from model". Now view the mapping details for the PaperBack entity. Click on "Add a condition", I chose BookType and the equals operator, and set the value to 3. This tells EF when the BookType value is three cast the object to PaperBack. I repeated this for Magazine and HardCover.

After that I mapped the Enum's. There is a new "Convert To Enum" option on the right click menu. It brings up a window that looks like this:





















And unlike earlier versions of EF this Enum mapping actually works.

Because I chose a code generation strategy of none I have no context class. I chose to implement a context class that inherits from ObjectContext. I could have also used dbContext, but I didn't.

The class itself is easy. The hard part came in troubleshooting various issues I had with my entity connection string's metadata. The problems I had there are a little outside the scope of this blog. I don't want to go too far off on a rabbit trail, but there are several great sites for troubleshooting issues of this type.

Here's the context class:

Here is a class that represents a service layer and exposes functionality of the context class.
Later on I could take this service layer and implement a more traditional SOA approach. I could set it up so that my DO's stay on one side of my service, and DTO's go out to my UI layer. I can set up some object validation in my service layer as well.




With these layers set up I can perform all the basic CRUD functions I need to make a sample MVC application.


As long as I was already in VS 2012 I went ahead and used MVC 4.

I will go over that portion in Part2.

Observer Pattern

*Disclaimer these writings are for my own learning purposes not as advice to others. If any part is incorrect please feel free to constructively discuss.

Previously I discussed
Strategy Pattern
Factory Pattern
Abstract Factory Pattern

Due to how events are handled one of the most widely used patterns in the .Net framework is the Observer Pattern.

The main point of the observer pattern is the allow objects to be notify of state change in other objects without being tightly coupled. At least thats how I would describe it to someone in my own words.

A more text book definition is:
"Defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically" Got that from OODesigns.

If you ever written an application using the architectural pattern's MVC or MVVM you've used the observer pattern.

As usual I will not go into a lot of detail defining the pattern, there's plenty of sites that have already done that. Below is my example, and here is the source code.

*Note this is a very basic example. I point that out because you can get quite a bit more specific in exactly what flavor of the observer pattern you implement. I believe publish / subscribe is the most widely used. Another is using a feature called an event manager or change manager, or Event Emitter/Target/Dispatcher. My example is a simple publisher / subscriber flavor. Also within that flavor you can implement notifications in a "push" or "pull" manner. Push being the subject always informs the observers of change, and "pull" being the observers can reach out and check for changes in the subject when they want. This example uses the Push technique.

//Subject interface
public interface IEngine
{
      string Name { get; set; }
      List<ISubscriber> Subscribers { get; set; }
      void Notify();
      void Attach(ISubscriber subscriber);
      void Detach(ISubscriber subscriber);
      int EngineTemp { get; set; }
}

//Concrete Subject
public class SilveradoEngine : IEngine
{
        public List<ISubscriber> Subscribers { get; set; }

        public SilveradoEngine()
        {
            Subscribers = new List<ISubscriber>();
        }

        public void Notify()
        {
            foreach(ISubscriber subs in Subscribers)
            {
                subs.Update(this);
            }
        }

        public void Attach(ISubscriber subscriber)
        {
            Subscribers.Add(subscriber);
        }

        public void Detach(ISubscriber subscriber)
        {
            Subscribers.Remove(subscriber);
        }

        private int _EngineTemp;
        public int EngineTemp
        {
            get
            {
                return _EngineTemp;
            }
            set
            {
                _EngineTemp = value;
                Notify();
            }
        }

        public string Name { get; set; }
}

//Observer or subscriber interface
public interface ISubscriber
{
      void Update(SilveradoEngine engine);
}

//Concrete Observer 1
public class EngineTemperatureDashLight : ISubscriber
{
        IEngine engine;
        public EngineTemperatureDashLight()
        {
            this.engine = engine;
        }
        public void Update(SilveradoEngine engine)
        {
            this.engine = engine;
            EngineTempWarningLight = this.engine.EngineTemp > 500 ? true : false;
        }

        public bool EngineTempWarningLight {get; set; }

}

//Concrete Observer 2
public class OnStarAlert : ISubscriber
{
        IEngine engine;
        public OnStarAlert(IEngine engine)
        {
            this.engine = engine;
        }
       
        public void Update(SilveradoEngine engine)
        {
            this.engine = engine;
            OnstartHasAlerts = this.engine.EngineTemp > 500 ? true : false;
        }

        public bool OnstartHasAlerts { get; set; }
}