"Layer of Abstraction" Confusion

"Layer of Abstraction" Confusion

• Joel

  What they referring to with the "level of abstraction" is that you're not dependent upon handling all the events that happen. for example

  Imagine you have an application, you add a function that you want to execute when the pageloads.

  private void Form1_Load(object sender, EventArgs e) { }

  As you can see this is a standard function that runs when the Form1 loads, because its called "Form1_Load", however the name has NOTHING to do with why THIS is the specific function to be called when the form loads, you could call it "Stampede" or "Dixie Twist", the compiler doesn't care.
  
  What it DOES care about is the eventhandler, and if you take an example at the Form1.Designer.cs, you see alot of Designer Generated code, this one in particular

  this.Load += new System.EventHandler(this.Form1_Load);

  Now this is very simple, look at it like a compiler does, you see the new statement, so that means that there is a new object being made, and later you see that its of type "System.EventHandler" and it carries a parameter, the functions parameter type is a function, so we pass our function into the eventhandler for the this.Load
  
  So we have a new object called this.Load which is a eventhandler, which will be called when ever the code that created that event wants to, and here you decide, "Okay I want THIS function to be called, when THAT event is called!"
  
  

  
  
  

• Andy Craig

  Thanks very much for the replies. That's cleared up quite a lot of misconceptions on my part; some of it was so obvious I'm surprised I didn't really get it before. It's something that has been bothering me for quite some time and something I've wanted to rectify for that same amount of time.

  So if I understand these replies correctly, am I right in saying that a layer of abstraction "abstracts" away the details that don't need to be visible outside of the class, so events are a form of interface Also, would this mean that this type of construction is a form of data hiding Am I correct in my thinking here

  Thanks again for taking the time to reply to me.

  Edit: Oops, ignore the other one. ;-)

  
  

• PabloK

  Everyone is a rookie about something…

  
  
  

• Nishchal

  Thanks Michael (and the other posters), that's really cleared up a hell of a lot for me. I think all I need now is a bit of practice in using them.

  Cheers, and it's nice to see no noob bashing here! Great forum!

  
  

• FDN

  Typically, abstraction layers are interfaces, abstract classes, or rather 'abstract implementations' that allow the user to program against an 'abstraction' of a class rather than the class itself. If the class changes, the code still works because you program against the interface/abstraction rather than the class.

  The abstraction layer you get from events (which should always be public, I don't know why a class would need to be informed of its own event), is that it produces a Publisher/Subscriber scenario.

  A common example is a clock. The clock publishes an event, say, second-tick, when a second has gone by, maybe it publishes another event, called Alarm, to tell its subscribers that it's some particular time.

  The subscribers don't know and don't care how the clock actually works, it knows that the events it subscribes to has a certain signature... usually something like (object sender, EventArgs e) where e can also be a class that derives from EventArgs...

  The subscriber can not evoke the event itself (unlike public delegates), so it subscribes to them and is only alerted when the publishing class says, "okay, here is an event with some (or no) information".

  Also, as long as the signature of the event stays the same, the clock can change its implementation and the subscribers will never know or care.

  It represents a one to many pattern, where one class can notify multiple classes of some raised event, where all parties remain ignorant of the implementation behind the event, or how the event is handled by any of the subscribers.

  And yes, it is a major feature that you should definitely take advantage of.

  
  
  

• Jeremy Delozier

  One of the chief goals in object oriented programming is encapsulation, hiding the implementation (details) of the class from the users of the class.

  An interface itself is more like a contract that states that a class or struct that inherits a particular interface must provide the method signatures, events etc, that the interface defines. The interface says what methods and events should be implemented, but not how.

  Events provide a means to publish a state change without the subscribers having to know how the class that raised that event works, in fact its preferable that it be ignorant of like you say the details of that. It's a type of detail-hiding or abstraction, but not an interface.

  It might not be entirely apt to say abstraction when dealing with events (you can be using very well known and defined objects rather than truly working with a 'front end' to an implimentation), but it is worth pointing out that  the publisher that fires the event is not dependant on the subscriber(s) which respond to the event, those two actions are said to be decoupled in this case because neither is dependant on the other's implementation.

  
  
  

• HomerJS

  “another layer of abstraction” means essentially, “to make a thing easier to think about or work with”.

   

  E.g.: we “know” that our software is just a bunch of 1s and 0s.

   

  The first abstraction is “machine code”, or “assembly language”, which “abstracts away” the 1s and 0s.

   

  The second abstraction is “a programming language”, which “abstracts away” the machine code.

   

  Etc.

   

  A similar expression you might come across is "another degree of indirection"

  
  
  

• CGantz2000

  Events (and some other aspects of C#/Programming in general) are one of the things that when you get it and use it, you go like "Aha!" and rarely forget it...

  .NET programming is based HEAVILY on Event based subscription, so this will help make alot more sense when your apps blow up.

  
  
  

• z1000

  Hi,

  As I see it, the .NET Framework offers you events to signal methods that can be called upon when an event occurres in your code (or in any code for that matter).

  If you look at a Button being clicked, the code that is being executed by the system, capturing the click on the button, will raise an event. Every piece of code that has subscribed to the event that is being raised will be triggered. In this way a "real life event" can trigger one or more subscribed methods.

  The best thing about events is that if the events are declared public, you can subscribe code outside the class or even outside the assembly that exposes the event (and eventually triggers it) by using delegates. In that way you can make you code responsive to events that happen in another component. If you write your own code with your own events, you can enable other developers to subscribe on events that occur in your code.

  Some more info about events:
  http://msdn.microsoft.com/library/default.asp url=/library/en-us/csref/html/vclrfeventpg.asp

  I hope this helps.

  Eric.

  
  
• "Layer of Abstraction" Confusion