BestPractices Technical Practices: Never Return Your Data No Getters That's the normal form of this technical practice. No Getters There's some uncertainity around what "No Getters" means. OK, there's two versions of it. Yegor Bugayenko in Elegant Objects Vol. 1 says, It's all about prefixes That's section 3.5.
TDD µObjects: Unit Testable UI Interactions This is a follow up to the Hotel Pattern which I've pretty much abandoned, though it's concepts and ideas have evolved into my current practices. It ties into the Interface Overload mechanism I discovered as well. Though, neither fit well into the new µObject
XP Patterns: Null Object I've covered never having nulls and that's what the NullObject pattern is here to help us with. The NullObject pattern is one that I tried to implement earlier in my career (mostly after reading about it) and never managed to get it to stick.
microoop My Thoughts: Pass through vs Base class A conflict that has come up a few times is using composition and a pass through or a base class I favor pass through; I write it that way Everytime. The other engineer on the project favors a base class. Here's an example of
BestPractices My Thoughts: 'Interface' isn't harmful My thoughts about Object Oriented Programming has evolved over the years. Especially in the past 6 months. My development of MicroObjects has caused a lot of thinking about Object Oriented Programming and how to develop better and more maintainable software. A lot of great
microObject µObject Poker: Scoring a Hand I found I'm not a huge fan of the video. I don't tend to put a lot of time and effort into each post; it's an opportunity for me to share research and experimentation with the world; as well as give myself a searchable
µObjects M:TG Game - Event Bussing I've been pondering how to do some µObjects in a more intelligent system for a while. I'm going to try to use Magic: The Gathering for this. Much like the poke one; the idea here is to explore µObjects and how they can be
BestPractices µObjects: Being CLEAN Beyond Legacy Code's CLEAN I've read David Bernstein's Beyond Legacy Code and clearly enjoyed it. :) One of the concepts he expands on in the book is "Clean Code". He takes this and makes it into an acronym, "CLEAN code". Well.
TDD µObjects: Being Nonredundant Redundant code is code that changes at the same time for the same reason. Part of object oriented programming is limiting change to a single place. If it changes, it should change in one place. How do µObjects encourage being nonredundant? By focusing on
TDD µObjects: Being Assertive Being assertive is about being self-responsbile. Being assertive is about an object being lazy. This also has the object doing all behaviors for the state it holds. It follows from encapsulation that an object will be assertive. How do µObjects encourage this? µObjects do
TDD µObjects: Being Encapsulated Encapsulation for objects is, IMO, how well the data is hidden. Encapsulation is only acting via behavior from an object. Never getting data and doing something. A well encapsulated object is also a very cohesive object. These traits tend to enhance each other. µObjects
TDD µObjects: Being Loosely Coupled Loose coupling is about how much a class knows about the objects it's using. The less a class knows about the components it is using; the better the decoupling. Or they are loosely coupled. How do µObjects fair with being loosely coupled? That's what
microObject µObjects: Being Cohesive Cohesion for objects is how well the behaviors in the class belong together. Some very non-cohesive behaviors would be multiplying two numbers and splitting a string. Multiplying and Raising to a power can be very cohesive behaviors. How do µObjects do cohesion? That's what
TDD µObjects: Pizza Shop - Review The Pizza Shop The Start More µObjects New Requirements Calzoned The Final I started the Pizza Shop example to show how to apply µObjects in code; Using a very similar process I do in production code. From there, working through the changes and applying
TDD µObjects: Pizza Shop - Final Changes These are the final changes for our Pizza Shop. I think a few will be interesting to implement; but nothing stands out as a "how would I...?". µObjects make it very simple and quick to get new functionality in cleanly. One of
TDD µObjects: Pizza Shop - Calzoned! The pizza shop is expanding it's offerings! CALZONES! We'll do a 1/2 calzone and a full calzone! $8 and $14 respectively. Based on how we did the Medium pizza last time... Not expecting much work for these. Which... THAT'S THE POINT! µObjects make
TDD µObjects: Pizza Shop new Reqs Pizza's going great! We've got our system in place; we've cleaned up our code! We have µObjects everywhere! In my ideal; there aren't enough tests. All behavior is still covered; test coverage is at 100% for everything except our Money object. Which was pulled
TDD µObjects: Pizza Shop - More µObjects We return to our pizza shop to refactor. I like to check out my "TODO" or "Smelly" comments and see what I can clean up. I normally go for "TODO" as most tools have a way to list
TDD µObjects: Where our code meets the user There's a couple types of places where the code we write interacts with the code someone else wrote. This could be another team, a 3rd party library, or the operating system. When we interact with these components, we're tying our code to their code
microoop µObjects: Where our code meets their code There's a couple types of places where the code we write interacts with the code someone else wrote. This could be another team, a 3rd party library, or the operating system. When we interact with these components, we're tying our code to their code
microoop µObjects: Temporally Coupled Decisions into Chain of Responsibility µObjects: By Example - Playing Cards I've been a bit remiss on good code examples for µObjects. I've been planning a few things; never got them done. Almost entirely because I'm lazy. So... I'm going to try a simple example of the application of
microoop µObjects: Small and Focused Our goal as software developers is to produce code that can be easily maintained. This is frequently a challenge; as writing good code is hard. µObjects is a way of Object Oriented Programming that I've found gives us this. There are a number of