I have seen good developers, nay great developers break encapsulation and even more interestingly, they didn't even know they we're doing it! How is this even possible? On this piece we shall explore this phenomena.
First, lets look at what encapsulation is. Encapsulation is one of the four pillars of Object Oriented Programming commonly abbreviated as OOP. The others include inheritance, polymorphism and abstraction. The principle behind encapsulation is hiding of data and behavior of an object to prevent it from external corruption and reduce overall complexity.
The language specific implementation shall be left as an exercise to the reader. Please check your language documentation.
Semantic encapsulation is broken when we depend not on the public interface offered by the object but on some prior knowledge of the implementation.
This concept is rather hard to grok, as such will give some few examples.
In normal use of this code we would simply call $a->performFirstOperation() safe in the knowledge that the requisite initialize() operation will be called.
Do you see the gotcha there?
To protect ourselves we would need to change the method type to either protected or private that would then ensure initialize can only be called from outside the function.
What about that one? Did you see anything of interest?
Well in this case the User class is very intimate with the Database class, knowing not just how to connect to the external service but also how to check if its connected to start with!
Now for our final example.
In this case we initialize a Class B from Class A where we modify its behaviour or data in some way that is useful to our business rules. However since we already know that the Class B is already initialized we can now use it later on in our code safe in the knowledge that the class has the right data.
This again is a demonstration of how prior knowledge of implementation is used to break encapsulation.
I believe third time's the charm and we now have an even better understanding of encapsulation.
Have you encountered the issues highlighted above in your code base? Talk to us in the comment section below.
A lot of methodologies can not make claims of making your team work 400% faster. Scrum however is not one of those.
In the 22 years of it's existence this way of working has proven particularly effective in almost all human endeavour in which teams we're involved. Yet it's effectiveness is matched only by its simplicity. If you have not been using Scrum in your projects then now is the time to start.
In this piece, we will look into what the process entails so you can give it a spin in your own team. You will note that, we assume what you are working on is a software project thou the principle can be easily replicated in other disciplines.
At its heart, Scrum is all about the people. Roles defined by the methodology are not meant to enforce rank but provide value, as such all team members in a Scrum team are considered equals.
Power without direction is useless. The product owner is in charge of the vision of the team, in short he/she is to ensure that the effectiveness granted by Scrum is not wasted on busy work but rather contributes to the business value of the project.
The PO can then act in lieu of the client on the day to day activities of the team.
This individual should be well versed with the dynamics of the team and fundamentals of Scrum. He/she will lead meetings, track progress and ensure that the rest of the team is living up to the ideals of Scrum.
When problems arise, as they will. The Scrum master is in charge of taking care of them ensuring the team is not affected by the minutiae of office politics.
The materials needed to start out are readily available and can be found in any store with office supplies.
Each and every single thing that can be done by the team is written on a sticker. This are actionable items, i.e stories that can be converted to software.
This works because while humans are terrible at absolute estimates, we shine on relative ones.
We all love the feeling of getting something done. That's exactly what the sprint is targeted at.
The team selects items of highest priority to get done within a certain period. This period is ideally two to three weeks. The items of highest priority are then moved to this list.
During the sprint all items on the sprint list must get done. In this case getting done means having the entire feature/story fully completed and working. In fact at the end of the sprint the team must demo their work to other stakeholders in the project including the client and representative of the end user.
Critical at this stage is that the items on the sprint don't get added. That is no new feature can be requested. If it is, then its added to the nacklog.
The daily stand up is a meeting like no other. The stand up in the name is literal, the meeting should be held with everyone standing up. This should discourage any would be "hearty speakers".
What did you do yesterday to move the sprint forward?
What are the obstacles in your way?
This ensures everyone is has full information on progress of the project. The Scrum master leads this session and should take care of any external or internal obstacles to project progress.
At the end of the sprint the team should have a demo ready for the client showing what has been done thus far in the project.
Once the demo is complete a review of how the sprint went should be done with the purpose of identifying inefficiencies in the process. The team can then strategise on how this challenges can be addressed on the next sprint.
The identified improvements should take priority in the next sprint.
So there you have it, Scrum in a nutshell, kind of simple isn't it? Taking the principles outlined above into practice will be the biggest challenge that your team will face.
Will you take on the challenge? Talk to us on the comment section below.