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
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
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
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
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
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
µ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
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
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
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
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
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
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
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
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
20180110 µ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
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
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
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
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
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.
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