Example: Getting Data Back From An EventHandler

Background I previously wrote about why I like to use events here and here. I figured it would be appropriate to illustrate a simple case where you can delegate decisions between functionally separate parts of code (say, between an application layer and a presentation layer). If you're well versed in C# and .NET, this might put you to sleep. If you have no idea what I'm talking about, hopefully this will help. By the end of this, hopefully you'll have a better idea for how you can use an EventHandler to pass data/state back through an invoked event... And don't forget to check out the code! The Scenario Let's assume we have a layered application, which is usually my go to. I might have three layers: one for data persistence, one for my business logic and one for interacting with…

0 Comments

Why Events? Decoupling.

Background Previously, I wrote about how events provide you with flexibility in your code. If you take on an event-based paradigm, you can view your system as a group of components that have events execute when certain conditions are met, and less of a procedural view where X always must occur after Y. But what else do events let us do? Decouple your architecture! We all know decoupling is a beautiful thing, so let's see how it's done.   How Events Decouple Your Code So the big question then is, how? I'd like to start by providing framing an example architecture. If we assume that we have code that is decoupled by major functionality, we might have some sort of layered architecture. This could mean that we have three layers: presentation, application, and data. These layers would be responsible for…

0 Comments

What Makes a Good API?

Background My position at work allows me a bit of freedom in how I code and more importantly, influence how others code. I was recently having a conversation with a colleague about what I think makes a good API, from a high level. The context of our discussion was pertaining to developing a C# based API, but this really applies to any object oriented API. I had two key points that I wanted to address, and while they're not the only important things, I believe they're often overlooked. The first thing is how people will use your API, so how they will call methods and use the results. The second point was about how people will implement your API should they want to extend your work and implement their own classes. Here's what I was trying to drive home:   Usage: As a programmer,…

3 Comments

End of content

No more pages to load