Internalizing - software design

I attended the cfObjective conference where lots of good new content was presented. The sessions were packed with details and concepts. To really grok or get something, you must internalize it, put it into your model, see it the way your brain likes it. For me, writing it down is the best way to achieve that. I also like to talk out loud, even more than just thinking about it in my head. Strange i suppose, but verbalizing does help, writing helps more. This is one of the main motivations i have to blog stuff. One of the primary concepts at any software engineering conference would be around OO programming. Object Oriented. That means thinking about things in your problem domain as object, not data containers. I work in education, so i see things like, assessment exams, scores, resources, standards and assets. Think of them as objects that have attributes that define them and actions that they do. Think of the attributes as things that describe the object and the actions as things the object can do. Think of the object and what it does as its interface. The actions start to inform the interface. Think of the interface as the way other objects, including you, see the object. The interface becomes like a public face that is exposed to the outside. You and other objects can talk to and modify the object through its public face.

Design patterns

Once you start to build objects you see commonality among them and the need to predict or manage their interactions. Design patterns help the architect to build predictable manageable scalable solutions. In other words, use patterns to help build great flexible code.