Piszę program funkcyjnie, wiec dodam sobie funkcje/callbacki i rozwiązałem problem.
Teraz piszę program w paradygmacie obiektowym, i zastanawiam się jak ugryść strategię.
Wziąć i zaimplementować. Jeżeli priorytetem jest utrzymanie programu w zgodności z paradygmantem obiektowym, to nie wiem co uważasz za ten paradygmat.
- Jestem zdania, że w obiektowym świecie (paradygmacie obiektowym), należy tworzyć obiekty które dostają jakiś parametr (np przez konstruktor) - nazywaj to jak chcesz, ja to nazwałem enkapsulacją, ale jeśli Ty masz inne określenie na enkapsulacje, to nie chce użyć tego słowa. Chodzi dokłądnie o to co napisałem: "ze instancje dostają coś przez parametr". To moim zdaniem jest potrzebne, żeby móc nazwać program napisany w paradygmacie obiektowym (nie ważne w jakim języku piszesz).
No i w końcu jasno napisałeś coś z czym mogę się jasno nie zgodzić. Dostawanie (mniejsza o sposób) jakiegoś parametru przez obiekt w czasie jego tworzenia (a również po utworzeniu), nie jest warunkiem niezbędnym, żeby coś nazwać OOP, lub nie OOP.
Nie mam ochoty gadać o tym czym według Ciebie jest enkapsulacja, albo czym według Ciebie jest programowanie obiektowe, nie mam ochoty na dywagacje o nazewnictwo. Chodzi tylko o to, czy strategia wpisuje się w paradygmat obiektowy czy nie. A jeśli tak, to czy to oznacza że funkcje globalne też wpisują się w ten paradgymat.
Ale cały ten wątek i twój problem to spór o nazewnictwo. Zastanawiasz się właśnie, czy jeżeli użyjesz funkcji globalnej, to wciąż będzie można nazwać twój program obiektowym. W poście gdzieś wyżej ubolewasz, że w części języków ~obiektowych klasy i struktury mają taką samą nazwę.
Według mojej wiedzy, nie ma aktualnie żadnego popularnego języka, który jest w 100% obiektowy. Co dla przykładu robią w Javie metody statyczne, pola statyczne, typy prymitywne itd? Czy funkcje z kotlina można wcisnąć w nazwę "object oriented programing"? Jeden rabin powie tak, drugi powie, że nie. Jeżeli sobie popatrzysz na taką funkcję okiem ortodoksa, to absolutnie nie. Ale liberał powie ci, ze taka funkcja to trochę jak implementacja interface'u funkcyjnego, tylko dzięki code sugars z kotlina nie trzeba nigdzie pisać "interface" i nazwy metody, to to się rozumie samo przez siebie. Albo czy tak modne "immutable objects" to obiekty? Bo przecież ideą u podstaw OOP było połączenie danych i logiki, która na nich operuje (w tym zmienia) w jeden byt, np.:
public class Counter{
private int clicks = 0;
public void click(){
clicks++;
}
public int getClicks() return clicks;
}
No i jeżeli nie można, to jak to jest, że język niby czysto obiektowy, a można pisać nieobiektowo. O pakiecie Math, gdzie ani obiektów, ani metod, a właściwie same funkcje statyczne zapakowane bo trzeba w jedną klasę i typy prymitywne nawet nie warto wspominać.
A w temacie - strategia to dla mnie wzorzec w pełni obiektowy, ponieważ w moim rozumieniu wypełnia całkowicie założenia paradygmatu OOP. Pisze o klasycznych, wzorcowych metodach implementacji.