#207 - new article added

_layouts/post.html

@@ -20,8 +20,6 @@
       <!--<meta itemprop="width" content="250"/>-->
     <!--</div>-->
   </div>
-
-
     <div class="inline-element-first">
         <time
             itemprop="datePublished dateModified"
@@ -30,12 +28,8 @@
         </time>
     </div>
     <div class="inline-element">
-      <a href="{{ site.url }}{{ page.url }}#disqus_thread" class="a-black">comments</a>
+      <a href="{{ site.url }}{{ page.url }}#disqus_thread" class="a-black" data-proofer-ignore>comments</a>
     </div>
-
-
-
-
   <h1 itemprop="name headline mainEntityOfPage">{{ page.title }}</h1>
   {{ page.excerpt }}
   <figure>

_posts/2019/03/2019-03-18-extension-methods-are-not-oop.md

@@ -15,7 +15,7 @@ comments: true
 [Extension method] is a special language feature introduced by Kotlin, Swift and
 other programming languages, which allows developers to add new methods to
 otherwise unchangeable classes. While at first it seems like a great idea, in
-reality it contradicts core OOP concepts and ideas.
+reality it contradicts the core OOP concepts and ideas.
 
 <!--more-->
 

_posts/2020/02/2020-02-24-object-and-functions-friends-or-foes-neither.md

@@ -0,0 +1,92 @@
+---
+date: 2020-02-24
+title: "Objects and functions - friends or foes? Neither!"
+figure: /assets/images/posts/2020/object-and-functions-friends-or-foes-neither/Functional-Programming-vs-OOP.png
+figcaption: © educba.com
+figalt: Functional programming vs OOP
+description: OOP and functional programming are often contrasted, but maybe they should be compared instead?
+keywords:
+- oop
+
+categories: oop
+comments: true
+---
+
+Programmers often view [object-oriented] and [functional programming] as two completely different paradigms. As a result,
+some developers advocate for one them, pointing out the advantages of their favourite paradigm and criticizing the
+"opposing" one. However, I have rarely seen anyone *comparing* OOP with functional programming instead of
+*contrasting* them.
+
+<!--more-->
+
+Let's look at this piece of Kotlin code, which filters and then maps the elements of the given list:
+
+```kotlin
+val result = listOf("Adam", "Bob", "Boris")
+    .filter { it.startsWith("B") }
+    .map { it.length }
+```
+
+This is how the code above usually looks like in classic Java, one of the most popular OOP languages:
+
+```java
+List<String> originalList = Arrays.asList("Adam", "Bob", "Boris");
+List<String> filteredList = new ArrayList<>();
+List<String> mappedList = new ArrayList<>();
+
+for (String name : originalList) {
+    if (name.startsWith("B")) {
+        filteredList.add(employee);
+    } 
+}
+
+for (String name : filteredList) {
+    mappedList.add(name.length());
+}
+```
+
+Is there any way we could *compare* this code snippet with the initial one? I don't think so. However, we can
+and should rather *contrast* it. This seems quite apparent, right? The reason for it is that this piece of Java code is
+not object-oriented, but *imperative*.
+
+The *object-oriented* Java code should like this:
+
+```java
+List<String> result = new ListOf<>(
+    new Mapped<>(
+      s -> s.length(),
+      new Filtered<>(
+          s -> s.startsWith("B"),
+          new IterableOf<>("Adam", "Bob", "Boris")
+        ),
+    )
+);
+// The "ListOf", "Mapped" and "Filtered" classes are from the
+// "yegor256/cactoos" java lib
+```
+
+This [solution] is very similar to the initial functional one, although the paradigms are completely different, which brings
+us to the main point of the article - **OOP and functional programming are two paradigms that solve the given problem
+in a *declarative* manner through a *composition* of smaller logical blocks**. In other words, *what* functional and OOP
+are doing is the same (a composition of smaller logical blocks), but *how* they are doing it is different
+(OOP relies on [objects], while functional programming relies on functions).
+
+I believe that by reapproaching OOP with the idea of **adding new functionality *declaratively*, *incrementally*
+and through a *composition* of small logical blocks**,
+we can not only improve our code, but also to change the way we analyze the problems we encounter (from imperative to
+declarative). In addition, it can enable us to revisit the OOP patterns (such as the *Decorator* pattern demonstrated above)
+to see which of them apply to this concept and how.
+
+The next time you use an OOP language to solve a problem, try to do it *declaratively* and *incrementally*, and then
+see if what you come up with can *compare* to the code snippets in this article. 
+
+
+[functional programming]: https://en.wikipedia.org/wiki/Functional_programming
+[object-oriented]: https://en.wikipedia.org/wiki/Object-oriented_programming
+[solution]: https://www.yegor256.com/2015/02/26/composable-decorators.html
+[objects]: /2018/07/27/props-file.html
+
+[utility classes]: https://www.yegor256.com/2014/05/05/oop-alternative-to-utility-classes.html
+[reducing scope]: https://www.yegor256.com/2019/03/12/data-and-maintainability.html
+[fully encapsulated]: https://g4s8.github.io/fully-encapsulated/
+

_rake/aspell.en.pws

@@ -1,4 +1,6 @@
 personal_ws-1.1 en 0
+declaratively
+reapproaching
 Disqus
 POJO
 Yegor

index.html

@@ -7,7 +7,7 @@
 {% for post in paginator.posts %}
   <article class="article-preview">
     {{ post.date | date: "%B %-d, %Y" }}
-    <a href="{{ site.url }}{{ post.url }}#disqus_thread" class="inline-element a-black">comments</a>
+    <a href="{{ site.url }}{{ post.url }}#disqus_thread" class="inline-element a-black" data-proofer-ignore>comments</a>
     <h1>
       <a href="{{ site.baseurl }}{{ post.url }}">
         {{ post.title }}