When I started my journey with Object Oriented Programming I quickly found out many tutorials and trainings, which showed how to use OOP structures in code. Unfortunately, most of them demonstrate only how to write your first own class, interface. How to create an object. All of this was about language “grammar”, about key words, the way how to create structures used in OOP, etc. Yet, somewhere authors lost the most important information to share - why we decide to do this instead of looking for other solutions? Why an interface contains nothing more than abstract methods? Why all of those are public? What for are those visibilities? And so on...
Tuesday, December 30, 2014
Friday, December 5, 2014
What diagrams can tell you
let’s talk about diagrams
I know that many of you may feel sick at the very thought of UML’s, but, whether you want or not, in certain moment of your career you will have to work with them and, what’s more frightening, there’s a chance that you will have to create them on our own.Why so many programmers don’t like diagrams anyway? Well, I think it’s because of some kind of unwillingness towards something unknown, in this particular case – to the language which is unknown for us. Because that’s what UML really is, a language that isn’t understandable by all of us. It’s a language that not each of us “speaks”.
However, today I don’t want to write about this.
It happens in each language, sometimes we can know essence without deep investigation of details. We just know, that in each sentence there are less important words, as well as those words which matter most.
It’s exactly like with those sentences with word “but” inside. We all know that everything that stands before “but” is irrelevant and the real sense is just after :) And that’s what I want to describe today: cases, when you don’t have to look deeper to understand the context. A quick look at a diagram is enough to get the hang of what is the most important in it.
Subscribe to:
Posts (Atom)