#oop principles

Can I just give you an honest rant for a minute about my frustration with some of the developers I’ve worked with in the past? OK? good. I was discussing the principles of OOP with a Java student a few minutes before writing this, and it made me reflect a lot over people I have worked with in the past, and the struggle it creates when a developer’s code is unmaintainable.

So, for those who have worked with me in the past, they’re fully aware how picky I am about code maintainability (with the other principles of OOP supporting that specific ethic, such as one object only having one responsibility and such). I’ve always said if I need you to comment your code to even grasp what it’s supposed to be doing, then it’s too complicated and needs refactoring. Most people take this on board, but then you get those special snowflakes. You know, that one guy/girl you work with who writes code in the laziest fashion possible? That one guy/girl who is a nightmare to work with because he/she follows literally zero conventions? You know who I’m on about.

People like this. They wind me up to no end and make my job so much harder than it needs to be. I’m not saying I’m a saint, I’ve written some code in the past I’m not proud of, but at least I do my best to refactor it and make it readable for other devs that might come along and alter my code, and I have learned from it. This profession is all about self improvement. Every situation is different in some manner, so you need to have your mental toolbox to be ready to deal with anything. These people though. Oh no. It’s their way or nobody’s. It’s like trying to speak Welsh to someone who only speaks Japanese, you’ll get nowhere with them and you’ll get frustrated at that fact.

If you don’t refactor your code, or keep it at the very least moderately maintainable, I implore you to sit down and get into the habit of it, you’ll be saving so many other developers so much time, and yourself in the future if there is a bug with what you have written. Don’t rely on comments alone. Seriously, don’t.

The benefits of using O.P.P. programming is its defining principles: encapsulation, inheritance, and polymorphism. Encapsulation Objects are self-contained entities, meaning they are not dependent. Hiding is a term often used to describe this self-contained, "keeping-to-oneself" personality. Objects maintain a boundary between its state and behavior, and the outside world. A common boundary is public/private access. Like objects in the real world, objects used in computer programming have various types of relationships with different categories of objects in the applications that use them. On Java platform, access specifiers are used to vary the nature of object relationships from public access to private access, where public access is wide open and publicly available to all subclasses, and private access is private and only available to the parent class. The public and private boundary enforces the object-oriented principle of encapsulation. On Java platform, a programmer can vary the strength of this boundary on an object-to-object basis, depending on a system of trust. Inheritance In standard structuring, it is common to copy a structure, give it a new name, and add or modify the attributes that will make the new entity different from its original source. However, this approach will eventually generate a great deal of duplicated code, which can create maintenance issues. Object-oriented programming introduces the concept of inheritance, where the specialized objects (child)--without additional code--can copy the attributes and behavior of the source objects (parent) it specializes. If some of the attributes or behaviors need to change, the programmer can simply override them, where a programmer only changes what they need to change in order to create a specialized object. Suppose a programmer was writing a human-resources application and wanted to use the

object as the basis for a new object called

. Since

would be the child, its attributes will match its parent,

, with additional attributes to make it specialized: Taxpayer identification number Hire date Salary Inheritance makes it simple to create the

class of the object without having to copy all of the

code manually. Polymorphism Polymorphism is when objects that belong to the same hierarchy are sent the same message (or when told to do the same thing), and have the ability to manifest that behavior differently. To use polymorphism in a business-application context, return to the

object and its ability to format its attributes into a

. However, polymorphism makes it possible for

to represent its attributes in a variety of ways, depending on the type of