Multiple inheritance is very general OOPS concept, then why it is not implemented in systemverilog and only single inheritance is allowed?
2nd why interfaces are not allowed inside class? Is it because of storage implementation like dynamic storage in class and static in modules, programs, interface?
This really should be two separate posts for your two distinct questions. Unfortunately the keyword interface will be used to answer both of them with entirely separate meanings.
I wrote a 2010 DVCon paper describing some of the reasons that multiple inheritance was not in the original SystemVerilog LRM, and possible solutions. SystemVerilog 1800-2012 did add multiple interface class inheritance and here is a link to a good description of that feature. This use of the keyword interface as a kind of class has nothing to do with the interface in your 2nd question.
You are mostly correct about why interface instances are not allowed in classes. An SV interface is very similar to the design elements module and program that are instances of hierarchical containers. During the process of elaboration, these containers get flattened out before simulation begins. Class instances are only constructed at run-time by executing procedural code.
The elaboration process is particular to hardware description languages and is part of the the code generation and replication process. It is also what allows you to hierarchically reference signals throughout the design without the use of pointers. Class objects on the other hand, are only referenced through dynamically created handles.
I am trying to understand the definition of 'abstraction' in OOP.
I have come across two main definitions. Are they both valid? Is one of them wrong? I'm confused. (I re-wrote the definition with my own words).
Definition 1:
Abstraction is the concept of taking some object from the real world, and converting it to programming terms. Such as creating a Human class and giving it int health, int age, String name, etc. properties, and eat() etc. methods.
Definition 2:
A more general definition. Abstraction is a concept that takes place anywhere in a software system where 'making things more general/simpler/abstract' is involved. A few examples:
An inheritance hierarchy, where the higher classes are simpler or more general,
and define more general and abstract implementation.
While the lower classes in the hierarchy are more concrete and define
more detailed implementations.
Using encapsulation to hide the details of implementation of a class from other classes, thus making the class more 'abstract' (simpler) to the outside software world.
Is any of these definitions correct?
(I am referring to the most conventional and accepted definition).
I'm learning computer programming and at several places I've stumbled upon the concept of cohesion and I understand that it is desirable for a software to have "high cohesion" but what does it mean? I'm a Java, C and Python programmer learning C++ from the book C++ Primer which mentions cohesion without having it in the index, could you point me to some links about this topic? I did not find the wikipedia page about computer science cohesion informative since it just says it's a qualitative measure and doesn't give real code examples.
High cohesion is when you have a class that does a well defined job. Low cohesion is when a class does a lot of jobs that don't have much in common.
Let's take this example:
You have a class that adds two numbers, but the same class creates a window displaying the result. This is a low cohesive class because the window and the adding operation don't have much in common. The window is the visual part of the program and the adding function is the logic behind it.
To create a high cohesive solution, you would have to create a class Window and a class Sum. The window will call Sum's method to get the result and display it. This way you will develop separately the logic and the GUI of your application.
An explanation of what it is from Steve McConnell's Code Complete:
Cohesion refers to how closely all the routines in a class or all the
code in a routine support a central purpose. Classes that contain
strongly related functionality are described as having strong
cohesion, and the heuristic goal is to make cohesion as strong as
possible. Cohesion is a useful tool for managing complexity because
the more code in a class supports a central purpose, the more easily
your brain can remember everything the code does.
Some way of achieving it from Uncle Bob's Clean Code:
Classes should have a small number of instance variables. Each of the
methods of a class should manipulate one or more of those variables.
In general the more variables a method manipulates the more cohesive
that method is to its class. A class in which each variable is used by
each method is maximally cohesive.
In general it is neither advisable
nor possible to create such maximally cohesive classes; on the other
hand, we would like cohesion to be high. When cohesion is high, it
means that the methods and variables of the class are co-dependent and
hang together as a logical whole.
The notion of cohesion is strongly related with the notion of coupling; also, there is a principle based on the heuristic of high cohesion, named Single Responsibility Principle (the S from SOLID).
High cohesion is a software engineering concept. Basically, it says a class should only do what it is supposed to do, and does it fully. Do not overload it with functions that it is not supposed to do, and whatever directly related to it should not appear in the code of some other class either.
Example is quite subjective, since we also have to consider the scale. A simple program should not be too modularized or it will be fragmented; while a complex program may need more level of abstractions to take care of the complexity.
e.g. Email class. It should contains data members to, from, cc, bcc, subject, body, and may contain these methods saveAsDraft(), send(), discardDraft(). But login() should not be here, since there are a number of email protocol, and should be implemented separately.
Cohesion is usually measured using one of the LCOM (Lack of cohesion) metrics, the original LCOM metric came from Chidamber and Kemerer. See for example:
http://www.computing.dcu.ie/~renaat/ca421/LCOM.html
A more concrete example:
If a class has for example one private field and three methods; when all three methods use this field to perform an operation then the class is very cohesive.
Pseudo code of a cohesive class:
class FooBar {
private SomeObject _bla = new SomeObject();
public void FirstMethod() {
_bla.FirstCall();
}
public void SecondMethod() {
_bla.SecondCall();
}
public void ThirdMethod() {
_bla.ThirdCall();
}
}
If a class has for example three private fields and three methods; when all three methods use just one of the three fields then the class is poorly cohesive.
Pseudo code of a poorly cohesive class:
class FooBar {
private SomeObject _bla = new SomeObject();
private SomeObject _foo = new SomeObject();
private SomeObject _bar = new SomeObject();
public void FirstMethod() {
_bla.Call();
}
public void SecondMethod() {
_foo.Call();
}
public void ThirdMethod() {
_bar.Call();
}
}
The class doing one thing principle is the Single Responsibility Principle which comes from Robert C. Martin and is one of the SOLID principles. The principle prescribes that a class should have only one reason to change.
Staying close to the Single Responsibility Principle could possibly result in more cohesive code, but in my opinion these are two different things.
Most of the answers don't explain what is cohesion, It is well defined in uncle bobs book clean code.
Classes should have a small number of instance variables. Each of the
methods of a class should manipulate one or more of those variables.
In general the more variables a method manipulates the more cohesive
that method is to its class. A class in which each variable is used by
each method is maximally cohesive. In general it is neither advisable
nor possible to create such maximally cohesive classes; on the other
hand, we would like cohesion to be high. When cohesion is high, it
means that the methods and variables of the class are co-dependent and
hang together as a logical whole.
Let me explain it with a class definition
class FooBar {
private _bla;
private _foo;
private _bar;
function doStuff()
if(this._bla>10){
this._foo = 10;
this._bar = 20;
}
}
function doOtherStuff(){
if(this._foo==10){
this._bar = 100;
this._bla = 200;
}
}
}
If you see the above example the class is cohesive that means the variables are shared among the class to work together more variables are shared that means the class is highly cohesive and work as a single unit.
This is an example of low cohesion:
class Calculator
{
public static void main(String args[])
{
//calculating sum here
result = a + b;
//calculating difference here
result = a - b;
//same for multiplication and division
}
}
But high cohesion implies that the functions in the classes do what they are supposed to do(like they are named). And not some function doing the job of some other function. So, the following can be an example of high cohesion:
class Calculator
{
public static void main(String args[])
{
Calculator myObj = new Calculator();
System.out.println(myObj.SumOfTwoNumbers(5,7));
}
public int SumOfTwoNumbers(int a, int b)
{
return (a+b);
}
//similarly for other operations
}
The term cohesion was originally used to describe modules of source code as a qualitative measure of how well the source code of the module was related to each other. The idea of cohesion is used in a variety of fields. For instance a group of people such as a military unit may be cohesive, meaning the people in the unit work together towards a common goal.
The essence of source code cohesion is that the source code in a module work together towards a common, well defined goal. The minimum amount of source code needed to create the module outputs is in the module and no more. The interface is well defined and the inputs flow in over through the interface and the outputs flow back out through the interface. There are no side effects and the emphasis is on minimalism.
A benefit of functionally cohesive modules is that developing and automating unit tests is straightforward. In fact a good measure of the cohesion of a module is how easy it is to create a full set of exhaustive unit tests for the module.
A module may be a class in an object oriented language or a function in a functional language or non-object oriented language such as C. Much of the original work in this area of measuring cohesion mostly involved work with COBOL programs at IBM back in the 1970s so cohesion is definitely not just an object oriented concept.
The original intent of the research from which the concept of cohesion and the associated concept of coupling came from was research into what where the characteristics of programs that were easy to understand, maintain, and extend. The goal was to be able to learn best practices of programming, codify those best practices, and then teach the practices to other programmers.
The goal of good programmers is to write source code whose cohesion is as high as possible given the environment and the problem being solved. This implies that in a large application some parts of the source code body will vary from other parts as to the level of cohesion of the source code in that module or class. Some times about the best you can get is temporal or sequential cohesion due to the problem you are trying to solve.
The best level of cohesion is functional cohesion. A module with functional cohesion is similar to a mathematical function in that you provide a set of inputs and you get a specific output. A truly functional module will not have side effects in addition to the output nor will it maintain any kind of state. It will instead have a well defined interface which encapsulates the functionality of the module without exposing any of the internals of the module and the person using the module will provide a particular set of inputs and get a particular output in return. A truly functional module should be thread safe as well.
Many programming language libraries contain a number of examples of functional modules whether classes, templates, or functions. The most functional cohesive examples would be mathematical functions such as sin, cosine, square root, etc.
Other functions may have side effects or maintain state of some kind resulting in making the use of those functions more complicated.
For instance a function which throws an exception or sets a global error variable (errno in C) or must be used in a sequence (strtok() function is an example from the Standard C library as it maintains an internal state) or which provides a pointer which must then be managed or issues a log to some log utility are all examples of a function that is no longer functional cohesion.
I have read both Yourdon and Constantine's original book, Structured Programming, where I first came across the idea of cohesion in the 1980s and Meilir Page-Jones' book Practical Guide to Structured Systems Design, and Page-Jones did a much better job of describing both coupling and cohesion. The Yourdon and Constantine book seems a bit more academic. Steve McConnell's book Code Complete is quite good and practical and the revised edition has quite a bit to say about good programming practice.
A general way to think of the principle of cohesion is that you should locate a code along with other code that either depend on it, or upon which it depends. Cohesion can and should be applied to levels of composition above the class level. For instance a package or namespace should ideally contain classes that relate to some common theme, and that are more heavily inter-dependent than dependent on other packages/namespaces. I.e. keep dependencies local.
cohesion means that a class or a method does just one defined job. the name of the method or class also should be self-explanatory. for example if you write a calculator you should name the class "calculator" and not "asdfghj". also you should consider to create a method for each task, e.g. subtract() add() etc...
the programmer who might use your program in the future knows exactly what your methods are doing. good naming can reduce commenting efforts
also a principle is DRY - don't repeat yourself
MSDN's article on it is probably more informative than Wikipedia in this case.
Is there a difference in the meaning of "class diagram" and "object graph"?
see this tutorial
http://www.cs.toronto.edu/~jm/340S/Slides6/ClassD.pdf
Object graph contains value of one instance of class see example View its a view of an object system at a particular point in time
while
class diagram as wiki
The class diagram is the main building block of object oriented modelling. It is used both for general conceptual modelling of the systematics of the application, and for detailed modelling translating the models into programming code. Class diagrams can also be used for data modeling.[1] The classes in a class diagram represent both the main objects and or interactions in the application and the objects to be programmed. In the class diagram these classes are represented with boxes which contain three parts: [2]
A class with three sections.
The upper part holds the name of the class
The middle part contains the attributes of the class
The bottom part gives the methods or operations the class can take or undertake
see further
I agree with the previous post but would like to add that a class diagram is based on UML which is an accredited language sponsored by the OMG and known by over 5 millions users. UML is therefore a standard based on a model from which you get views.
IN UML 2 the class diagram is fantastic if used with Java because it seems to me that the new specification has exactly the same structure as a java project. It include a project name, with packages including classifiers (e.g. Class, interface, enum) which includes attributes, methodes which includes properties.
If you have to use just one diagram I would say to use Class diagram. It is easy to create because you don't need to know UML and can reverse engineer your project into a model a get class diagram views. My class diagram is Just magic:-)
Class diagram represent class name,its attributes and behaviours whereas object diagram represent instance of class diagram,object diagram comes under class diagram
Abstract classes are described as being useful for a family of objects (e.g. could be used for animals which are mammals). However, what difference is there between using an interface or abstract class for representing a family of related objects?
My process is to use an abstract class when I want to define common functionality but with the option for future extensions and an interface for custom functionality (implementations).
For example, I wrote an abstract class to encapsulate some database functionality which will be used heavily in a small web app at work. I wrote an abstract class with virtual methods which can be overrided with custom functionality in the future (e.g. logging, or some reporting of the database events which may be required).
Is this the right way to go? Is there any significance in choosing one construct (abstract or interface) to represent a family?
An abstract class should be used when there is common state and behavior between all types. An interface should be used when all types will have a common interface but will not share state or behavior.
Here is an example.
German Shepherd, Golden Retriever, Beagle
These three objects are all dogs, and as such they share certain common state (carnivorous, 4 legs, etc.) and they also share certain overridable behavior (bark, pant, etc.). In this instance it would make the most sense to create an abstract Dog class to hold this common state and behavior and create subtypes of Dog for each type of dog.
Pencil, Pen, Chalk
These objects have no common state and they cannot share behavior. Yet you may notice that they do have something in common - they are cabaple of writing. These objects are best build separately and without a base class and then tied together with a Writable interface that exposes each type's Write method.
I would suggest using interfaces so that you can implement new functionality in your database utility at some future point.
As always, the primary design principle when it comes to development is
Design towards an interface, not an implementation
With abstract classes, you can provide implementation that is needed and shared by all the classes in your hierarchy. Therefore, you're reusing code. You may allow the derived classes to override the default behavior or not but at least you're providing a baseline functionality like breathing for a new born animal. However, with interfaces, you can't provide any implementation. You simply define a contract that all classes that inherits that interface should honor and provide implementation for. This may lead to repetitive and duplicate code among the hierarchy of classes.
Interfaces are not very good for extensibility and you need to worry about versioning. You decide to make change to an existing interface but you will soon realize that there are a lot of classes in existence you may need to modify. Think about adding Breath method to IMammal interface that's already being used by many mammals. You will need to go and provide Breath implementation for each one. With an abstract class, you can simply add Breath method and provide some baseline implementation without having to worry about existing derived classes. So abstract classes are more flexible in term of the development of your hierarchy and the api.