|
Take a behavior. Pull the nouns (classes) and what they are told to do (methods). Finally, I don't need to know how you do what you do, that is your problem, not mine. Very oversimplified, but that is what it is. See the pieces that you are playing with, and they can receive messages asking them to do something, this will be method calling. This describes objects and message passing. Sometimes different parts need to respond to the same message, think on a car: push pedal, it means to release gas into the engine to the gas pedal, but it means squeeze the wheels to the brake pedal. Welcome to polymorphism. And when I press a pedal I don;t need to know how it accomplish what I am asking to do. In a gas engine means releasing more gas, but in a tesla it means reducing resistance between the batteries and the motors. That would be encapsulation. And by the way, think also in the instrument panel, they don't go asking then engine "what are you doing now", instead they just display whatever information the engine is volunteering. The engine makes a little wire spin, and the speedometer shows the speed. That would be the bases for the observable pattern. There are others, but this one helps abstract the engine it self from the car body. In other words, the UI should be nothing but one example on how a user can interact with the engine, for this you need to build your engine without thinking in ui. This would be how to structure an oo app. |