??‍?Software - Konstantinos Grevenitis

OOP, cohesion, coupling and heuristics

Introduction

In the OOP world, we do not need big, God like, classes that do a bit of everything. On the contrary, we need small classes that have specific roles and responsibilities. At the same time, each class has to be as independent as reasonably possible from the others, no matter if they belong in the same module or not.

In the OOP world a module is a package or a namespace, depending on the programming language you are using. The S.O.L.I.D principle that is focused on creating highly cohesive classes is the Single Responsibility Principle.

Think of your codebase as a multinational company, like LexCorp or Wayne Enterprises. You would not assign too many roles to a specific person, but you would not let them go rogue too. It is not that wise. There is always a hierarchy, a structure, a system of reasoning of who does what and why! It is the same in the OOP world. Always reason on how many classes you need and why, and which the role of each class. Try to avoid to be extremely verbal, ergo, do not create classes that have little or no role in your codebase!

Cohesion indicates the classes relationships within the module, while on the other hand coupling indicates the relationships among modules. The concepts of cohesion and coupling are not new at all. They were invented by Larry Constantine, and you can read more about them in the Structured Design book.

Finally, the OO Design Heuristics are a set of guidelines for good object-oriented designs. As Bjarne Stroustrup (father of the C++ programming language) correctly pointed out many years ago, just making a design “object oriented” doesn’t always mean that the design is good.

The software requirements bitter feelings

Introduction

“Not knowing the full requirements is agile“, an old boss of mine told me in the past. As soon as I heard it, I freaked out! I couldn’t believe it! I was so frustrated that I don’t know how I managed to keep my mouth shut! Lacking functional requirements is a recipe for disaster. A way straight to hell. You can’t build a system if you do not know how it works. Agile doesn’t alter the need for functional or other requirements, but it does change how you gather them. The waterfall way is to go through a long process of documents filling and revising them, till they contain all(?) the system’s requirements. The agile way to gather requirements is to specify the requirements for a small increment of the system, a minimum viable product as it is usually called, build it, then get feedback and work on the next increment. No matter the way the phrase “I don’t know” is embraced, it should never be acceptable! Without the right context anyone might understand anything!

Point of view*

Introduction

Christmas is always a period of retrospecting. So let’s retrospect software design and development. When it’s time to design a new software system, a lot of variables must be taken under consideration. One variable is the past also. In order to paint the future, you have to look what you or others did in the past, but also what didn’t happen and why. Especially the what didn’t happen part might give you more insights.

If you take a step back, and look at similar to yours products and services, you will understand more the progress that has taken place in the domain, the growth, the risks and the failures, if they exist. The software analysis, design, and development processes, principles and tools have changed a lot in the past fifty to seventy years. But one thing is still the same. And this is people’s point of view to the goal, no matter if they are the stakeholders, the developers, the users. And the goal is to be better, faster, stronger, more successful than the competitor and keep or increase the power and domination.

Could the goal be different? Well individually yes, but in a corporate world the aforementioned explanation of the goal, is what you will hear from most of the companies, unless companies have become socialistic structures and I don’t know about it!

*Fates Warning – Point Of View (OFFICIAL VIDEO) – YouTube

Think, don’t just execute

Introduction

I believe, and this might be a bit controversial, that many people write code, but not all of them are programmers. Programming has nothing to do with tools, languages, frameworks, IDEs per se, it has to do with your way of thinking. The process you follow to analyze and decompose the problem successfully, then to pick the right tools and use them correctly, without abusing them. My math professor, at the university, used to say: “Don’t kill a fly, with a shotgun”.

Simulate a bank run with emotional responses, with Agent Based Economics

TL;DR
This article is based on my master thesis with my supervisor, assistant professor Ilias Sakellariou.

The topic was to simulate a bank run scenario with agents that their emotions might change based on influences and end up in panic mode, cause of the fear that they will lose their money.

The scenario is simple. The agents everyday have a standard schedule. They wake up, the work for 8 hours, they do their groceries, if the goods are not enough, and return home. Suddenly they face rumors related to banks credibility, and this leads to massive withdrawals till we end up to a bank run phenomena.

You can go directly to the results, or to the references.

A paper by Springer, will be published soon.

Introduction

In recent years, agent based simulation has been successfully utilized in studying various economic phenomena. Those research results focus on modeling and simulation of emotions in Agent Based Economics (ACE).

The economic phenomena simulation based on multi-agent systems is one of the most contemporary ways of studying the latter, as it allows the design of various factors with twenty-two standardized emotions, which interact with each other.

The research scenario under investigation in the context of the present work, is the one of “bank panic”. The term “panic”, refers to the presence of emotional bias towards the unanticipated deposits withdrawal from more than one bank (simultaneous bank runs). The simulation world is composed of depositor agents, influencer agents, banks, ATMs, and retail shops.

C# extension methods to save the day

Introduction

Extensions methods, that are heavily used in LINQ and in fluent like interfaces, allow developers not just extend existing types but organize the code better. Especially functionalities related to those types. Also, extension methods can be used to add functionality to types we have no control upon them.

C# and FP – episode 3 – OOP today, Inversion of Control and Dependency injection.

Introduction

The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.
Joe Armstrong, father of Erlang

He is right, you know! I totally agree with the quote above. The abuse of inheritance, leads to over complex systems with objects that have no clear responsibility and in general the SOLID principles go out of the window.

C# and FP – episode 2 – OOP today, (im)mutability.

Introduction

An object’s state, describes its current condition. If object was a human, this could be their emotional state (e.g happy, sad, angry). To think a bit further, the height value in an object’s field is not a state, but the height’s value help us to define it’s height category (e.g tall, short, average), that is actually the state. And it is the state, based on the context we, as society, have set on defining when someone is considered tall or not.

A bit of FIWARE history

Introduction

Actually, this is the article I should start with, but I didn’t. Before talking about the functionalities of the Orion context Broker, we should tell a few words about the whole initiative.

FIWARE is an open source cloud platform with a collaborative and mature ecosystem of developers, innovation Hubs, accelerators, cities and more than 1000 Small and Medium Enterprises and startups. By 2020, businesses leveraging the FIWARE platform are expected to generate revenues of more than EUR 330 million [1].

Internet object

Introduction

A small article about the internet object. Internet object is one more format for sending data over the wire. Specifically:

It is designed for transferring data over internet, Internet Object is a new age serialization/data-interchange format. It is human readable, thin, self explanatory, robust and schema oriented. It was developed by Mohamed Aamir Maniar out of frustrations associated with JSON.
by https://internetobject.org