pros

Caution signs for considering an iterator or a materialized collection
C# / .NET / dotnet / Programming / Software Engineering

Beware of These Iterator and Collection Traps

This article is not set out to try and persuade you, the reader, that either using an iterator or materialized collection will universally solve your problems. Both iterator and materialized collection usage can be used to solve the scenarios that we'll be looking at, but both will come with a different set of pros and cons that we can further explore. The purpose of this article is to highlight scenarios based on real world experiences where either an iterator or materialized collection was being misunderstood, misused, and ultimately leading to a pile of headaches. As you read this article, if you find yourself saying "Well, sure, but they should have..." you're probably right. The problem is fundamentally not the usage of an iterator or the materialized collection, but not understanding how to consume them effectively. So I hope that when…

0 Comments
February 22, 2023
C# / .NET / dotnet / Programming

What Makes Good Code? – Should Every Class Have An Interface? Pt 2

Should Every Class Have an Interface? This is part two in the sub-series of "Should Every Class Have an Interface?", and part of the bigger "What Makes Good Code?" series. Other Peoples' Code So in the last post, we made sure we could get an interface for every class we made. Okay, well that's all fine and dandy (I say half sarcastically). But you and I are smart programmers, so we like to re-use other peoples' code in our own projects. But wait just a second! It looks like Joe Shmoe didn't use interfaces in his API that he created! We refuse to pollute our beautiful interface-rich code with his! What can we do about it? Wrap it. That's right! If we add a little bit of code we can get all the benefits as the example we walked through originally. It's…

1 Comment
January 3, 2016
Programming / Software Architecture / Software Engineering

API: Top-Down? Bottom-Up? Somewhere in the Middle?

A Quick Brain-Dump on API Desgin I'll keep this one pretty brief as I haven't totally nailed down my thoughts on this. I still thought it was worth a quick little post: When you're creating a brand new API to expose some functionality of a system, should you design it with a strong focus on how the internals work? Should you ignore how internals work and make it as easy to consume as possible? Or is there an obvious balance? I find myself trying to answer this question without ever explicitly asking it. Any time I'm looking to extend or connect systems, this is likely to come up. Most Recently... Most recently I started trying to look at creating an API over AMQP to connect my game back-end to a Unity 3D front-end. I had been developing the back-end for…

0 Comments
January 1, 2016
Game Development / Personal Project Updates

ProjectXyz: Enforcing Interfaces (Part 2)

Enforcing Interfaces This is my second installment of the series related to my small side project that I started. I mentioned in the first post that one of the things I wanted to try out with this project is coding by interfaces. There's an article over at CodeProject that I once read (I'm struggling to dig it up now, arrrrrghh) that really gave me a different perspective about using interfaces when I program. Ever since then I've been a changed man. Seriously. The main message behind the article was along the lines of: Have your classes implement your interface, and to be certain nobody is going to come by and muck around with your class's API, make sure they can't knowingly make an instance of the class. One of the easiest ways to do this (and bear with me here, I'm…

2 Comments
November 12, 2014
C# / .NET / dotnet / CodeProject / Programming

Yield! Reconsidering APIs with Collections

Yield: A Little Background The yield keyword in C# is pretty cool. Being used within an iterator, yield lets a function return an item as well as control of execution to the caller and upon next iteration resume where it left off. Neat, right? MSDN documentation lists these limitations surrounding the use of the yield keyword: Unsafe blocks are not allowed. Parameters to the method, operator, or accessor cannot be ref or out. A yield return statement cannot be located anywhere inside a try-catch block. It can be located in a try block if the try block is followed by a finally block. A yield break statement may be located in a try block or a catch block but not a finally block. So what does this have to do with API specifications? A whole lot really, especially if you're dealing…

0 Comments
December 26, 2013

End of content

No more pages to load