Traditional procedural programming focuses on actions – functions. Object oriented programming focuses on data (objects) and the operations on objects.
You want to look at items that you will be coding, and think, what makes this information up? and, What things can it do, and/or be done to it?
Objects in the physical realm are easy, it becomes a little more challenging when we were with things that are not physical objects, but with time and experience, those become more obvious as well.
When we think about objects, and their data, we can start to look for ways to group and sub-group data.
Objects can contain other objects. Like a student class might have a major class. That class would have things like the major’s name, but also how many credits are needed to graduate, a list of required courses, etc.
This is known as a aggregation relationship – and is thought of as a has-a relationship.
There are other types of relationships that we’ll cover in upcoming classes.
Class Guidelines
Cohesion – A class should cover a single type of entity.
Consistency – follow standard programming style and naming conventions
Encapsulation – data members should be private. Use getter and setter methods to access data.
Clarity – the previous should make clarity easy. That is how it is used should be clear in the naming and conventions as to what each method is going to do.
Completeness – a class should provide a variety of ways to perform commonly needed functions. This will make it more accessible to people. i.e. a Dice class shouldn’t limit you to 6-sided dice, as there are more types than that.
Instance v. Static – A variable or method that is dependent on a specific instance should be an instance variable/method. If it is shared, make it static.
Thinking in Objects was originally found on Access 2 Learn
