Design Models to a specific language
There is a way to objectively describe and observe it and test a program. When you have something that behaves in a deterministic way you can gauge immediately if it solves your problem or determine at least if the problem you need to solve is being addressed.
Structural models of software display the organization of a system in terms of the components that make up that system and their relationships.
We’re going to focus on class diagram for modeling the structure of the classes in a software system.
Class Diagram
We will use the information we have from the conceptual model about our objects to create the class diagram.
Naming Convention
You start by using a way for naming your classes. Usually, the class name is in the singular, and uppercase first later, like “BankAccount”.
For the attributes, and methods, they are in camel case; lower case first letter, and all other words begins with upper case letter, like “getProductDetails”.
Some people prefer to use uppercase first letter for private attributes and methods, but it doesn’t matter, unless you’re using one way for naming, and your code is clear, easy to read and maintain.
Attributes
We then write the attributes, their data types and their default value if exist.
Methods
Write the methods, their parameter if exist inside a parentheses, and their return type.
Public, Private and Protected
They are called the access modifiers. They are used to control the access to object’s members.
Now, a good case practice is to keep all you members (attributes and methods) private unless it needs to be exposed.
So, we use signs to denote the access modifier of each member in the class.
- Public (‘+’): It says that it can be seen and triggered at any part of the application
- Private (‘-’): It says that it can be only triggered inside it’s class only
- Protected (‘#’): It says that it can be only triggered inside it’s class and also inside the child classes.
Some developers tend to keep their attributes private even if they know some other class need to trigger them. They allow getting and setting the value of these attributes through what’s called Getters and Setters. These are methods to get and set the attributes without allowing any external code to have a direct effect on them.
Constructor and Destructor
Whenever you create an object, you need to construct that object, meaning you assign all the instance variables to their correct values. This makes sure the object will be in a valid state once it’s created.
The constructor is method has the same name of the class. It’s called as soon as you created an object. You can have multiple constructors.
Having two or more methods with the same name, but with different parameters, either in the number of the parameters, their sequence, or their data type, is called “method overloading”.
The same idea as having a method that will be called as soon as the object is created, there is another one whenever the object goes out of the scope.
In Java, there is no destructor since it’s garbage collected language, hence you can’t know when the object will be destroyed by the garbage collected. While in C++, this concept applies, and we do have a destructor.
Instance Members Vs Static Members
Maybe we need to have a member that will be the same for across all instantiated objects.
If that’s the case, we can create a static member that’s shared across all the class. So, there will be one and only one copy of this member.
Static members are shown with underline to differentiate between them and the instance members.
You access a static member through the class name, not the object instantiated, and also you can access it even if there is no objects have been instantiated yet.
Now, one important thing to know, you can’t trigger an instance methods or attributes inside a static method.
This should make sense for you, because, static methods aren’t tied to any object, so, these instance methods or attributes don’t belong to any object when we are trying to trigger them from inside a static method.
Types of Relationships
Inheritance
When we say, “a student IS-A person”, “an employee IS-A person” “a car IS-A vehicle”, “a bus IS-A vehicle”, etc. This indicates that student and employee share some common attributes and behaviors, the same for car and bus.
Inheritance provides a generic super class, an abstract class, that has the common attributes and methods between all sub classes.
This way, we avoid duplicates, as we don’t have to write the common attributes or methods. You only write them once in the super class, and they automatically will have all the attributes and methods from their super class.
We may add some methods, or attributes that are specific to the sub class.
Something to watch out for, if you want to re-write the inherited methods in the sub class, we’re doing what’s called overriding.
Overriding is replacing or adding additional behavior to the inherited one.
This is a not good case practice here, unless you have an abstract method in the super class. The abstract methods will be explained later.
Another thing is, try to avoid the situation where you have many level of inheritance — Depth of Inheritance (DIT). Don’t look for inheritance, inheritance announces for it self.
Can you bring an object-oriented design to a «non object-oriented» language?
IMPOSIBLE!!! don’t try it Because its a very particular way to program and you can’t transform apples to oranges!
References:
https://modeling-languages.com/models-to-code-interview-leon-starr/
Credits at the outstanding image
Estudio Ícone
From Pexels
Understated Chaos 